(Illustration by Gaich Muramatsu)
Hi Greg, I can not help commenting on the virtues of Kerberos. On Thu, Jul 10, 2014 at 04:38:54PM -0400, Greg Troxel wrote: > it should go in the repo, to be usable in the interim until the glorious > future arrives. (IMHO, setting up a separate ad-hoc Needham-Schroeder > system with custom code that hasn't had the wide review and fixes that > Kerberos has instead of just relying on Kerberos seems totally > unreasonable in 2014; I get it that afs/coda coevolved with krb from > long long ago and there are historical reasons.) TL;DR : As for my experience, it is a _major_ practical advantage to have a non-Kerberos authentications architecture and subsystem. Coda authentication implementation is really ancient and I do not advocate keeping it as-is - but Kerberos is not a desirable replacement (even though interoperability with Kerberos is precious). The longer version: 1. Entrance threshold. Coda authentication is conceptually and practically much simpler to set up correctly than a Kerberos realm or otherwise than to properly use a Kerberos realm. (by much simpler I do not mean the traditional Coda setup scripts, try the Aetey's installer to see the difference) 2. File-realm-centric representation of credentials. Coda tokens are a convenient common ground for technical representation of credentials. Other types of credentials are quite easily translatable to tokens. 3. Multiple authorities / protocols. The main (and heavily used here) point of the modular clog is bridging to any "reasonable" authentication protocol and authority, allowing independently managed authorities and the corresponding identity names (sub)spaces. This does not look easy or even possible with Kerberos. 4. Ease/freedom of management Choosing Kerberos as "the" authentications means buys you a lot of "reviewed" cryptography but also restrains you inside the infrastructure and imposes on you its shortcomings, without an escape. 5. Human perception Even concerning system administrators, Kerberos is very badly understood (and misleadingly documented). Even worse is this among the users. An abstraction of a Coda token is in fact easier to explain than the one of a Kerberos tickets (no "trusted third party", time-dependency or special-kind-of-a-ticket aka tgt involved). 6. Practices Kerberos traditional practices are often detrimental for both security and sane thinking, like putting different credentials in the same keytab or inability to handle multiple realms' credentials in a single credentials cache. NFSv4 use of Kerberos credentials is a bad heuristic-based hack, do we want something similar for Coda? Why didn't they do anything better? Probably because it is hard. 7. Question and answers :) Q. Is there any AFS cell issuing secure anonymous tokens like Coda easily can? Anything like this for NFSv4? A. 8-o Q. Is there any formal specification of the format of the Kerberos file credentials cache (which different implementations are _supposed_ to be able to share) ? A. When I asked a couple of years ago at the Kerberos & AFS conference the answer was negative. Kerberos is very useful but it is very far from being an answer to all needs, particularly to the needs of a file system. My 2c RuneReceived on 2014-07-10 20:59:55