Re: [OT] Re: random, digest, uuid, cipher & Co

[David Haley <dchaley@...>]

PA wrote:

> 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 
> the server
> (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 
compromise. :-)

--
~David-Haley
http://david.the-haleys.org