potential for harm in DES AD/MIT trust

[David Ressman]

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/ADREALM at MITREALM
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/ADREALM at MITREALM
referral ticket the sole basis of the AD realm's trust that user at MITREALM
really has proved themselves to the MIT realm, and really is user at MITREALM
(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/ADREALM at MITREALM 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