My $0.02 on this subject: While zeroconf is an admirable goal (one I've pushed for a long time), zeroauth (for lack of a better term) is a completely different matter.
Authentication is tied up a whole bunch of site-specific policies, and every site I've ever encountered has a vastly different mindset on how they deal with authentication. For example, I consider regular password changes a vitally important part of our security posture, yet many sites don't do this at all. >> You just accept any username, create a KDC entry for them, and give >> them an empty password. Tada, authenticated. > >Only the KDC admin can do this. Furthermore, users would need to >remember a different username (and password, if they have any sense) >for every cell. Well, there _is_ cross-realm authentication, of course. But that has it's own interesting challenges (speaking as someone who helped set up a 7-8 cross-realm mesh). Users in that mesh can use one principal to autheticate to any resource at approximately 20 different sites. But you have different goals than I do; you want to accept basically any kind of existing authentication that a user has already, with zero effort. While I am pretty liberal with who we cross-realm with, that does not extend to users using those realms. We control the principal to userid mapping, and do not let users get interactive access to our systems from arbitrary principals. I suspect most people want something in the middle of this. >> the user now has this piece of magic data that they have to keep track of > >SSH users seem to be able to manage this quite easily. PGP as well. Does it? I see SSH mostly being used as a secure tunnel; not that there's anything wrong with that, it's certainly better than plaintext telnet, but it mostly deals with the "magic data" problem by cheating, and only power users seem to know about RSA authentication. I have even started to see sites turning off RSA authentication because user's workstations are too easily 0wned. >I also mentioned kx509 as an example of a partial solution: perhaps >authentication is moving from kdc-as-trusted-omnipotent-diety to >kdc-as-key-storage-facility. Specifically, kx509 changes the role of >the KDC from issuing tickets to issuing "junk certificates". Maybe it's me, but I've never really seen the difference between a junk certificate and a Kerberos ticket; crypto-wise they're handled differently, but from a key management perspective they're almost zero-sum. >It's a >way for organizations that have made major investments in Kerberos to >escape the fundamental limitations of symmetric-only cryptosystems. >This way users don't have to carry around their keys. I'm confused; do you know about some cryptosystem that I don't that doesn't require users to know some sort of key? Certainly kx509 doesn't eliminate a user knowing a key; I view it a way to solve the "web browsers don't do Kerberos" problem, or even the, "We designed a distributed computing environment that really should have used Kerberos from the start, but for some political reason we choose PKI and decided to add all the features to our PKI that Kerberos has" problem. >Perhaps identity management can't be done perfectly, but it is already >being done well enough to make the rest of this possible. The trick >to avoid committing to a single approach (as with afs+krb4), but >instead to provide the minimum interface that would allow them all. We'd have to agree what we want from identity management first; it seems like everybody's goals are different enough to make it a hard problem. --Ken _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
