[OAUTH-WG] Fwd: issues with token age element - MAC token
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 the > overall header, as before). > > skylar > > > > On May 23, 2011, at 2:11 AM, Skylar Woodward wrote: > >> You may have noticed, on page 8 the host is listed as "example.net" - should >> be example.com, I believe. (draft v5) >> >> All in all, I'm in support of the changes in v2. Certainly addresses my >> hesitations from v2. >> >> skylar >> >> >> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote: >> >>> (Please discuss this draft on the Apps-Discuss >>> mailing list) >>> >>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >>> >>> While this document has moved to the Apps-Discuss mailing list for the time >>> being, I wanted to give a quick update to those who have been following >>> this draft which originated on this list. >>> >>> The
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. Y
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
But see, now you are specializing the use of MAC token even more - now it's becoming a service mainly for user-agents on home desktops? This is further for the original goal of making MAC as flexible is possible. In this case you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short. Sarcasm aside, my point is that timestamp is just as good as your offset technique and is more: reliable, straightforward, flexible. User agents that care about creating robust behavior for home desktops or mobiles (presumably of users and OS not yet sophisticated enough to check network time on their own) should be advised to do clock correction on their own (by pinging a time service) and trusting the device clock alone. Please change the spec back to using timestamp rather than age. I'd also like to hear a convincing argument from the Mozilla co-authors about why they think that age is more resilient than the above (I believe it is not) and further more why they would find the above unattractive or difficult to implement in a modern user-agent. Thanks, skylar ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. skylar woodward Kiva Developer Program / build.kiva.org / @buildkiva On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: > 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
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
I can't speak for Mozilla, but I can tell you that many folks don't have synchronized clocks, for a wide variety of reasons. I guess I don't really understand why you view age as problematic. You reference "fragility of using time-since-credentials-issued" but you don't say what exactly is fragile about it. There's nothing particularly complex about age, especially when using the monotonic clock provided by all modern operating systems. Adam On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward wrote: > But see, now you are specializing the use of MAC token even more - now it's > becoming a service mainly for user-agents on home desktops? This is further > for the original goal of making MAC as flexible is possible. In this case you > should change the spec name to > MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF > for short. > > Sarcasm aside, my point is that timestamp is just as good as your offset > technique and is more: reliable, straightforward, flexible. > > User agents that care about creating robust behavior for home desktops or > mobiles (presumably of users and OS not yet sophisticated enough to check > network time on their own) should be advised to do clock correction on their > own (by pinging a time service) and trusting the device clock alone. > > Please change the spec back to using timestamp rather than age. > > I'd also like to hear a convincing argument from the Mozilla co-authors about > why they think that age is more resilient than the above (I believe it is > not) and further more why they would find the above unattractive or difficult > to implement in a modern user-agent. > > Thanks, > skylar > > ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- .-.. > .- .-. — .-- --- --- -.. .-- .- .-. -.. > skylar woodward > Kiva Developer Program / build.kiva.org / @buildkiva > > > On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: > >> 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
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
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 origi
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
, >>> skylar >>> >>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- >>> .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>> skylar woodward >>> Kiva Developer Program / build.kiva.org / @buildkiva >>> >>> >>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>> >>>> 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. >>>>>>> >>>>>>> The
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
imestamp is just as good as your offset >>>> technique and is more: reliable, straightforward, flexible. >>>> >>>> User agents that care about creating robust behavior for home desktops or >>>> mobiles (presumably of users and OS not yet sophisticated enough to check >>>> network time on their own) should be advised to do clock correction on >>>> their own (by pinging a time service) and trusting the device clock alone. >>>> >>>> Please change the spec back to using timestamp rather than age. >>>> >>>> I'd also like to hear a convincing argument from the Mozilla co-authors >>>> about why they think that age is more resilient than the above (I believe >>>> it is not) and further more why they would find the above unattractive or >>>> difficult to implement in a modern user-agent. >>>> >>>> Thanks, >>>> skylar >>>> >>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- >>>> .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>>> skylar woodward >>>> Kiva Developer Program / build.kiva.org / @buildkiva >>>> >>>> >>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>>> >>>>> 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 va
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
May 30, 2011 at 12:03 AM, Skylar Woodward wrote: >>>>> But see, now you are specializing the use of MAC token even more - now >>>>> it's becoming a service mainly for user-agents on home desktops? This is >>>>> further for the original goal of making MAC as flexible is possible. In >>>>> this case you should change the spec name to >>>>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or >>>>> MTBCRLF for short. >>>>> >>>>> Sarcasm aside, my point is that timestamp is just as good as your offset >>>>> technique and is more: reliable, straightforward, flexible. >>>>> >>>>> User agents that care about creating robust behavior for home desktops or >>>>> mobiles (presumably of users and OS not yet sophisticated enough to check >>>>> network time on their own) should be advised to do clock correction on >>>>> their own (by pinging a time service) and trusting the device clock alone. >>>>> >>>>> Please change the spec back to using timestamp rather than age. >>>>> >>>>> I'd also like to hear a convincing argument from the Mozilla co-authors >>>>> about why they think that age is more resilient than the above (I believe >>>>> it is not) and further more why they would find the above unattractive or >>>>> difficult to implement in a modern user-agent. >>>>> >>>>> Thanks, >>>>> skylar >>>>> >>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- >>>>> .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>>>> skylar woodward >>>>> Kiva Developer Program / build.kiva.org / @buildkiva >>>>> >>>>> >>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>>>> >>>>>> 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
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
; The client has no way of determining on its own when the value was >>>> actually issued (unless we communicate that on the developer website and >>>> force users to embed that with client_id, which adds usability issues of >>>> users copying and entering string date values correctly). The same is >>>> actually true for all of our OAuth access tokens because we reissue tokens >>>> to the same client_id if they were previously issued and are still valid. >>>> (The client would thus think the issue_date was now() when if fact it was >>>> the time of the first issue for client_id+scope+grantor_id). Thus, age is >>>> really just a convoluted way of trying to communicate the device system >>>> offset: >>>> >>>>local_offset = current_server_time - current_device_time >>>>age = current_device_time - (server_issue_date-local_offset) >>>> >>>> Since the protocol doesn't currently allow for server_issue_date to be >>>> given with tokens, thus age currently can't have the resilience that >>>> timestamp does. It also forces servers to issue new tokens on demand just >>>> to make the convoluted age system work (rather than reuse existing valid >>>> tokens). Or, you have to modify the protocol to add server_issue_date and >>>> current_server_time into the token-issue exchange - eg, more complexity. >>>> >>>> Timestamp is simpler, proven, it and it has a solution for your use case >>>> of unsyncronized clocks. >>>> >>>> skylar >>>> >>>> >>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote: >>>> >>>>> I can't speak for Mozilla, but I can tell you that many folks don't >>>>> have synchronized clocks, for a wide variety of reasons. I guess I >>>>> don't really understand why you view age as problematic. You >>>>> reference "fragility of using time-since-credentials-issued" but you >>>>> don't say what exactly is fragile about it. There's nothing >>>>> particularly complex about age, especially when using the monotonic >>>>> clock provided by all modern operating systems. >>>>> >>>>> Adam >>>>> >>>>> >>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward wrote: >>>>>> But see, now you are specializing the use of MAC token even more - now >>>>>> it's becoming a service mainly for user-agents on home desktops? This is >>>>>> further for the original goal of making MAC as flexible is possible. In >>>>>> this case you should change the spec name to >>>>>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or >>>>>> MTBCRLF for short. >>>>>> >>>>>> Sarcasm aside, my point is that timestamp is just as good as your offset >>>>>> technique and is more: reliable, straightforward, flexible. >>>>>> >>>>>> User agents that care about creating robust behavior for home desktops >>>>>> or mobiles (presumably of users and OS not yet sophisticated enough to >>>>>> check network time on their own) should be advised to do clock >>>>>> correction on their own (by pinging a time service) and trusting the >>>>>> device clock alone. >>>>>> >>>>>> Please change the spec back to using timestamp rather than age. >>>>>> >>>>>> I'd also like to hear a convincing argument from the Mozilla co-authors >>>>>> about why they think that age is more resilient than the above (I >>>>>> believe it is not) and further more why they would find the above >>>>>> unattractive or difficult to implement in a modern user-agent. >>>>>> >>>>>> Thanks, >>>>>> skylar >>>>>> >>>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- >>>>>> .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>>>>> skylar woodward >>>>>> Kiva Developer Program / build.kiva.org / @buildkiva >>>>>> >>>>>> >>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>>>>> >>>>>>> Any kind of clock sync requirement
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your >>>>>>> offset technique and is more: reliable, straightforward, flexible. >>>>>>> >>>>>>> User agents that care about creating robust behavior for home desktops >>>>>>> or mobiles (presumably of users and OS not yet sophisticated enough to >>>>>>> check network time on their own) should be advised to do clock >>>>>>> correction on their own (by pinging a time service) and trusting the >>>>>>> device clock alone. >>>>>>> >>>>>>> Please change the spec back to using timestamp rather than age. >>>>>>> >>>>>>> I'd also like to hear a convincing argument from the Mozilla co-authors >>>>>>> about why they think that age is more resilient than the above (I >>>>>>> believe it is not) and further more why they would find the above >>>>>>> unattractive or difficult to implement in a modern user-agent. >>>>>>> >>>>>>> Thanks, >>>>>>> skylar >>>>>>> >>>>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- >>>>>>> -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>>>>>> skylar woodward >>>>>>> Kiva Developer Program / build.kiva.org / @buildkiva >>>>>>> >>>>>>> >>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>>>>>> >>>>>>>> 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 >>>&
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
The client should calculate the time of issue based on when it gets the credentials. Network delays should be accounted for by the server when allowing shifts in the nonce itself. EHL > -Original Message- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Tuesday, May 31, 2011 1:04 AM > To: Adam Barth > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > It seems we're failing to communicate. Or you're not understanding my use > cases. Age doesn't "just" work. It only works for a limited number of uses > cases that must include all of yours - and it is brittle at that. It doesn't > work > for any of our uses cases (where the client can't know issue_date w/o the > server telling it - in which case we have the equivalent problem as > timestamp). > > If you'd like to talk this out over Skype I'm happy to do that, so I can help > you > understand why age doesn't work. > > > > On May 31, 2011, at 9:47 AM, Adam Barth wrote: > > > Timestamps don't work when the client doesn't have a synchronized > > clock. It's true that a client could synchronize its clock with the > > network, but our implementation experience is that many clients don't > > for a variety of reasons. That means that age better because, you > > know, it works. > > > > Adam > > > > > > On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward > wrote: > >> I don't think you read my first message on the topic (or I wrote too much). > >> > >> Age is fragile because if the clock changes between issue_date and the > time of submission, it will fail. We know many people don't have > synchronized clocks, but using age only solves this problem if two > assumptions hold true: > >> > >> 1) the client is able to guess the issue_date the server is using > >> based on the time the credential was issued > >> 2) the client system clock doesn't change between issue date and > submission time. > >> > >> Timestamp has neither of these issues because the client can always > inquire about network time and can effectively correct for inaccuracies in the > device timekeeping system. > >> > >> Regarding the first assumption, this fails when a token might be re-issued > between devices. An example is that we use MAC token for the client > credentials, which are issued when a developer registers an application. The > client has no way of determining on its own when the value was actually > issued (unless we communicate that on the developer website and force > users to embed that with client_id, which adds usability issues of users > copying and entering string date values correctly). The same is actually true > for all of our OAuth access tokens because we reissue tokens to the same > client_id if they were previously issued and are still valid. (The client > would > thus think the issue_date was now() when if fact it was the time of the first > issue for client_id+scope+grantor_id). Thus, age is really just a convoluted > way of trying to communicate the device system offset: > >> > >>local_offset = current_server_time - current_device_time > >>age = current_device_time - (server_issue_date-local_offset) > >> > >> Since the protocol doesn't currently allow for server_issue_date to be > given with tokens, thus age currently can't have the resilience that > timestamp does. It also forces servers to issue new tokens on demand just > to make the convoluted age system work (rather than reuse existing valid > tokens). Or, you have to modify the protocol to add server_issue_date and > current_server_time into the token-issue exchange - eg, more complexity. > >> > >> Timestamp is simpler, proven, it and it has a solution for your use case of > unsyncronized clocks. > >> > >> skylar > >> > >> > >> On May 30, 2011, at 9:08 AM, Adam Barth wrote: > >> > >>> I can't speak for Mozilla, but I can tell you that many folks don't > >>> have synchronized clocks, for a wide variety of reasons. I guess I > >>> don't really understand why you view age as problematic. You > >>> reference "fragility of using time-since-credentials-issued" but you > >>> don't say what exactly is fragile about it. There's nothing > >>> particularly complex about age, especially when using the monotonic > >>> clock provided by all modern operating systems. > >>> > >>> A
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
ur >>>>>>> offset technique and is more: reliable, straightforward, flexible. >>>>>>> >>>>>>> User agents that care about creating robust behavior for home desktops >>>>>>> or mobiles (presumably of users and OS not yet sophisticated enough to >>>>>>> check network time on their own) should be advised to do clock >>>>>>> correction on their own (by pinging a time service) and trusting the >>>>>>> device clock alone. >>>>>>> >>>>>>> Please change the spec back to using timestamp rather than age. >>>>>>> >>>>>>> I'd also like to hear a convincing argument from the Mozilla co-authors >>>>>>> about why they think that age is more resilient than the above (I >>>>>>> believe it is not) and further more why they would find the above >>>>>>> unattractive or difficult to implement in a modern user-agent. >>>>>>> >>>>>>> Thanks, >>>>>>> skylar >>>>>>> >>>>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- >>>>>>> -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>>>>>> skylar woodward >>>>>>> Kiva Developer Program / build.kiva.org / @buildkiva >>>>>>> >>>>>>> >>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>>>>>> >>>>>>>> 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 Woodwar
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
exactly is fragile about it. There's nothing >>>>>>> particularly complex about age, especially when using the monotonic >>>>>>> clock provided by all modern operating systems. >>>>>>> >>>>>>> Adam >>>>>>> >>>>>>> >>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward >>>>>>> wrote: >>>>>>>> But see, now you are specializing the use of MAC token even more - now >>>>>>>> it's becoming a service mainly for user-agents on home desktops? This >>>>>>>> is further for the original goal of making MAC as flexible is >>>>>>>> possible. In this case you should change the spec name to >>>>>>>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or >>>>>>>> MTBCRLF for short. >>>>>>>> >>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your >>>>>>>> offset technique and is more: reliable, straightforward, flexible. >>>>>>>> >>>>>>>> User agents that care about creating robust behavior for home desktops >>>>>>>> or mobiles (presumably of users and OS not yet sophisticated enough to >>>>>>>> check network time on their own) should be advised to do clock >>>>>>>> correction on their own (by pinging a time service) and trusting the >>>>>>>> device clock alone. >>>>>>>> >>>>>>>> Please change the spec back to using timestamp rather than age. >>>>>>>> >>>>>>>> I'd also like to hear a convincing argument from the Mozilla >>>>>>>> co-authors about why they think that age is more resilient than the >>>>>>>> above (I believe it is not) and further more why they would find the >>>>>>>> above unattractive or difficult to implement in a modern user-agent. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> skylar >>>>>>>> >>>>>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- >>>>>>>> -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>>>>>>> skylar woodward >>>>>>>> Kiva Developer Program / build.kiva.org / @buildkiva >>>>>>>> >>>>>>>> >>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>>>>>>> >>>>>>>>> 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
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
mestamp is simpler, proven, it and it has a solution for your use >>>>>>> case of unsyncronized clocks. >>>>>>> >>>>>>> skylar >>>>>>> >>>>>>> >>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote: >>>>>>> >>>>>>>> I can't speak for Mozilla, but I can tell you that many folks don't >>>>>>>> have synchronized clocks, for a wide variety of reasons. I guess I >>>>>>>> don't really understand why you view age as problematic. You >>>>>>>> reference "fragility of using time-since-credentials-issued" but you >>>>>>>> don't say what exactly is fragile about it. There's nothing >>>>>>>> particularly complex about age, especially when using the monotonic >>>>>>>> clock provided by all modern operating systems. >>>>>>>> >>>>>>>> Adam >>>>>>>> >>>>>>>> >>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward >>>>>>>> wrote: >>>>>>>>> But see, now you are specializing the use of MAC token even more - >>>>>>>>> now it's becoming a service mainly for user-agents on home desktops? >>>>>>>>> This is further for the original goal of making MAC as flexible is >>>>>>>>> possible. In this case you should change the spec name to >>>>>>>>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or >>>>>>>>> MTBCRLF for short. >>>>>>>>> >>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your >>>>>>>>> offset technique and is more: reliable, straightforward, flexible. >>>>>>>>> >>>>>>>>> User agents that care about creating robust behavior for home >>>>>>>>> desktops or mobiles (presumably of users and OS not yet sophisticated >>>>>>>>> enough to check network time on their own) should be advised to do >>>>>>>>> clock correction on their own (by pinging a time service) and >>>>>>>>> trusting the device clock alone. >>>>>>>>> >>>>>>>>> Please change the spec back to using timestamp rather than age. >>>>>>>>> >>>>>>>>> I'd also like to hear a convincing argument from the Mozilla >>>>>>>>> co-authors about why they think that age is more resilient than the >>>>>>>>> above (I believe it is not) and further more why they would find the >>>>>>>>> above unattractive or difficult to implement in a modern user-agent. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> skylar >>>>>>>>> >>>>>>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- >>>>>>>>> -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>>>>>>>> skylar woodward >>>>>>>>> Kiva Developer Program / build.kiva.org / @buildkiva >>>>>>>>> >>>>>>>>> >>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>>>>>>>> >>>>>>>>>> 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 availabl
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
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 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
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
because we reissue tokens to the same client_id if they were >>>>>>>> previously issued and are still valid. (The client would thus think >>>>>>>> the issue_date was now() when if fact it was the time of the first >>>>>>>> issue for client_id+scope+grantor_id). Thus, age is really just a >>>>>>>> convoluted way of trying to communicate the device system offset: >>>>>>>> >>>>>>>> local_offset = current_server_time - current_device_time >>>>>>>> age = current_device_time - (server_issue_date-local_offset) >>>>>>>> >>>>>>>> Since the protocol doesn't currently allow for server_issue_date to be >>>>>>>> given with tokens, thus age currently can't have the resilience that >>>>>>>> timestamp does. It also forces servers to issue new tokens on demand >>>>>>>> just to make the convoluted age system work (rather than reuse >>>>>>>> existing valid tokens). Or, you have to modify the protocol to add >>>>>>>> server_issue_date and current_server_time into the token-issue >>>>>>>> exchange - eg, more complexity. >>>>>>>> >>>>>>>> Timestamp is simpler, proven, it and it has a solution for your use >>>>>>>> case of unsyncronized clocks. >>>>>>>> >>>>>>>> skylar >>>>>>>> >>>>>>>> >>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks don't >>>>>>>>> have synchronized clocks, for a wide variety of reasons. I guess I >>>>>>>>> don't really understand why you view age as problematic. You >>>>>>>>> reference "fragility of using time-since-credentials-issued" but you >>>>>>>>> don't say what exactly is fragile about it. There's nothing >>>>>>>>> particularly complex about age, especially when using the monotonic >>>>>>>>> clock provided by all modern operating systems. >>>>>>>>> >>>>>>>>> Adam >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> But see, now you are specializing the use of MAC token even more - >>>>>>>>>> now it's becoming a service mainly for user-agents on home desktops? >>>>>>>>>> This is further for the original goal of making MAC as flexible is >>>>>>>>>> possible. In this case you should change the spec name to >>>>>>>>>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or >>>>>>>>>> MTBCRLF for short. >>>>>>>>>> >>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your >>>>>>>>>> offset technique and is more: reliable, straightforward, flexible. >>>>>>>>>> >>>>>>>>>> User agents that care about creating robust behavior for home >>>>>>>>>> desktops or mobiles (presumably of users and OS not yet >>>>>>>>>> sophisticated enough to check network time on their own) should be >>>>>>>>>> advised to do clock correction on their own (by pinging a time >>>>>>>>>> service) and trusting the device clock alone. >>>>>>>>>> >>>>>>>>>> Please change the spec back to using timestamp rather than age. >>>>>>>>>> >>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla >>>>>>>>>> co-authors about why they think that age is more resilient than the >>>>>>>>>> above (I believe it is not) and further more why they would find the >>>>>>>>>> above unattractive or difficult to
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
gt;> re-issued between devices. An example is that we use MAC token for >>>>>>>>> the client credentials, which are issued when a developer registers >>>>>>>>> an application. The client has no way of determining on its own when >>>>>>>>> the value was actually issued (unless we communicate that on the >>>>>>>>> developer website and force users to embed that with client_id, which >>>>>>>>> adds usability issues of users copying and entering string date >>>>>>>>> values correctly). The same is actually true for all of our OAuth >>>>>>>>> access tokens because we reissue tokens to the same client_id if they >>>>>>>>> were previously issued and are still valid. (The client would thus >>>>>>>>> think the issue_date was now() when if fact it was the time of the >>>>>>>>> first issue for client_id+scope+grantor_id). Thus, age is really just >>>>>>>>> a convoluted way of trying to communicate the device system offset: >>>>>>>>> >>>>>>>>> local_offset = current_server_time - current_device_time >>>>>>>>> age = current_device_time - (server_issue_date-local_offset) >>>>>>>>> >>>>>>>>> Since the protocol doesn't currently allow for server_issue_date to >>>>>>>>> be given with tokens, thus age currently can't have the resilience >>>>>>>>> that timestamp does. It also forces servers to issue new tokens on >>>>>>>>> demand just to make the convoluted age system work (rather than reuse >>>>>>>>> existing valid tokens). Or, you have to modify the protocol to add >>>>>>>>> server_issue_date and current_server_time into the token-issue >>>>>>>>> exchange - eg, more complexity. >>>>>>>>> >>>>>>>>> Timestamp is simpler, proven, it and it has a solution for your use >>>>>>>>> case of unsyncronized clocks. >>>>>>>>> >>>>>>>>> skylar >>>>>>>>> >>>>>>>>> >>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks don't >>>>>>>>>> have synchronized clocks, for a wide variety of reasons. I guess I >>>>>>>>>> don't really understand why you view age as problematic. You >>>>>>>>>> reference "fragility of using time-since-credentials-issued" but you >>>>>>>>>> don't say what exactly is fragile about it. There's nothing >>>>>>>>>> particularly complex about age, especially when using the monotonic >>>>>>>>>> clock provided by all modern operating systems. >>>>>>>>>> >>>>>>>>>> Adam >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> But see, now you are specializing the use of MAC token even more - >>>>>>>>>>> now it's becoming a service mainly for user-agents on home >>>>>>>>>>> desktops? This is further for the original goal of making MAC as >>>>>>>>>>> flexible is possible. In this case you should change the spec name >>>>>>>>>>> to MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX >>>>>>>>>>> - or MTBCRLF for short. >>>>>>>>>>> >>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your >>>>>>>>>>> offset technique and is more: reliable, straightforward, flexible. >>>>>>>>>>> >>>>>>>>>>> User agents that care about creating robust behavior for home >>>>>>>>>>> desktops or mobiles (pre
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Igor Faynberg > Sent: Tuesday, May 31, 2011 3:50 PM > To: Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > ...Sorry to turn the question around so as to underline my pet peeve: > Have we *documented* all cases? (This is what the Use Cases document is > supposed to be all about.) > > Just to clarify: I am not arguing with Phil's point now. I just stress that > as of > this moment we don't have anything to check against. > > Igor > > Phil Hunt wrote: > > There seems to be a demonstrated need for both age and timestamp > tokens. > > > > The list has 2 separate cases with 2 separate proposals that do not solve > > all > cases. > > > > Can we at least agree that neither proposal works in all cases? > > > > Phil > > > > @independentid > > www.independentid.com > > phil.h...@oracle.com > > > > > > > > > > > > On 2011-05-31, at 2:41 PM, Adam Barth wrote: > > > > > >> You haven't described a problem. > >> > >> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward > wrote: > >> > >>> First we should agree on a common understanding of the spec. The > reason why age works with unsynchronized clocks is that the client > determines issue_date based on the time when it receives the token over > the wire. This depends on the server and client both recording time this way > and for the transmission of the token to be be not longer than the margin of > error for validating age. Are we agreed on this understanding? > >>> > >> That's not correct. > >> > >> The age allows the server to protect against replay attacks in > >> bounded memory. With unbounded memory, the server can just > remember > >> every nonce it has ever seen associated with a given key and reject > replays. > >> With bounded memory, the server eventually needs to evict some of > >> these nonces due to memory pressure. The age value lets the server > >> reject the nonces with the smallest age values first. The server > >> then rejects any messages with age values smaller than (or equal to) > >> the largest age value it has ever evicted for the given key. > >> > >> Notice that neither clock synchronization nor transmission time plays > >> a role in that implementation. > >> > >> > >>> The easiest case for me to explain here is client credentials because I > have to assume you've built and registered a Twitter app at some point (or > similar OAuth 1.0a app). You registered your app on the site and were issued > a client_id and client_secret (called consumer_key and consumer_secret in > 1.0). You then embedded these values in your client (they were not issued > programmatically to your app). Assuming the MAC token algorithm is used > then for establishing client identity (originally one of the uses we, the > working group, hoped MAC would cover) how then will your client > determine issue date? > >>> > >> I recommend the date at which the developer obtained the credential > >> from Twitter because that is the date when the credential was issued. > >> > >> > >>> After we can establish where you're at on the two above points I'll > continue with the explanation. But as a preview, the next points would be: > >>> > >>> - If issue_date comes form the server, how is it translated to the client? > >>> > >> The issue_date does not come from the server. > >> > >> > >>> - If you use a server provided issue_date, how do you then translate > that a value relative to the local unsyncronized clock? > >>> > >> The server does not provide the issue_date. > >> > >> > >>> - If your answer to that is to also provide the current server time to the > client so the offset on the server provided issue_date can be calculated what > is the difference between all of these values and just using timestamp? > >>> > >> My answer is not to provide the current server time to the client. > >> > >> Kind regards, > >> Adam > >> > >> > >> > >>> So don't get wrapped up in those 3 questions until we establish your > co
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Adam and I have discussed a proposal which should address everyone's use cases. I will post shortly. Just FYI so people don't invest too much time in this thread... EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phil Hunt > Sent: Tuesday, May 31, 2011 3:35 PM > To: Adam Barth > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > There seems to be a demonstrated need for both age and timestamp > tokens. > > The list has 2 separate cases with 2 separate proposals that do not solve all > cases. > > Can we at least agree that neither proposal works in all cases? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011-05-31, at 2:41 PM, Adam Barth wrote: > > > You haven't described a problem. > > > > On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward > wrote: > >> First we should agree on a common understanding of the spec. The > reason why age works with unsynchronized clocks is that the client > determines issue_date based on the time when it receives the token over > the wire. This depends on the server and client both recording time this way > and for the transmission of the token to be be not longer than the margin of > error for validating age. Are we agreed on this understanding? > > > > That's not correct. > > > > The age allows the server to protect against replay attacks in bounded > > memory. With unbounded memory, the server can just remember every > > nonce it has ever seen associated with a given key and reject replays. > > With bounded memory, the server eventually needs to evict some of > > these nonces due to memory pressure. The age value lets the server > > reject the nonces with the smallest age values first. The server then > > rejects any messages with age values smaller than (or equal to) the > > largest age value it has ever evicted for the given key. > > > > Notice that neither clock synchronization nor transmission time plays > > a role in that implementation. > > > >> The easiest case for me to explain here is client credentials because I > >> have > to assume you've built and registered a Twitter app at some point (or similar > OAuth 1.0a app). You registered your app on the site and were issued a > client_id and client_secret (called consumer_key and consumer_secret in > 1.0). You then embedded these values in your client (they were not issued > programmatically to your app). Assuming the MAC token algorithm is used > then for establishing client identity (originally one of the uses we, the > working group, hoped MAC would cover) how then will your client > determine issue date? > > > > I recommend the date at which the developer obtained the credential > > from Twitter because that is the date when the credential was issued. > > > >> After we can establish where you're at on the two above points I'll > continue with the explanation. But as a preview, the next points would be: > >> > >> - If issue_date comes form the server, how is it translated to the client? > > > > The issue_date does not come from the server. > > > >> - If you use a server provided issue_date, how do you then translate that > a value relative to the local unsyncronized clock? > > > > The server does not provide the issue_date. > > > >> - If your answer to that is to also provide the current server time to the > client so the offset on the server provided issue_date can be calculated what > is the difference between all of these values and just using timestamp? > > > > My answer is not to provide the current server time to the client. > > > > Kind regards, > > Adam > > > > > >> So don't get wrapped up in those 3 questions until we establish your > contextual understanding of the first two paragraphs. Feel free to also > respond to me off the list so we don't trouble everyone else with us getting > on the same page (the reason, I thought, why a Skype call would be more > efficient and painless). I do think my explanations all have been very clear > thus far. There must be a contextual confusion that is keeping us from a > common understanding of the terminology or the use cases. > >> > >> skylar > >> > >> > >> On May 31, 2011, at 10:30 AM, Adam Barth wrote: > >> > >>> I'm not sure we need a Skype call. Can you explain the trouble > >>> caused by age clearly? I didn't understand your p
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Maybe... But this information must be captured somewhere, right? At the moment, there seems to be no record of and consequently no reference point to the use case in question. And this is what has created all this discussion--with messages coming from all directions. Igor Eran Hammer-Lahav wrote: I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor Faynberg Sent: Tuesday, May 31, 2011 3:50 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token ...Sorry to turn the question around so as to underline my pet peeve: Have we *documented* all cases? (This is what the Use Cases document is supposed to be all about.) Just to clarify: I am not arguing with Phil's point now. I just stress that as of this moment we don't have anything to check against. Igor Phil Hunt wrote: There seems to be a demonstrated need for both age and timestamp tokens. The list has 2 separate cases with 2 separate proposals that do not solve all cases. Can we at least agree that neither proposal works in all cases? Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-05-31, at 2:41 PM, Adam Barth wrote: You haven't described a problem. On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward wrote: First we should agree on a common understanding of the spec. The reason why age works with unsynchronized clocks is that the client determines issue_date based on the time when it receives the token over the wire. This depends on the server and client both recording time this way and for the transmission of the token to be be not longer than the margin of error for validating age. Are we agreed on this understanding? That's not correct. The age allows the server to protect against replay attacks in bounded memory. With unbounded memory, the server can just remember every nonce it has ever seen associated with a given key and reject replays. With bounded memory, the server eventually needs to evict some of these nonces due to memory pressure. The age value lets the server reject the nonces with the smallest age values first. The server then rejects any messages with age values smaller than (or equal to) the largest age value it has ever evicted for the given key. Notice that neither clock synchronization nor transmission time plays a role in that implementation. The easiest case for me to explain here is client credentials because I have to assume you've built and registered a Twitter app at some point (or similar OAuth 1.0a app). You registered your app on the site and were issued a client_id and client_secret (called consumer_key and consumer_secret in 1.0). You then embedded these values in your client (they were not issued programmatically to your app). Assuming the MAC token algorithm is used then for establishing client identity (originally one of the uses we, the working group, hoped MAC would cover) how then will your client determine issue date? I recommend the date at which the developer obtained the credential from Twitter because that is the date when the credential was issued. After we can establish where you're at on the two above points I'll continue with the explanation. But as a preview, the next points would be: - If issue_date comes form the server, how is it translated to the client? The issue_date does not come from the server. - If you use a server provided issue_date, how do you then translate that a value relative to the local unsyncronized clock? The server does not provide the issue_date. - If your answer to that is to also provide the current server time to the client so the offset on the server provided issue_date can be calculated what is the difference between all of these values and just using timestamp? My answer is not to provide the current server time to the client. Kind regards, Adam So don't get wrapped up in those 3 questions until we establish your contextual understanding of the first two paragraphs. Feel free to also respond to me off the list so we don't trouble everyone else with us getting on the same page (the reason, I thought, why a Skype call would be more efficient and painless). I do think my explanations all have been very clear thus far. There must be a contextual confusion that is keeping us from a common understanding of the terminology or the use cases. skylar On May 31, 2011, at 10:30 AM, Adam Barth wrote: I'm not sure we need a Skype call. Can you ex
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Yes, but I think my case is very important (eg, being able to use a MAC token as a client credential). I don't understand why Adam can't comprehend my explanation. My best guess is this is some kind of political game on his front to protect the age specification yet I don't understand any motivation for being so close-minded. His reply to my last thread was completely disrespectful and ignorant. Unless I've made him mad or offended him in some way I see no excuse for this behavior. I'm going to make one more attempt to try to explain this to him over email. After that I recommend a Skype call (hopefully brief) or I will work offline with Eran to see if we can find some solution. Btw, in addition to the use case of using MAC tokens for client credentials, we also have the use case of re-issuing a valid token multiple times to instances of the same client. (eg, the value of ID and secret are constant across multiple transmissions to client instances). Thanks, skylar On Jun 1, 2011, at 2:00 AM, Eran Hammer-Lahav wrote: > I think the use case document should focus on v2, not on MAC. At some point, > it becomes impractical to keep every use case discussed on this list recorded. > > EHL > >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Igor Faynberg >> Sent: Tuesday, May 31, 2011 3:50 PM >> To: Phil Hunt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token >> >> ...Sorry to turn the question around so as to underline my pet peeve: >> Have we *documented* all cases? (This is what the Use Cases document is >> supposed to be all about.) >> >> Just to clarify: I am not arguing with Phil's point now. I just stress that >> as of >> this moment we don't have anything to check against. >> >> Igor >> >> Phil Hunt wrote: >>> There seems to be a demonstrated need for both age and timestamp >> tokens. >>> >>> The list has 2 separate cases with 2 separate proposals that do not solve >>> all >> cases. >>> >>> Can we at least agree that neither proposal works in all cases? >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.h...@oracle.com >>> >>> >>> >>> >>> >>> On 2011-05-31, at 2:41 PM, Adam Barth wrote: >>> >>> >>>> You haven't described a problem. >>>> >>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward >> wrote: >>>> >>>>> First we should agree on a common understanding of the spec. The >> reason why age works with unsynchronized clocks is that the client >> determines issue_date based on the time when it receives the token over >> the wire. This depends on the server and client both recording time this way >> and for the transmission of the token to be be not longer than the margin of >> error for validating age. Are we agreed on this understanding? >>>>> >>>> That's not correct. >>>> >>>> The age allows the server to protect against replay attacks in >>>> bounded memory. With unbounded memory, the server can just >> remember >>>> every nonce it has ever seen associated with a given key and reject >> replays. >>>> With bounded memory, the server eventually needs to evict some of >>>> these nonces due to memory pressure. The age value lets the server >>>> reject the nonces with the smallest age values first. The server >>>> then rejects any messages with age values smaller than (or equal to) >>>> the largest age value it has ever evicted for the given key. >>>> >>>> Notice that neither clock synchronization nor transmission time plays >>>> a role in that implementation. >>>> >>>> >>>>> The easiest case for me to explain here is client credentials because I >> have to assume you've built and registered a Twitter app at some point (or >> similar OAuth 1.0a app). You registered your app on the site and were issued >> a client_id and client_secret (called consumer_key and consumer_secret in >> 1.0). You then embedded these values in your client (they were not issued >> programmatically to your app). Assuming the MAC token algorithm is used >> then for establishing client identity (originally one of the uses we, the >> working group, hoped MAC would cover) how then will your client >> determine issue date? >>>>>
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
On May 31, 2011, at 11:41 PM, Adam Barth wrote: > You haven't described a problem. Maybe so, but I guess you can't see yet where this is going, or you are ignoring it intentionally. I did preface this letter that I wanted to understand your perspective on this two points before attempting to continue the discussion. Let's try to move forward with your answer to the second question. > > On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward wrote: >> First we should agree on a common understanding of the spec. The reason why >> age works with unsynchronized clocks is that the client determines >> issue_date based on the time when it receives the token over the wire. This >> depends on the server and client both recording time this way and for the >> transmission of the token to be be not longer than the margin of error for >> validating age. Are we agreed on this understanding? > > That's not correct. > > The age allows the server to protect against replay attacks in bounded > memory. With unbounded memory, the server can just remember every > nonce it has ever seen associated with a given key and reject replays. > With bounded memory, the server eventually needs to evict some of > these nonces due to memory pressure. The age value lets the server > reject the nonces with the smallest age values first. The server then > rejects any messages with age values smaller than (or equal to) the > largest age value it has ever evicted for the given key. > > Notice that neither clock synchronization nor transmission time plays > a role in that implementation. > Yes, but this isn't a implementation we've yet considered and it isn't the one suggested by the spec. The spec states: "To avoid the need to retain an infinite number of nonce values for future checks, the server MAY choose to restrict the time period after which a request with an old age is rejected." This text is analogous to the text originally used for timestamp in which case "old" is relative to current time. By this text, I also understand age to be relative to the current time of the device constructing or validating the value. If "old" means relative to previous values seen by the server then the this text should be made more clear. However, if this how you expect age to be used to invalidate old nonce history then timestamp is much simpler. The client can use any value so long as it makes sure that subsequent values come after previous values. It can keep a counter going from 0 upwards, or it can use some upward moving counter relative to its device (eg local clock). In fact, this is the more common definition used by most protocols using a timestamp. It is often merely a suggestion that current time be used for this value to avoid extra record-keeping on the part of the client. So if this is your intent you can simplify the specification of "age" by suggesting the client pick an arbitrary start point, but make no mention of it needing to be within a proximity of the server's understanding of the same start point. Unfortunately though, this implementation doesn't help my use cases because such sequential requirement of a timestamp/age requires all devices with the token to be in sync as to the value of timestamp/age. So let's move on. >> The easiest case for me to explain here is client credentials because I have >> to assume you've built and registered a Twitter app at some point (or >> similar OAuth 1.0a app). You registered your app on the site and were issued >> a client_id and client_secret (called consumer_key and consumer_secret in >> 1.0). You then embedded these values in your client (they were not issued >> programmatically to your app). Assuming the MAC token algorithm is used then >> for establishing client identity (originally one of the uses we, the working >> group, hoped MAC would cover) how then will your client determine issue date? > > I recommend the date at which the developer obtained the credential > from Twitter because that is the date when the credential was issued. Okay, so this value was issued from the server to a developer account, not directly to the client software. How do you then propose the time is communicated to the client software program in a way where the date of issuance is relative to the clock on that device (not to the device holding the developer account data). For example, if the client credential was issued at time 2120 but is then installed with a client program on a device who thinks the current time is 630 then age is already negative (2120-630). How to translate 2120 from the date the developer obtained the credential to the translation of that date on a user device where the clock is significantly behind that of the developer services server (eg, dev.twitter.com) or even that of the local developer's box? skylar ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
They are coming in 2-3 directions, the use case isn't really clear (other than claims of some flavors being harder than others), and overall this is more about general HTTP authentication than OAuth use cases. Don't get me wrong - if you want to put the effort in to capture these, go ahead. I just think this isn't worth the effort in a formal document. EHL > -Original Message- > From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] > Sent: Tuesday, May 31, 2011 6:15 PM > To: Eran Hammer-Lahav > Cc: Phil Hunt; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > Maybe... But this information must be captured somewhere, right? > > At the moment, there seems to be no record of and consequently no > reference point to the use case in question. And this is what has created all > this discussion--with messages coming from all directions. > > Igor > > Eran Hammer-Lahav wrote: > > I think the use case document should focus on v2, not on MAC. At some > point, it becomes impractical to keep every use case discussed on this list > recorded. > > > > EHL > > > > > >> -Original Message- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> Behalf Of Igor Faynberg > >> Sent: Tuesday, May 31, 2011 3:50 PM > >> To: Phil Hunt > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >> token > >> > >> ...Sorry to turn the question around so as to underline my pet peeve: > >> Have we *documented* all cases? (This is what the Use Cases document > >> is supposed to be all about.) > >> > >> Just to clarify: I am not arguing with Phil's point now. I just > >> stress that as of this moment we don't have anything to check against. > >> > >> Igor > >> > >> Phil Hunt wrote: > >> > >>> There seems to be a demonstrated need for both age and timestamp > >>> > >> tokens. > >> > >>> The list has 2 separate cases with 2 separate proposals that do not > >>> solve all > >>> > >> cases. > >> > >>> Can we at least agree that neither proposal works in all cases? > >>> > >>> Phil > >>> > >>> @independentid > >>> www.independentid.com > >>> phil.h...@oracle.com > >>> > >>> > >>> > >>> > >>> > >>> On 2011-05-31, at 2:41 PM, Adam Barth wrote: > >>> > >>> > >>> > >>>> You haven't described a problem. > >>>> > >>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward > >>>> > >> wrote: > >> > >>>>> First we should agree on a common understanding of the spec. The > >>>>> > >> reason why age works with unsynchronized clocks is that the client > >> determines issue_date based on the time when it receives the token > >> over the wire. This depends on the server and client both recording > >> time this way and for the transmission of the token to be be not > >> longer than the margin of error for validating age. Are we agreed on this > understanding? > >> > >>>> That's not correct. > >>>> > >>>> The age allows the server to protect against replay attacks in > >>>> bounded memory. With unbounded memory, the server can just > >>>> > >> remember > >> > >>>> every nonce it has ever seen associated with a given key and reject > >>>> > >> replays. > >> > >>>> With bounded memory, the server eventually needs to evict some of > >>>> these nonces due to memory pressure. The age value lets the server > >>>> reject the nonces with the smallest age values first. The server > >>>> then rejects any messages with age values smaller than (or equal > >>>> to) the largest age value it has ever evicted for the given key. > >>>> > >>>> Notice that neither clock synchronization nor transmission time > >>>> plays a role in that implementation. > >>>> > >>>> > >>>> > >>>>> The easiest case for me to explain here is client credentials > >>>>> because I > >>>>> > >> have to assume you've built and registered a Twitter app at some > >> point (
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
No need to get worked up. I'm sure Adam didn't mean to offend - that's just his style (speaking as someone who is considered much less polite by a landslide). I don't think you have made the case why you age is any harder to implement than a timestamp. It is not that your email isn't clear, it's that we're not convinced that timestamp will produce any better result than age in practice. This is purely technical, not political. However, we did come up with a solution that should cover all bases. I do strongly object to making this protocol configurable. Configurable authentication schemes are by definition complex and right now MAC is amazingly simple. EHL > -Original Message- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Tuesday, May 31, 2011 10:14 PM > To: Eran Hammer-Lahav > Cc: igor.faynb...@alcatel-lucent.com; Phil Hunt; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > Yes, but I think my case is very important (eg, being able to use a MAC token > as a client credential). I don't understand why Adam can't comprehend my > explanation. My best guess is this is some kind of political game on his front > to protect the age specification yet I don't understand any motivation for > being so close-minded. His reply to my last thread was completely > disrespectful and ignorant. Unless I've made him mad or offended him in > some way I see no excuse for this behavior. > > I'm going to make one more attempt to try to explain this to him over email. > After that I recommend a Skype call (hopefully brief) or I will work offline > with Eran to see if we can find some solution. > > Btw, in addition to the use case of using MAC tokens for client credentials, > we also have the use case of re-issuing a valid token multiple times to > instances of the same client. (eg, the value of ID and secret are constant > across multiple transmissions to client instances). > > Thanks, > skylar > > On Jun 1, 2011, at 2:00 AM, Eran Hammer-Lahav wrote: > > > I think the use case document should focus on v2, not on MAC. At some > point, it becomes impractical to keep every use case discussed on this list > recorded. > > > > EHL > > > >> -Original Message- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> Behalf Of Igor Faynberg > >> Sent: Tuesday, May 31, 2011 3:50 PM > >> To: Phil Hunt > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >> token > >> > >> ...Sorry to turn the question around so as to underline my pet peeve: > >> Have we *documented* all cases? (This is what the Use Cases document > >> is supposed to be all about.) > >> > >> Just to clarify: I am not arguing with Phil's point now. I just > >> stress that as of this moment we don't have anything to check against. > >> > >> Igor > >> > >> Phil Hunt wrote: > >>> There seems to be a demonstrated need for both age and timestamp > >> tokens. > >>> > >>> The list has 2 separate cases with 2 separate proposals that do not > >>> solve all > >> cases. > >>> > >>> Can we at least agree that neither proposal works in all cases? > >>> > >>> Phil > >>> > >>> @independentid > >>> www.independentid.com > >>> phil.h...@oracle.com > >>> > >>> > >>> > >>> > >>> > >>> On 2011-05-31, at 2:41 PM, Adam Barth wrote: > >>> > >>> > >>>> You haven't described a problem. > >>>> > >>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward > >> wrote: > >>>> > >>>>> First we should agree on a common understanding of the spec. The > >> reason why age works with unsynchronized clocks is that the client > >> determines issue_date based on the time when it receives the token > >> over the wire. This depends on the server and client both recording > >> time this way and for the transmission of the token to be be not > >> longer than the margin of error for validating age. Are we agreed on this > understanding? > >>>>> > >>>> That's not correct. > >>>> > >>>> The age allows the server to protect against replay attacks in > >>>> bounded memory. With unbounded memory, the server can just > >> remember > >>>> every nonce
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Eran, sorry, where should use cases be officially documented? I assume the use cases being more like "HTTP Auth" are not in reference to the ones I've been describing. For my part, I'm focused on OAuth use cases. Both that of a single token being used on multiple devices (or app instances) and that of tokens being presented for client credentials in the OAuth flow. I thought we had already agreed from a previous thread that the MAC token spec should be extensible beyond just use of access tokens and at least to that of client credentials. skylar On Jun 1, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: > They are coming in 2-3 directions, the use case isn't really clear (other > than claims of some flavors being harder than others), and overall this is > more about general HTTP authentication than OAuth use cases. Don't get me > wrong - if you want to put the effort in to capture these, go ahead. I just > think this isn't worth the effort in a formal document. > > EHL > >> -Original Message- >> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] >> Sent: Tuesday, May 31, 2011 6:15 PM >> To: Eran Hammer-Lahav >> Cc: Phil Hunt; OAuth WG >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token >> >> Maybe... But this information must be captured somewhere, right? >> >> At the moment, there seems to be no record of and consequently no >> reference point to the use case in question. And this is what has created all >> this discussion--with messages coming from all directions. >> >> Igor >> >> Eran Hammer-Lahav wrote: >>> I think the use case document should focus on v2, not on MAC. At some >> point, it becomes impractical to keep every use case discussed on this list >> recorded. >>> >>> EHL >>> >>> >>>> -----Original Message----- >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >>>> Behalf Of Igor Faynberg >>>> Sent: Tuesday, May 31, 2011 3:50 PM >>>> To: Phil Hunt >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC >>>> token >>>> >>>> ...Sorry to turn the question around so as to underline my pet peeve: >>>> Have we *documented* all cases? (This is what the Use Cases document >>>> is supposed to be all about.) >>>> >>>> Just to clarify: I am not arguing with Phil's point now. I just >>>> stress that as of this moment we don't have anything to check against. >>>> >>>> Igor >>>> >>>> Phil Hunt wrote: >>>> >>>>> There seems to be a demonstrated need for both age and timestamp >>>>> >>>> tokens. >>>> >>>>> The list has 2 separate cases with 2 separate proposals that do not >>>>> solve all >>>>> >>>> cases. >>>> >>>>> Can we at least agree that neither proposal works in all cases? >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.h...@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote: >>>>> >>>>> >>>>> >>>>>> You haven't described a problem. >>>>>> >>>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward >>>>>> >>>> wrote: >>>> >>>>>>> First we should agree on a common understanding of the spec. The >>>>>>> >>>> reason why age works with unsynchronized clocks is that the client >>>> determines issue_date based on the time when it receives the token >>>> over the wire. This depends on the server and client both recording >>>> time this way and for the transmission of the token to be be not >>>> longer than the margin of error for validating age. Are we agreed on this >> understanding? >>>> >>>>>> That's not correct. >>>>>> >>>>>> The age allows the server to protect against replay attacks in >>>>>> bounded memory. With unbounded memory, the server can just >>>>>> >>>> remember >>>> >>>>>> every nonce it has ever seen associated with a given k
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
On Jun 1, 2011, at 7:58 AM, Eran Hammer-Lahav wrote: > I don't think you have made the case why you age is any harder to implement > than a timestamp. It is not that your email isn't clear, it's that we're not > convinced that timestamp will produce any better result than age in practice. > This is purely technical, not political. That's no longer my point. I've now realized it doesn't work for all of my uses for MAC token (assuming we validate age, either by the implementation Adam suggested or by the one I had assumed where age is judged "old" by comparing to a device system time). Let me know if my latest response to Adam doesn't it make it clear why this does not work for either client credentials or a token issued to multiple instances of a client. If not, I'll continue attempting to explain myself. I also would like to see the specification not to be configurable. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
No, no, my little "I told you so" aside, I don't insist on putting this in the document, especially that we have already agreed that the use case document is a post-2.0 issue. I think that for the purposes of the discussion on this thread it would help if all the use cases in question were clearly described--if only in an e-mail for now. Then it would be a matter of logic to see if there is a problem, and if there is one, what the solutions to it might be. Igor Eran Hammer-Lahav wrote: They are coming in 2-3 directions, the use case isn't really clear (other than claims of some flavors being harder than others), and overall this is more about general HTTP authentication than OAuth use cases. Don't get me wrong - if you want to put the effort in to capture these, go ahead. I just think this isn't worth the effort in a formal document. EHL -Original Message- From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] Sent: Tuesday, May 31, 2011 6:15 PM To: Eran Hammer-Lahav Cc: Phil Hunt; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Maybe... But this information must be captured somewhere, right? At the moment, there seems to be no record of and consequently no reference point to the use case in question. And this is what has created all this discussion--with messages coming from all directions. Igor Eran Hammer-Lahav wrote: I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor Faynberg Sent: Tuesday, May 31, 2011 3:50 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token ...Sorry to turn the question around so as to underline my pet peeve: Have we *documented* all cases? (This is what the Use Cases document is supposed to be all about.) Just to clarify: I am not arguing with Phil's point now. I just stress that as of this moment we don't have anything to check against. Igor Phil Hunt wrote: There seems to be a demonstrated need for both age and timestamp tokens. The list has 2 separate cases with 2 separate proposals that do not solve all cases. Can we at least agree that neither proposal works in all cases? Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-05-31, at 2:41 PM, Adam Barth wrote: You haven't described a problem. On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward wrote: First we should agree on a common understanding of the spec. The reason why age works with unsynchronized clocks is that the client determines issue_date based on the time when it receives the token over the wire. This depends on the server and client both recording time this way and for the transmission of the token to be be not longer than the margin of error for validating age. Are we agreed on this understanding? That's not correct. The age allows the server to protect against replay attacks in bounded memory. With unbounded memory, the server can just remember every nonce it has ever seen associated with a given key and reject replays. With bounded memory, the server eventually needs to evict some of these nonces due to memory pressure. The age value lets the server reject the nonces with the smallest age values first. The server then rejects any messages with age values smaller than (or equal to) the largest age value it has ever evicted for the given key. Notice that neither clock synchronization nor transmission time plays a role in that implementation. The easiest case for me to explain here is client credentials because I have to assume you've built and registered a Twitter app at some point (or similar OAuth 1.0a app). You registered your app on the site and were issued a client_id and client_secret (called consumer_key and consumer_secret in 1.0). You then embedded these values in your client (they were not issued programmatically to your app). Assuming the MAC token algorithm is used then for establishing client identity (originally one of the uses we, the working group, hoped MAC would cover) how then will your client determine issue date? I recommend the date at which the developer obtained the credential from Twitter because that is the date when the credential was issued. After we can establish where you're at on the two above points I'll continue with the explanation. But as a preview, the next points would be: - If issue_date comes form the server, how is it translated to the
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Yeah, sorry, I didn't mean to offend you Skylar. Your suggested approach is similar to the approach Eran alluded to earlier. Hopefully he'll have some new text that will work for your use case (which I still don't fully understand). Adam On Tue, May 31, 2011 at 10:58 PM, Eran Hammer-Lahav wrote: > No need to get worked up. I'm sure Adam didn't mean to offend - that's just > his style (speaking as someone who is considered much less polite by a > landslide). > > I don't think you have made the case why you age is any harder to implement > than a timestamp. It is not that your email isn't clear, it's that we're not > convinced that timestamp will produce any better result than age in practice. > This is purely technical, not political. > > However, we did come up with a solution that should cover all bases. > > I do strongly object to making this protocol configurable. Configurable > authentication schemes are by definition complex and right now MAC is > amazingly simple. > > EHL > >> -Original Message- >> From: Skylar Woodward [mailto:sky...@kiva.org] >> Sent: Tuesday, May 31, 2011 10:14 PM >> To: Eran Hammer-Lahav >> Cc: igor.faynb...@alcatel-lucent.com; Phil Hunt; OAuth WG >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token >> >> Yes, but I think my case is very important (eg, being able to use a MAC token >> as a client credential). I don't understand why Adam can't comprehend my >> explanation. My best guess is this is some kind of political game on his >> front >> to protect the age specification yet I don't understand any motivation for >> being so close-minded. His reply to my last thread was completely >> disrespectful and ignorant. Unless I've made him mad or offended him in >> some way I see no excuse for this behavior. >> >> I'm going to make one more attempt to try to explain this to him over email. >> After that I recommend a Skype call (hopefully brief) or I will work offline >> with Eran to see if we can find some solution. >> >> Btw, in addition to the use case of using MAC tokens for client credentials, >> we also have the use case of re-issuing a valid token multiple times to >> instances of the same client. (eg, the value of ID and secret are constant >> across multiple transmissions to client instances). >> >> Thanks, >> skylar >> >> On Jun 1, 2011, at 2:00 AM, Eran Hammer-Lahav wrote: >> >> > I think the use case document should focus on v2, not on MAC. At some >> point, it becomes impractical to keep every use case discussed on this list >> recorded. >> > >> > EHL >> > >> >> -Original Message- >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >> >> Behalf Of Igor Faynberg >> >> Sent: Tuesday, May 31, 2011 3:50 PM >> >> To: Phil Hunt >> >> Cc: OAuth WG >> >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC >> >> token >> >> >> >> ...Sorry to turn the question around so as to underline my pet peeve: >> >> Have we *documented* all cases? (This is what the Use Cases document >> >> is supposed to be all about.) >> >> >> >> Just to clarify: I am not arguing with Phil's point now. I just >> >> stress that as of this moment we don't have anything to check against. >> >> >> >> Igor >> >> >> >> Phil Hunt wrote: >> >>> There seems to be a demonstrated need for both age and timestamp >> >> tokens. >> >>> >> >>> The list has 2 separate cases with 2 separate proposals that do not >> >>> solve all >> >> cases. >> >>> >> >>> Can we at least agree that neither proposal works in all cases? >> >>> >> >>> Phil >> >>> >> >>> @independentid >> >>> www.independentid.com >> >>> phil.h...@oracle.com >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On 2011-05-31, at 2:41 PM, Adam Barth wrote: >> >>> >> >>> >> >>>> You haven't described a problem. >> >>>> >> >>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward >> >> wrote: >> >>>> >> >>>>> First we should agree on a common understanding of the spec. The >> >>
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
> -Original Message- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Tuesday, May 31, 2011 10:54 PM > Unfortunately though, this implementation doesn't help my use cases > because such sequential requirement of a timestamp/age requires all > devices with the token to be in sync as to the value of timestamp/age. So > let's move on. This is not true. The age value has to be monotonically increasing, but not necessarily unique. Really, any counter will do. The reason why timestamp isn't any better than age or sequence is because ultimately, it is the server's memory restriction which determines the nonces storage size, not anything else (like a time limit). I am going to change the spec to define age as any 'monotonically increasing, but not necessarily unique' positive numerical value, and give timestamp and time-since-received as two examples, along with a counter. It will also specify that if the numerical value is time-based, it MUST use seconds precision. This should provide a practical solution to everyone. When the first request comes in, it goes into storage. When the second one comes, you check if its numerical part is equal or greater than the one you previously received. If the number is smaller, you should allow for some margin in case the client is using time-based value, otherwise you reject the request. Once the storage fills, you evict the nonces with the smallest numerical values as needed. The storage size should match the speed in which clients transmit requests. Unlike timestamps, the margin can be very small, like 60 seconds, because this is time-sync across *client* machines, not the client and server. It is perfectly reasonable to expect a client sharing the same MAC credentials across multiple machines to implement clock sync keeping all machines less than a minute apart. Any kind of storage-limited nonce-checking is going to fail sometimes even for valid requests because of how the numerical part is generated and how much storage the server has (across all clients). I think this is a very reasonable compromise that in practice, will produce good results with little complexity and plenty of flexibility. The alternatives presented so far (using timestamps or offering multiple options) will fail completely for the primary use cases this specification was written for. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
> -Original Message- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Tuesday, May 31, 2011 11:03 PM > To: Eran Hammer-Lahav > Cc: igor.faynb...@alcatel-lucent.com; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > Eran, sorry, where should use cases be officially documented? This list seems a fine enough place. I have no problem keeping track. > I assume the use cases being more like "HTTP Auth" are not in reference to > the ones I've been describing. For my part, I'm focused on OAuth use cases. > Both that of a single token being used on multiple devices (or app instances) > and that of tokens being presented for client credentials in the OAuth flow. I > thought we had already agreed from a previous thread that the MAC token > spec should be extensible beyond just use of access tokens and at least to > that of client credentials. Useful for, yes. Extensible, no. The only extensible part if the choice of algorithm. > skylar > > > On Jun 1, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: > > > They are coming in 2-3 directions, the use case isn't really clear (other > > than > claims of some flavors being harder than others), and overall this is more > about general HTTP authentication than OAuth use cases. Don't get me > wrong - if you want to put the effort in to capture these, go ahead. I just > think this isn't worth the effort in a formal document. > > > > EHL > > > >> -Original Message- > >> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] > >> Sent: Tuesday, May 31, 2011 6:15 PM > >> To: Eran Hammer-Lahav > >> Cc: Phil Hunt; OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >> token > >> > >> Maybe... But this information must be captured somewhere, right? > >> > >> At the moment, there seems to be no record of and consequently no > >> reference point to the use case in question. And this is what has > >> created all this discussion--with messages coming from all directions. > >> > >> Igor > >> > >> Eran Hammer-Lahav wrote: > >>> I think the use case document should focus on v2, not on MAC. At > >>> some > >> point, it becomes impractical to keep every use case discussed on > >> this list recorded. > >>> > >>> EHL > >>> > >>> > >>>> -Original Message- > >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>>> Behalf Of Igor Faynberg > >>>> Sent: Tuesday, May 31, 2011 3:50 PM > >>>> To: Phil Hunt > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >>>> token > >>>> > >>>> ...Sorry to turn the question around so as to underline my pet peeve: > >>>> Have we *documented* all cases? (This is what the Use Cases > >>>> document is supposed to be all about.) > >>>> > >>>> Just to clarify: I am not arguing with Phil's point now. I just > >>>> stress that as of this moment we don't have anything to check against. > >>>> > >>>> Igor > >>>> > >>>> Phil Hunt wrote: > >>>> > >>>>> There seems to be a demonstrated need for both age and timestamp > >>>>> > >>>> tokens. > >>>> > >>>>> The list has 2 separate cases with 2 separate proposals that do > >>>>> not solve all > >>>>> > >>>> cases. > >>>> > >>>>> Can we at least agree that neither proposal works in all cases? > >>>>> > >>>>> Phil > >>>>> > >>>>> @independentid > >>>>> www.independentid.com > >>>>> phil.h...@oracle.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote: > >>>>> > >>>>> > >>>>> > >>>>>> You haven't described a problem. > >>>>>> > >>>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward > >>>>>> > >>>>>> > >>>> wrote: > >>>> > >>>>>>> First we should agr
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
I think the use cases are pretty well understood (the issue here was not lack of use-case understanding). Basically, when it comes to client and server deployment, you can have one-to-one, one-to-many, many-to-one, and many-to-many. Each setup presents is own challenges on how to produce unique nonces on the client side (for all requests with the same MAC credentials / access token), and how to store and check on the server side. Once you go beyond one-to-one, it can be extremely hard (which is why most large providers don't check it). The discussion here was mostly about the "matter of logic"... which is never as easy as it should be. :-) EHL > -Original Message- > From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] > Sent: Tuesday, May 31, 2011 11:14 PM > To: Eran Hammer-Lahav > Cc: Phil Hunt; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > No, no, my little "I told you so" aside, I don't insist on putting this in the > document, especially that we have already agreed that the use case > document is a post-2.0 issue. > > I think that for the purposes of the discussion on this thread it would help > if > all the use cases in question were clearly described--if only in an e-mail for > now. Then it would be a matter of logic to see if there is a problem, and if > there is one, what the solutions to it might be. > > Igor > > Eran Hammer-Lahav wrote: > > They are coming in 2-3 directions, the use case isn't really clear (other > > than > claims of some flavors being harder than others), and overall this is more > about general HTTP authentication than OAuth use cases. Don't get me > wrong - if you want to put the effort in to capture these, go ahead. I just > think this isn't worth the effort in a formal document. > > > > EHL > > > > > >> -Original Message- > >> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] > >> Sent: Tuesday, May 31, 2011 6:15 PM > >> To: Eran Hammer-Lahav > >> Cc: Phil Hunt; OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >> token > >> > >> Maybe... But this information must be captured somewhere, right? > >> > >> At the moment, there seems to be no record of and consequently no > >> reference point to the use case in question. And this is what has > >> created all this discussion--with messages coming from all directions. > >> > >> Igor > >> > >> Eran Hammer-Lahav wrote: > >> > >>> I think the use case document should focus on v2, not on MAC. At > >>> some > >>> > >> point, it becomes impractical to keep every use case discussed on > >> this list recorded. > >> > >>> EHL > >>> > >>> > >>> > >>>> -Original Message- > >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>>> Behalf Of Igor Faynberg > >>>> Sent: Tuesday, May 31, 2011 3:50 PM > >>>> To: Phil Hunt > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >>>> token > >>>> > >>>> ...Sorry to turn the question around so as to underline my pet peeve: > >>>> Have we *documented* all cases? (This is what the Use Cases > >>>> document is supposed to be all about.) > >>>> > >>>> Just to clarify: I am not arguing with Phil's point now. I just > >>>> stress that as of this moment we don't have anything to check against. > >>>> > >>>> Igor > >>>> > >>>> Phil Hunt wrote: > >>>> > >>>> > >>>>> There seems to be a demonstrated need for both age and timestamp > >>>>> > >>>>> > >>>> tokens. > >>>> > >>>> > >>>>> The list has 2 separate cases with 2 separate proposals that do > >>>>> not solve all > >>>>> > >>>>> > >>>> cases. > >>>> > >>>> > >>>>> Can we at least agree that neither proposal works in all cases? > >>>>> > >>>>> Phil > >>>>> > >>>>> @independentid > >>>>> www.independentid.com > >>>>> phil.h...@oracle.com > >>>>> > >>>>>
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Provider: api.megaworld.com Software Program: A universal binary iOS app called MegaWorld for iOS Client ID: mega_app User: Frankie in London Username: frankie_uk Device A: Frankie's iPhone Device B: Frankie's iPad Now imagine MegaWorld for iOS installed on device A & B. Client ID is the same across the two devices. - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time on device A is 1306911444. - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time on device B is 1275375611. The provider, mega_app, does not issue multiple tokens for the same grant request (scope, client_id). This simplifies provider implementation but also helps enforce the correct user UI with respect to credential control at http://megaworld.com/my/apps - that is, the provider can't accurately know if frankie_uk has authorized one software instance twice on the same device, or multiple software instances once each (across multiple devices). Thus, the my/apps UI shows one authorization for "Megaworld for iOS" and thus one option to de-authorize this client_id (and thus all installed instances of the single software program with ID mega_app). Regardless if age or timestamp is used, if the implementation for validating the time value is sequential (perhaps with some window of error) then one device will have all its OAuth requests rejected as soon as the other presents a request. If timestamps are used the one with the older clock (device B) is rejected. If age is used, the one with the highest value of time (in this case, the more correct client) will be rejected as age will be calculated to be smaller than device B with an incorrect clock. If you also consider the case where device A and B have the same value for current time (UTC time, let's say) then age fails for device B after device A submits a request since device B thinks the credential is younger than device A. Timestamp does not fail in this case (because clocks are already sync'd). Only when the timestamp is a unified standard like UTC can both device A and B both use token 89ARC. If client B has it's request rejected it can quickly check UTC from any reasonable source (including api.megaworld.com) to correct its clock. Even better, it can politely check the correct system time on a regular basis and cache the offset between UTC and device time. Though experience may show that many software developers don't currently do this clock correction, it is trivial to adopt as a best practice. (Many software developer also don't routinely review their software for security or stability vulnerabilities of any sort.) Certainly is nothing for the small percentage of well-written high-value clients such as Firefox, TweetDeck or any serious effort with even moderate distribution or engineering resources. skylar On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > This is not true. > > The age value has to be monotonically increasing, but not necessarily unique. > Really, any counter will do. The reason why timestamp isn't any better than > age or sequence is because ultimately, it is the server's memory restriction > which determines the nonces storage size, not anything else (like a time > limit). ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Sounds like Eran's proposal will work fine for this scenario. MegaWorld for iOS can just do what you suggest in the final paragraph, which meets the new requirements for age. I'm glad we're able to address you use case. Thanks, Adam On Wed, Jun 1, 2011 at 12:15 AM, Skylar Woodward wrote: > Provider: api.megaworld.com > > Software Program: A universal binary iOS app called MegaWorld for iOS > Client ID: mega_app > > User: Frankie in London > Username: frankie_uk > > Device A: Frankie's iPhone > Device B: Frankie's iPad > > Now imagine MegaWorld for iOS installed on device A & B. Client ID is the > same across the two devices. > > - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to > access his account (frankie_uk) > - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time on > device A is 1306911444. > - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to > access his account (frankie_uk) > - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time on > device B is 1275375611. > > The provider, mega_app, does not issue multiple tokens for the same grant > request (scope, client_id). This simplifies provider implementation but also > helps enforce the correct user UI with respect to credential control at > http://megaworld.com/my/apps - that is, the provider can't accurately know if > frankie_uk has authorized one software instance twice on the same device, or > multiple software instances once each (across multiple devices). Thus, the > my/apps UI shows one authorization for "Megaworld for iOS" and thus one > option to de-authorize this client_id (and thus all installed instances of > the single software program with ID mega_app). > > Regardless if age or timestamp is used, if the implementation for validating > the time value is sequential (perhaps with some window of error) then one > device will have all its OAuth requests rejected as soon as the other > presents a request. If timestamps are used the one with the older clock > (device B) is rejected. If age is used, the one with the highest value of > time (in this case, the more correct client) will be rejected as age will be > calculated to be smaller than device B with an incorrect clock. > > If you also consider the case where device A and B have the same value for > current time (UTC time, let's say) then age fails for device B after device A > submits a request since device B thinks the credential is younger than device > A. Timestamp does not fail in this case (because clocks are already sync'd). > > Only when the timestamp is a unified standard like UTC can both device A and > B both use token 89ARC. If client B has it's request rejected it can quickly > check UTC from any reasonable source (including api.megaworld.com) to correct > its clock. Even better, it can politely check the correct system time on a > regular basis and cache the offset between UTC and device time. Though > experience may show that many software developers don't currently do this > clock correction, it is trivial to adopt as a best practice. (Many software > developer also don't routinely review their software for security or > stability vulnerabilities of any sort.) Certainly is nothing for the small > percentage of well-written high-value clients such as Firefox, TweetDeck or > any serious effort with even moderate distribution or engineering resources. > > skylar > > > On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > >> This is not true. >> >> The age value has to be monotonically increasing, but not necessarily >> unique. Really, any counter will do. The reason why timestamp isn't any >> better than age or sequence is because ultimately, it is the server's memory >> restriction which determines the nonces storage size, not anything else >> (like a time limit). > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
> -Original Message- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Wednesday, June 01, 2011 12:16 AM > To: Eran Hammer-Lahav > Cc: Adam Barth; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > Provider: api.megaworld.com > > Software Program: A universal binary iOS app called MegaWorld for iOS Client > ID: mega_app > > User: Frankie in London > Username: frankie_uk > > Device A: Frankie's iPhone > Device B: Frankie's iPad > > Now imagine MegaWorld for iOS installed on device A & B. Client ID is the > same across the two devices. This is broken. You are using MAC for client authentication, but your client is a native application which should not have a secret... > - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to > access his account (frankie_uk) > - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time > on device A is 1306911444. > - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to > access his account (frankie_uk) > - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time > on device B is 1275375611. When you say issued, you mean MAC credentials (access token) or client credentials? EHL > The provider, mega_app, does not issue multiple tokens for the same grant > request (scope, client_id). This simplifies provider implementation but also > helps enforce the correct user UI with respect to credential control at > http://megaworld.com/my/apps - that is, the provider can't accurately know > if frankie_uk has authorized one software instance twice on the same > device, or multiple software instances once each (across multiple devices). > Thus, the my/apps UI shows one authorization for "Megaworld for iOS" and > thus one option to de-authorize this client_id (and thus all installed > instances > of the single software program with ID mega_app). > > Regardless if age or timestamp is used, if the implementation for validating > the time value is sequential (perhaps with some window of error) then one > device will have all its OAuth requests rejected as soon as the other presents > a request. If timestamps are used the one with the older clock (device B) is > rejected. If age is used, the one with the highest value of time (in this > case, > the more correct client) will be rejected as age will be calculated to be > smaller > than device B with an incorrect clock. > > If you also consider the case where device A and B have the same value for > current time (UTC time, let's say) then age fails for device B after device A > submits a request since device B thinks the credential is younger than device > A. Timestamp does not fail in this case (because clocks are already sync'd). > > Only when the timestamp is a unified standard like UTC can both device A > and B both use token 89ARC. If client B has it's request rejected it can > quickly > check UTC from any reasonable source (including api.megaworld.com) to > correct its clock. Even better, it can politely check the correct system time > on > a regular basis and cache the offset between UTC and device time. Though > experience may show that many software developers don't currently do this > clock correction, it is trivial to adopt as a best practice. (Many software > developer also don't routinely review their software for security or stability > vulnerabilities of any sort.) Certainly is nothing for the small percentage of > well-written high-value clients such as Firefox, TweetDeck or any serious > effort with even moderate distribution or engineering resources. > > skylar > > > On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > > > This is not true. > > > > The age value has to be monotonically increasing, but not necessarily > unique. Really, any counter will do. The reason why timestamp isn't any > better than age or sequence is because ultimately, it is the server's memory > restriction which determines the nonces storage size, not anything else (like > a time limit). ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Actually, monotonically increasing fails for this use case because even if clocks are sync'd, device A and B can submit requests sequentially in UTC time but could arrive in reverse order. So monotonically increasing, with some tolerance or window of error would seem to be sufficient for allowing the server to expire nonces yet accounting for the complications of multiple devices presenting the same token. If providers were left to determine the window of error (which is really just a way of the provider controlling allocations for nonce storage) then it could accommodate for minor variances in device system time as before as well. skylar On Jun 1, 2011, at 9:24 AM, Adam Barth wrote: > Sounds like Eran's proposal will work fine for this scenario. > MegaWorld for iOS can just do what you suggest in the final paragraph, > which meets the new requirements for age. I'm glad we're able to > address you use case. > > Thanks, > Adam > > > On Wed, Jun 1, 2011 at 12:15 AM, Skylar Woodward wrote: >> Provider: api.megaworld.com >> >> Software Program: A universal binary iOS app called MegaWorld for iOS >> Client ID: mega_app >> >> User: Frankie in London >> Username: frankie_uk >> >> Device A: Frankie's iPhone >> Device B: Frankie's iPad >> >> Now imagine MegaWorld for iOS installed on device A & B. Client ID is the >> same across the two devices. >> >> - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS >> to access his account (frankie_uk) >> - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time >> on device A is 1306911444. >> - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS >> to access his account (frankie_uk) >> - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time >> on device B is 1275375611. >> >> The provider, mega_app, does not issue multiple tokens for the same grant >> request (scope, client_id). This simplifies provider implementation but also >> helps enforce the correct user UI with respect to credential control at >> http://megaworld.com/my/apps - that is, the provider can't accurately know >> if frankie_uk has authorized one software instance twice on the same device, >> or multiple software instances once each (across multiple devices). Thus, >> the my/apps UI shows one authorization for "Megaworld for iOS" and thus one >> option to de-authorize this client_id (and thus all installed instances of >> the single software program with ID mega_app). >> >> Regardless if age or timestamp is used, if the implementation for validating >> the time value is sequential (perhaps with some window of error) then one >> device will have all its OAuth requests rejected as soon as the other >> presents a request. If timestamps are used the one with the older clock >> (device B) is rejected. If age is used, the one with the highest value of >> time (in this case, the more correct client) will be rejected as age will be >> calculated to be smaller than device B with an incorrect clock. >> >> If you also consider the case where device A and B have the same value for >> current time (UTC time, let's say) then age fails for device B after device >> A submits a request since device B thinks the credential is younger than >> device A. Timestamp does not fail in this case (because clocks are already >> sync'd). >> >> Only when the timestamp is a unified standard like UTC can both device A and >> B both use token 89ARC. If client B has it's request rejected it can quickly >> check UTC from any reasonable source (including api.megaworld.com) to >> correct its clock. Even better, it can politely check the correct system >> time on a regular basis and cache the offset between UTC and device time. >> Though experience may show that many software developers don't currently do >> this clock correction, it is trivial to adopt as a best practice. (Many >> software developer also don't routinely review their software for security >> or stability vulnerabilities of any sort.) Certainly is nothing for the >> small percentage of well-written high-value clients such as Firefox, >> TweetDeck or any serious effort with even moderate distribution or >> engineering resources. >> >> skylar >> >> >> On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: >> >>> This is not true. >>> >>> The age value has to be monotonically increasing, but not necessarily >>> unique. Really, any counter will do. The reason why timestamp isn't any >>> better than age or sequence is because ultimately, it is the server's >>> memory restriction which determines the nonces storage size, not anything >>> else (like a time limit). >> >> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
> -Original Message- >> From: Skylar Woodward [mailto:sky...@kiva.org] >> Sent: Wednesday, June 01, 2011 12:16 AM >> To: Eran Hammer-Lahav >> Cc: Adam Barth; OAuth WG >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token >> >> Provider: api.megaworld.com >> >> Software Program: A universal binary iOS app called MegaWorld for iOS Client >> ID: mega_app >> >> User: Frankie in London >> Username: frankie_uk >> >> Device A: Frankie's iPhone >> Device B: Frankie's iPad >> >> Now imagine MegaWorld for iOS installed on device A & B. Client ID is the >> same across the two devices. > > This is broken. You are using MAC for client authentication, but your client > is a native application which should not have a secret... No, I had two use cases to discuss. One of access tokens being re-issued and the other of client credentials. Token re-issue seemed easier to explain because it is the more common case of device conflict. The issues with client credentials are minimized with the algorithm for nonce expiration that Adam suggested (sequential) which was not clear as a suggestion by the spec. I could outline a problem with age for client credentials which use the "flagged as old" algorithm, but this seems less important now if we assume "sequential with a window of tolerance" as the algorithm for invalidation. However, there are possible cases where two software instances use the same client credential (and where it's still possible to secure the secret). Most of those cases are ones where the software distribution is protected inside a controlled network. A few examples (not common across OAuth, though some of these will be popular for providers like Kiva where its customers deploy proprietary software inside controlled intranets where secrets can be protected from the public even in "native" apps): - Great State University makes an app for managing student grading. This app is distributed to all faculty iPhones using the Apple Enterprise Deployment system. GSU expects faculty not to share the installed software with non-faculty or to use jail-broken phones -- doing so is a violation of school code of ethics. GSU makes the case that the client credentials in the grading app are securable with reasonable deployment and legal protections in place. All installs of the app onto faculty iPhones use the same client credential. They use the client credential as an additional hurdle to protect against forged clients trying to authorize. - Green Microlender makes an app for submitting loan data to Kiva that also interfaces with their local MIS system. This is a Visual Basic program installed on Windows PCs throughout field offices in southern Uganda which each on the organization's protected VLAN (or multiple protected LANs). This program is deployed by IT staff only onto these devices. They choose to use client credentials in this program as they feel comfortable in asserting that the client secrets are protected adequately by Green Microlender. - MegaWorld Tracker deploys websites in France and the US. They set up different instances of their website program in servers in France and the US. Each deployment is configured with the same MegaWorld OAuth client ID since it is the same program, but different locale settings to make the software render text in French or English, respectively. Since MegaWorld Tracker isn't a huge corp, they've haven't put in place measures to sync user's access tokens between the French servers and the US servers. This means a user that hits both the FR server and the US server will have to authenticate twice to megaworld.com (and thus access tokens issued to each server install). Since they also didn't bother to register two client IDs (mw_tracker instead of mw_tracker_us and mw_tracker_fr) they essentially have two installs using the same client credentials. It's a reasonable gray area. I do admit these won't be en masse in the grand collective of all deployed OAuth v2 apps, but they are reasonable use cases, and for some organizations, very important use cases. >> - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to >> access his account (frankie_uk) >> - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time >> on device A is 1306911444. >> - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to >> access his account (frankie_uk) >> - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time >> on device B is 1275375611. > > When you say issued, you mean MAC credentials (access token) or client > credentials? these are access tokens > > EHL >
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Then all these clients sharing the same credentials will require clock sync (not a problem for cell phones usually, but can be for other devices). But if you are implementing OAuth 2.0, the request including client authentication is made over TLS (as required) and so replay isn't much of a concern. If for some reason you are not using TLS alongside client authentication for obtaining an access token, this particular use case becomes out of scope. EHL > -Original Message- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Wednesday, June 01, 2011 1:06 AM > To: Eran Hammer-Lahav > Cc: Adam Barth; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > > -Original Message- > >> From: Skylar Woodward [mailto:sky...@kiva.org] > >> Sent: Wednesday, June 01, 2011 12:16 AM > >> To: Eran Hammer-Lahav > >> Cc: Adam Barth; OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >> token > >> > >> Provider: api.megaworld.com > >> > >> Software Program: A universal binary iOS app called MegaWorld for iOS > >> Client > >> ID: mega_app > >> > >> User: Frankie in London > >> Username: frankie_uk > >> > >> Device A: Frankie's iPhone > >> Device B: Frankie's iPad > >> > >> Now imagine MegaWorld for iOS installed on device A & B. Client ID > >> is the same across the two devices. > > > > This is broken. You are using MAC for client authentication, but your client > is a native application which should not have a secret... > > No, I had two use cases to discuss. One of access tokens being re-issued and > the other of client credentials. Token re-issue seemed easier to explain > because it is the more common case of device conflict. > > The issues with client credentials are minimized with the algorithm for nonce > expiration that Adam suggested (sequential) which was not clear as a > suggestion by the spec. I could outline a problem with age for client > credentials which use the "flagged as old" algorithm, but this seems less > important now if we assume "sequential with a window of tolerance" as the > algorithm for invalidation. > > However, there are possible cases where two software instances use the > same client credential (and where it's still possible to secure the secret). > Most of those cases are ones where the software distribution is protected > inside a controlled network. A few examples (not common across OAuth, > though some of these will be popular for providers like Kiva where its > customers deploy proprietary software inside controlled intranets where > secrets can be protected from the public even in "native" apps): > > - Great State University makes an app for managing student grading. This app > is distributed to all faculty iPhones using the Apple Enterprise Deployment > system. GSU expects faculty not to share the installed software with non- > faculty or to use jail-broken phones -- doing so is a violation of school > code of > ethics. GSU makes the case that the client credentials in the grading app are > securable with reasonable deployment and legal protections in place. All > installs of the app onto faculty iPhones use the same client credential. They > use the client credential as an additional hurdle to protect against forged > clients trying to authorize. > > - Green Microlender makes an app for submitting loan data to Kiva that also > interfaces with their local MIS system. This is a Visual Basic program > installed > on Windows PCs throughout field offices in southern Uganda which each on > the organization's protected VLAN (or multiple protected LANs). This > program is deployed by IT staff only onto these devices. They choose to use > client credentials in this program as they feel comfortable in asserting that > the client secrets are protected adequately by Green Microlender. > > - MegaWorld Tracker deploys websites in France and the US. They set up > different instances of their website program in servers in France and the US. > Each deployment is configured with the same MegaWorld OAuth client ID > since it is the same program, but different locale settings to make the > software render text in French or English, respectively. Since MegaWorld > Tracker isn't a huge corp, they've haven't put in place measures to sync > user's > access tokens between the French servers and the US servers. This means a > user that hits both the FR server and the US server will have to authenticate > twice to megaworld.com (and thus access tokens iss
