potential for harm in DES AD/MIT trust

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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@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@MITREALM
referral ticket the sole basis of the AD realm's trust that user@MITREALM
really has proved themselves to the MIT realm, and really is user@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@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
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: potential for harm in DES AD/MIT trust

Jeffrey Altman-3
David Ressman wrote:
> 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?

David:

The MIT Kerberos team worked with the Microsoft Windows Security team
to make sure that RC4-HMAC could be used for cross-realm authentication
by Windows Server specificly because of the concerns you raise.   DES
keys are very weak and if they must be used because that is all that is
supported, then they keys must be replaced on a very regular basis
until such time as they no longer need to be used.

With 2003 Server SP1 there should no longer be a reason to use DES keys
for anything but compatibility with Java 1.5 and earlier.

Jeffrey Altman


--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: potential for harm in DES AD/MIT trust

David Botsch
Running Win 2003 SP1 and Win2000 latest SP (forget the num), we were forced to
add in the des-cbc-md5 encryption type for all users. The reason seemed to have
to do w. the session key being set up for the user.

So, we've seen the following behavior:

AS-REP has the TGT encrypted with des3-cbc-sha1, the reply itself encrtyped
with arcfour, and a session key of des-cbc-crc.

The TGS-REP for the cross-realm Active Directory tgt has a reply encrypted with
des-cbc-crc, ticket encrypted with des-cbc-md5, and session key of des-cbc-crc

Using the arcfour encrypted type for the cross realm tgt principal did not work
(in fact, MS's documentation mentions this). So, we had to set up the cross
realm principal with the des-cbc-md5 encryption type.

When we did not add the des-cbc-md5 type to the individual principals, the
server would choose to use des3-sha1 which, of course, Windows does not parse
:(

We're running MIT Kerbeors 1.3.5 with the latest security patches.

On Sat, Jun 04, 2005 at 03:27:27PM +0000, Jeffrey Altman wrote:

> David Ressman wrote:
> > 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?
>
> David:
>
> The MIT Kerberos team worked with the Microsoft Windows Security team
> to make sure that RC4-HMAC could be used for cross-realm authentication
> by Windows Server specificly because of the concerns you raise.   DES
> keys are very weak and if they must be used because that is all that is
> supported, then they keys must be replaced on a very regular basis
> until such time as they no longer need to be used.
>
> With 2003 Server SP1 there should no longer be a reason to use DES keys
> for anything but compatibility with Java 1.5 and earlier.
>
> Jeffrey Altman
>
>
> --
> -----------------
> This e-mail account is not read on a regular basis.
> Please send private responses to jaltman at mit dot edu
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
[hidden email]
********************************
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: potential for harm in DES AD/MIT trust

Brian Davidson
In reply to this post by Jeffrey Altman-3
On Jun 4, 2005, at 11:27 AM, Jeffrey Altman wrote:

> The MIT Kerberos team worked with the Microsoft Windows Security team
> to make sure that RC4-HMAC could be used for cross-realm authentication
> by Windows Server specificly because of the concerns you raise.   DES
> keys are very weak and if they must be used because that is all that is
> supported, then they keys must be replaced on a very regular basis
> until such time as they no longer need to be used.
>
> With 2003 Server SP1 there should no longer be a reason to use DES keys
> for anything but compatibility with Java 1.5 and earlier.

Has anyone had success with this?  I just tried to use RC4-HMAC for a
cross-realm trust with Server 2003 SP1, and it didn't work.  I could
only get the trust to work with a DES key.

Do you know if Microsoft has any of this documented anywhere?  I didn't
see any mention of this in the "Windows Server 2003 Service Pack 1 list
of updates"

I'm hoping there's just a registry setting that needs to be made to
enable this...

Thanks,

Brian Davidson
George Mason University

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: potential for harm in DES AD/MIT trust

chudler
Brian Davidson wrote:

> On Jun 4, 2005, at 11:27 AM, Jeffrey Altman wrote:
>
>> The MIT Kerberos team worked with the Microsoft Windows Security team
>> to make sure that RC4-HMAC could be used for cross-realm authentication
>> by Windows Server specificly because of the concerns you raise.   DES
>> keys are very weak and if they must be used because that is all that is
>> supported, then they keys must be replaced on a very regular basis
>> until such time as they no longer need to be used.
>>
>> With 2003 Server SP1 there should no longer be a reason to use DES keys
>> for anything but compatibility with Java 1.5 and earlier.
>
>
> Has anyone had success with this?  I just tried to use RC4-HMAC for a
> cross-realm trust with Server 2003 SP1, and it didn't work.  I could
> only get the trust to work with a DES key.
>
> Do you know if Microsoft has any of this documented anywhere?  I
> didn't see any mention of this in the "Windows Server 2003 Service
> Pack 1 list of updates"
>
> I'm hoping there's just a registry setting that needs to be made to
> enable this...
>
> Thanks,
>
> Brian Davidson
> George Mason University
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Hi Brian,

After setting the trust, install Windows 2003 SP1 Support tools, then run

ktpass -MitRealmName <REALM> -TrustEncryp RC4

I do not know where or if this is documented (besides the /? of
ktpass).  By the way, RC4 is not the default despite what "ktpass /? "
might say.   Hope that helps.

--
Colin Hudler
University of Chicago
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos