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
Rune