>Ken Hornstein <[EMAIL PROTECTED]> writes: >> Maybe it's me, but I've never really seen the difference between a junk >> certificate and a Kerberos ticket; > >Somebody with no prior trust relationship can check the validity of a >junk certificate.
Can they? How do they verify a certificate if they don't have some sort of trust relationship with a realm? I need to somehow securely get ahold of a CA certificate to verify a junk certificate. So if I'm an application server (using the Kerberos parlance), I still need to be told about the the CA certificate in some secure manner ... just like in Kerberos I need to be given a service key in a secure manner. In theory you don't need to encrypt the CA certificate, but you should verify it's integrity somehow. This is one of the places where PKI tends to cheat; it works great in the usual case where web browsers have a standard list of CAs that they accept. >> I'm confused; do you know about some cryptosystem that I don't that >> doesn't require users to know some sort of key? > >Asymmetric cryptography eliminates the need for the party verifying >the key to share a secret with the certificate issuer. While I agree it removes the need to share a _secret_, they still need to have some sort of trust relationship that should in theory involve some out-of-band initialization. At the end of the day, I don't see this fundamentally easier than the initialization that Kerberos does. The one big advantage with public key crypto in this case is that if the application server's CA list is discovered, there is no security vulnerability introduced. If an application server's Kerberos service key is discovered, that's a big problem. But that doesn't change the _management_ cost in the general case. >This is the problem with Kerberos when you try to expand beyond a >single administrative domain (or more than a few for whom it is >feasible to do N^2 cross-realm): you have to hunt down the KDC admin >and cajole him/her into doing you a favor. (Technically, it's ((N - 1) ^ 2) * 2, but it's still O(N^2), so I suppose that's quibbling). Well ... as a KDC admin, I'm not sure I want to let any random realm out there authenticate with my realm without doing some sort of validation. I could see a case where two different people could claim to be UNLV.EDU (someone could purchase a certificate from an unscrupulous CA), and I want to be sure that the "right" one is the one I accept. I would suspect that most KDC admins feel the same. One purpose the cross-realm authentication process serves right now is checking that. Now, the actual _crypto_ part of that sucks (having done it too many times). There are a couple of ways to alleviate that pain. One is transitive cross-realm; I've used that in practice, and that works well (you have to transit multiple realms instead of each one directly). Instead of having to key each pair directly, I have to edit a config file and say, "this path is valid". As other people have mentioned, PKCROSS is an option. The various people in the Kerberos community all think it's a reasonable idea, so it's not politically contentous. All it needs is someone with the will to do the actual work (from a standards point of view, and the actual bit fiddling). --Ken _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
