Greetings, My apologies if this has been covered before. I've spent a good deal of time looking through the list archives and can't find an answer to this particular question.
I understand that to set up a MIT/AD trust using rc4-hmac keys, the AD KDCs need to be running 2003 SP1. My question is this: what's the worst that can happen using des-cbc if you're not ready to move to SP1? Assuming for the moment that the des key is more-or-less trivially breakable in something close to realtime by someone who really wants to, what is the scope of the damage that a miscreant can cause after they've broken it? I'll explain what I understand about the process from reading all the documentation I've been able to find. Perhaps someone can correct any false assumptions I've been making. For the sake of clarity, I'll use ADREALM as our AD realm and MITREALM as our MIT realm. When we initially establish the trust, we create a krbtgt/[EMAIL PROTECTED] TGT principal with a des-encrypted key. This key is encrypted with some suitably complex passphrase that we then use to set up the trust on the AD KDCs. Later, when a client somewhere in ADREALM requests a service ticket for ldap/foo.ad.uchicago from the MIT realm, the MIT realm then responds with the krbtgt/ADREALM referral. What happens next? >From what I've been able to gather from Microsoft's documentation and from the Kerberos Working Group's "kerberos referrals" draft, the AD KDC takes this referral ticket and attempts to decrypt it using the passphrase used to establish the trust. If this decryption succeeds, the AD KDC will know that the TGT came from MITREALM, and since MITREALM is trusted, issue the service ticket or another referral, depending on where the service is actually located. Am I correct? Is the successful decryption of the krbtgt/[EMAIL PROTECTED] referral ticket the sole basis of the AD realm's trust that [EMAIL PROTECTED] really has proved themselves to the MIT realm, and really is [EMAIL PROTECTED] (and whatever AD user that principal is mapped to)? I initially thought that there was some other cryptographic mechanism inside the referral ticket that the AD KDCs could use to verify that the user was the user they claim to be, but it occurs to me that the only thing that the AD KDCs know that the MIT KDCs also know is the passphrase we supplied when we manually established the trust. If this is the case, my (admittedly incomplete) understanding of the situation leads me to believe that someone could obtain this trust passphrase by cracking this "weakly" encrypted TGT referral ticket. We're not particularly worried about the damage that could be done in the lifetime of the user's MIT TGT, but if the miscreant can obtain this passphrase, what about the whole interchange prevents them from being able to forge krbtgt/[EMAIL PROTECTED] referrals and present them to the AD KDCs for service tickets (for any MITREALM user and his/her corresponding AD identities at any time)? Is there some facility in the referral that establishes a finite lifetime and the identity of the user principal name for the ticket that can be verified by the AD KDCs and can not be forged with knowledge only of the trust passphrase? As it's been pointed out to me, many of our peer institutions have accepted the risk and have set up trusts in their production domains using des-cbc keys. What do they know that I don't? Thanks! David Ressman The University of Chicago ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
