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 <sky...@kiva.org>
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 previous
explanation. The more concrete you can be, the better.
Thanks,
Adam
On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
<sky...@kiva.org>
wrote:
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
<sky...@kiva.org> 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.
Adam
On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
<sky...@kiva.org> 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_FI
REFOX - 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
<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
random+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-
tok
en
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
