On Tue, Feb 17, 2004 at 10:56:09AM -0500, Greg Troxel wrote:
> authentication and confidentiality of data traffic: Coda uses a scheme
> that is much like Kerberos (a variant of Needham-Schroder, I believe)
> to obtain tokens and use them to authenticate/encrypt messages.
> This is tricky business, and I don't know if the coda scheme is sound;
> perhaps Satya can comment, especially in light of:
> http://citeseer.nj.nec.com/context/348225/0
> which I think postdates the auth2 code.

Coda uses a 'modified Needham-Schroeder', based on the corrections
suggested by the following vulnerability analysis of the Andrew Secure
RPC Handshake,

http://ftp.digital.com/pub/DEC/SRC/research-reports/abstracts/src-rr-039.html

> However, the coda implementation uses XOR instead of a cipher because
> of past export control rules.  Thus, no authentication and
> confidentiality is actually provided.  An eavesdropper can easily
> recover token keys from listening and then masquerade as the user.

Correct, the challenge is E(X) (encrypted random number X), and the
expected response is E(X+1). But xor encoding doesn't mangle the whole
block, but each bit individually. And adding 1 to any random value means
that we have a 50% chance that we need to flip the lowest bit only. If
the server accepts the bit-flip, we have 50% probability that the
original value matches the lowest bit in the shared secret (i.e. random
number had a 0 xor shared secret bit = shared secret bit). This can be
done iteratively for all remaining bits.

I'm know that something similar can be used against the Coda tokens, as
all tokens are encoded by the same 'auth2.tk' secret which is shared
between the auth2 daemon and the Coda servers. As there are known bits
in the secret part of the token I'm actually more afraid that it would
be fairly trivial for the user to decode the auth2.tk secret out of the
token than a third party eavesdropper who only sees the secret part.
The user has a lot more information like the shared secret session key,
Coda userid, begin and end timestamps, etc.

> well-reviewed security protocols that are believed to be sound.  While
> Kerberos is non-trivial to set up, it isn't that much harder than
> auth2.  One would replace getting tokens with establishing a binding

The problem is that kerberos might go off and do something like a
blocking DNS lookup, or long computation without yielding control to
other LWP threads. This isn't much of a problem in clog and auth2, but
for Coda clients and server such a thing would be deadly as it leads to
disconnections. And then we have to reestablish the RPC2 connections
which requires authentication which might block in kerberos, which leads
to disconnections...

Jan