On Tue, Mar 20, 2007 at 01:48:12PM +0000, Paulo Andre wrote:
> On Mar 20, 2007, at 12:53 PM, u+codalist-p4pg_at_chalmers.se wrote:
> >1: Yes, it is reasonably strong (about as strong as you can do with  
> >64 bits keys)
> >
> >2: Kerberos may still be preferable for other reasons, e.g.
> >
> > sharing passwords with other systems like host login or something  
> >else
> >
> > using third-party tools for authentication record management  
> >(password
> > changes, adding/deleting accounts)
> >
> > reusing existing user authentication databases (doesn't seem to apply
> > in your case?)
> 
> I'm interested in users - which authenticate via an external LDAP  
> server on their workstations - having their homes mounted upon login  
> on the /coda filesystem. Does this mean this will only work with a  

Home directories don't have to be mounted explicitly.

> Kerberos-based authentication in Coda? From what you see, it appears  
> to be the case, though taking into account clog uses 64-bit  
> encryption, that'd be enough for me and I rather avoid setting up  

During the initial handshake we establish several session keys. Each
RPC2 connection is using independent keys to encrypt and authenticate
for incoming and outgoing packets. These session keys are normally
128-bits each, i.e. one 128-bit key to encrypt outgoing packets, a
second 128-bit key to decrypt incoming packets. It is possible to
request a larger keysize (192 or 256-bits) with the RPC2SEC_KEYSIZE
environment variable. Also every RPC2 connection will negotiate a new
unique set of session keys during the initial handshake.

So at the lowest level we should be using the best possible keys. The
64-bit key that Rune mentioned are the ones that are passed in Coda
tokens. The RPC2-API defined an encryption key as a fixed 8-byte
character array (RPC2_EncryptionKey), and when strong encryption was
added we kept this around to avoid breaking the API.

So to derive a usable key from the secret information we get from both
Coda tokens and user passwords we passed this through a 'PBKDF'
(Password based key derivation function). Effectively we hash this less
trusted data 10000 times and use the result as the real key. The
reasoning is that if there are no shortcuts in the hashing algorithm
that it would be too expensive for anyone to try to brute force all
possible 64-bit input values.

Whenever RPC2 is initialized we actually check how long it takes to
perform the PBKDF and if it is less than 1ms (1000 ops/s) we print a
warning. This way if CPU are getting fast enough to brute force the
keyspace we bump the iterator by an extra factor of 10.

This is based on the assumption that it may be likely that someone has a
10x faster AES implementation and has roughly ~1000 machines available.
Also, it takes no time to check if the resulting key is the one he is
looking for. As my 3.2GHz P4 can perform about 133 key derivations per
second the attacker is expected to generate/check at least 1,330,000
keys per second.

In that case if the password only consists of lowercase alpha
characters, we have 40-bits of information in an 8 character secret. A
full search can be done in less than 10 days. But then again, lowercase
only passwords have been considered weak for several years now.

With a random alpha-numeric (mixed case) 8 character password, we have
almost 48 bits and under the same assumptions it would take the attacker
close to 2500 days (a little more than 6 years). A truly random 8 byte
secret (i.e. Coda tokens) increases the time it takes to brute force the
key significantly (435,000 years).

The other approach would be to pre-compute all possible key values. It
is probably feasible to store the generated 128-bit keys for all
possible sequences of 8 lowercase alpha characters (I think that would
only require about 16TB) but beyond that even storing all 2^64 possible
128-bit keys becomes a bit expensive.

So yes, we do use weaker 64-bit keys in the RPC2-API, but realize their
weakness and account for that by increasing the cost of deriving the key
we use during the initial handshake. And during that handshake we
negotiate a pair of unique 128-bit session keys which are used only for
the duration of that RPC2 connection.

> On a side note, I found a pam_coda module somewhere on the web,  
> written by Robin Gareus back in early 2000. What is the preferred way  
> nowadays to have such a setup going?

Not sure, I think there are/were 3 different pam_coda implementations
that all did things slightly differently. One linked/copied the clog
code which may cause a threading conflict between LWP and whatever the
pam-using application is using. Another simply forked clog and used it's
exit code to check for authentication success or failure.

I think that once the user has been authenticated with kerberos, it is
possible to run a kerberized version of clog without any arguments
(maybe just specifying the Coda realm) and it should simply pick up the
kerberos ticket and use that to authenticate with the auth2 daemon
without any further interaction.

The only step that kerberos avoids in the security picture is the
initial authentication step between clog and auth2, a user doesn't have
to type his password to prove his identity, but clog obtains some
authenticator from the kerberos ticket.

Once the initial handshake between clog and auth2 has completed, auth2
returns a Coda token, which is then passed along to venus and the
information from this Coda token is used to for any connections between
the client and the server.

I don't use kerberos myself, and the pre-built debian packages don't
have it enabled.

Jan