Yes, the third-party-based non-repudiation with symmetric cryptography
is a complex thing. The way I would apply it to the Client request is
as follows:
1) The Client sends the token request, R, to the Third Party (and, you
are right, the Third Party must know who the client is, and so one
shared secret is needed right there, given that there is no public key
cryptography; so this secret is used to sign R);
2) The Third Party hashes the request using a secret that *only the
Third Party knows* and sends this quantity, Q, back to the Client;
3) Now the Client sends to the server (R, Q).
The server could now go back to the Third Party and ask if Q is indeed
what it had given. To eliminate this step, the Third Party can either
encrypt (R, Q) with the secret shared with the server, or sign it with
its secret, and return the resulting quantity, Q', to the Client.
The requirement her is that the Third Party must be trusted by both the
Client and the Server and--in addition--it must be trusted by the court,
which could verify with the Third Party that it indeed has computed Q.
(Verification, I understand, should be done involving a real person
because, in general, escrowing signature keys makes signatures invalid.)
Igor
Dick Hardt wrote:
Hi Igor
Thanks for explanation. Unfortunately I am more confused. How does the third
party know who the Client is?
I don't understand how an Access Token plus a signing secret gives any more
assurance than an Access Token unless I get the Access Token from a different
place than the signing secret. Is that what I am missing?
-- Dick
On 2010-03-12, at 11:38 AM, Igor Faynberg wrote:
Dick,
The trick here is THE THIRD PARTY (referred to in the last words of Eve's
message), who is effectively a witness to the transaction. (This works pretty
much like when you want to switch your telephone provider. You would be
transferred to the third party to confirm your request.) Absent of the
private-key signature, this is the only known way to ensure non-repudiation.
Igor
Dick Hardt wrote:
On 2010-03-12, at 10:22 AM, Eve Maler wrote:
This nets out to the requesting party (person or company seeking access) having an
incentive to say "It's really me accessing this", such that it mitigates the
risk that the requester (client) will hand off both the access token and the signing
secret to a third party.
Note I am NOT a security expert, and would appreciate an education on where I
am wrong.
When I look at this, I question if there really is that much more value in the Client having two secret items over one secret item.
I can see an advantage with something like using RAS, in that only the Client should have the private key, and if the private key can be used for lots of things, then there is some difference between a token and the private key. With symmetric keys, multiple parties have the keys, so non-repudiation is not possible.
-- Dick
------------------------------------------------------------------------
_______________________________________________
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
