Adam Megacz wrote: > I really think it's more of a political issue than anything else; I > doubt they'd ever accept anything involving public key crypto as an > "official, standard, core" part of Kerberos. And I can't say I > disagree with them.
Its not a political issue. Its a resource issue. If you want to work on PKCROSS become active in the IETF Kerberos Working Group, volunteer to become editor of the draft, and assist in the development of an implementation. Enabling policy driven automated key exchange for Kerberos realms is a requirement for a large number of problem spaces. I want to see Kerberos be used to address the needs of the Web 2.0 community. That community requires zero conf. > I'm willing to contribute substantial developer-hours to realizing the > goal of easy, administrator-intervention-free cross-realm and > non-realm authentication. And I'm very flexible in terms of taking > direction from people who've been around OpenAFS longer than I have on > how this ought to be achieved. But if changing the "upstream" > Kerberos just to improve AFS is a prerequesite, I think this might be > a bigger task than I want to take on (or have the motivation to see > through). As I pointed out in other e-mails, there is nothing that prevents you from developing user friendly front ends that would allow you to deploy Kerberos or non-Kerberos solutions today for AFS. The binding between AFS and Kerberos is not as tight as you believe. The AFS token format happens to be the same as a Kerberos ticket. The only requirement is that the client be able to authenticate to a service and obtain something that looks like a Kerberos ticket signed with the AFS service key. AFS really doesn't care if the token actually is the result of a Kerberos authentication or not. The krb524 daemon does exactly this. When AFS did not understand Kerberos 5 ticket formats, the client would authenticate with Kerberos 5 and contact a krb524 daemon to validate the authentication and print a new ticket in a format the AFS service would understand. The same is true of gssklog. It uses a GSSAPI authentication to which results in a token being printed and given back to the client. You can do exactly the same thing for PGP today. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
