-----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 <sky...@kiva.org>
wrote:
Resending to the list from my subscribed account...
Begin forwarded message:
From: Skylar Woodward <sky...@larw.com>
Date: May 23, 2011 6:14:00 PM PDT
To: Skylar Woodward <sky...@kiva.org>
Cc: Eran Hammer-Lahav <e...@hueniverse.com>, OAuth WG
<oauth@ietf.org>
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
<apps-disc...@ietf.org> 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 major changes since -02 are:
* Removed OAuth terminology and association. The draft is now a
general purpose HTTP authentication scheme. It does include an OAuth 2.0
binding which is described in less than a page. One suggestion would be to
move section 5.1 into the OAuth specification and drop all the OAuth 2.0 text
from the MAC draft.
* Added 'Set-Cookie' extension for using MAC with session cookies.
* Removed request URI query normalization. The new draft uses the
raw request URI unchanged.
* Replaced timestamps with credentials age to remove the need for
clock sync.
* Added a placeholder for extension, allowing random text to be
included in the request and MAC.
* Added issuer attribute for identifying the source of the credentials as
an additional protection.
Draft -04 is not compatible with previous drafts.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc.
peter.wola...@acquia.com : 978-296-5247
"Get a free, hosted Drupal 7 site: http://www.drupalgardens.com";
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
