[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [OT] Re: random, digest, uuid, cipher & Co
- From: David Haley <dchaley@...>
- Date: Thu, 14 Apr 2005 08:21:12 -0700
The current concoction involve 3 steps:
(1) Upon connection, the server provide a random token to the client
(2) The client sign the token with its private key and pass it back to
(3) The server ask a directory service for the location of the client
and ask that node to validate the token signature.
And yes, each step can be compromised one way or another: the random
token could not be that random. The signature could turn out to be
quite predictable. The directory service could be compromised. The
callback could be highjacked. Etc...
I'm open to concrete and practical suggestions beside pointers to Mr
Schneier's blog :)
Well, I don't want to stretch on the off-topic too long, but it seems to
me that you need to have a think about just what it is you're trying to
be secure against. Are you trying to identify or _authenticate_ client
to server? If identify then just use UUIDs and be done with it. If
authenticate then you'll need a lot more work. And as I said earlier,
the problem with your solution is not necessarily in the cryptography;
the protocol might have fundamental flaws in it. For instance, asking
the client to validate its own signature.
Since you cited the WYTM post, you should answer it: what _is_ your
threat model? You've given a solution but you've not specified what kind
of attacks you're worried about. Your protocol as it stands might as
well be clear-text identification, given how easily it could be hijacked
at so many levels. The most salient flaw I see is signature checking.
The client validates the signature, so it could sign the received token
with gobbledegook and then, when challenged, simply say "yup, that's
mine". What is the point of your validation step? I feel that you might
be leaving out a lot; you say for instance that the server contacts a
directory for the location of the client - which client? Where has the
client given an identifier for itself?
Anyhow in order to judge your protocol, you need to specify what kind of
attacks you're trying to protect against, if any, and what level of
security failure is tolerable. You pointed out that security is always a
compromise, but there's SSL's compromise and then there's this
- random, digest, uuid, cipher & Co, PA
- Re: random, digest, uuid, cipher & Co, David Haley
- [OT] Re: random, digest, uuid, cipher & Co, PA