(Illustration by Gaich Muramatsu)
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. JanReceived on 2007-03-20 15:05:39