(Illustration by Gaich Muramatsu)
I must warn that I'm not speaking from direct experience. OK - here's my take on the situation from fairly long (1997 or so, I think) experience with coda. Coda security can be divided into three areas: authorization model: Here coda has a well-thought-out scheme and a reasonable implementation, with user and group permissions implemented by acls on directories. This model is based on authentication of requests. 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. 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. Until this problem is fixed it is simply incorrect to call coda - the implementation - secure. code quality: To be secure, the clients and servers must be free of exploitable defects. I think the code is getting better over time, but I don't have a warm fuzzy that it is all ok. As a result, my practice is to require IPsec ESP for all coda traffic, and to limit the set of hosts to which my server is willing to set up IPsec SAs to ones that are more or less under my control. There are at least two paths forward to solve the "XOR problem". One is to use AES instead. This leaves us with a N-S protocol variant (and, I think homegrown by people who are not cryptographers). Another alternative is to replace the RPC2 N-S scheme with the use of GSS-API wrapping, and then to use Kerberos. This would rely on 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 at the server from a kerberos principal to a coda uid (by consulting the equivalent of .klogin, probably in some authentication database, or by the obvious 'gdt._at_IR.BBN.COM can be coda user gdt in the ir.bbn.com coda realm' mapping. This binding setup would also exchange the intiial GSS-API state, so that datagram wrapping could be done on the rpc2 data. Unfortunately, the code has not been written yet.Received on 2004-02-17 10:59:53