Brian,
You are asking many interesting questions--maybe we should continue this
when we meet in Anaheim. (The nights are getting shorter...)
In short, yes, non-repudiation, in general, is a very tough thing. We
had been having long discussions with Steve Bellovin about that in
PINT/SPIRITS times, and really, in the absence of private key signatures
there, the only solution is some kind of a third-party interference.
You are right, non-repudiation was not an objective of OAuth 1.0, and I
do not insist that non-repudiation be a requirement in OAuth, period. I
merely pointed out that a private-key signature solves this problem too,
while answering a question on why signatures are needed.
But your questions naturally make me think about the non-repudiation use
case. I suspect that both the end-user and the Client would be involved
because this is a three-way transaction. Of course, the case I alluded
to dealt ONLY with the non-repudiation of the Client's request...
Anyway, this is a very interesting and, I suspect, complex problem.
Let us talk with a piece of paper when we meet?
Igor
Brian Eaton wrote:
On Thu, Mar 4, 2010 at 10:18 PM, Igor Faynberg
<[email protected]> wrote:
The secure channel only delivers a request (or a token). But there is no
proof of authentication (or the means for non-repudiation) in the token
itself, unless the whole session has been recorded (and the key for it has
been stored).
The non-repudiation goal is the most interesting, because it is the
only one in your list that is not met by WRAP over https.
Non-repudiation can, sort of, be achieved by some OAuth 1.0a
deployments. But not most of them.
The "token auth" drafts that Eran sent out earlier explicitly remove
the client secret from being used to sign resource requests, which
would even further restrict the number of OAuth deployments that could
claim something resembling non-repudiation.
I'd also note that non-repudiation was not a security goal of OAuth
1.0a, and as a consequence probably shouldn't be relied on for
non-repudiation. For example, OAuth 1.0a doesn't use a trusted
timestamping service; if a key leaks, all documents signed with that
key are suspect.
There are existing schemes for non-repudiation that may be better
suited for your use cases. Have you looked at alternatives to OAuth
signing?
But I have to admit I'm still unsure of your use cases. For example,
do you have three players (client, server, user), or just two (client,
server)? Which players are making statements that need the
non-repudiation property?
Cheers,
Brian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
