potential for harm in DES AD/MIT trust - Kerberos

This is a discussion on potential for harm in DES AD/MIT trust - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: potential for harm in DES AD/MIT trust

  1. potential for harm in DES AD/MIT trust

    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: potential for harm in DES AD/MIT trust

    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

  3. Re: potential for harm in DES AD/MIT trust

    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 Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos


    --
    ********************************
    David William Botsch
    Consultant/Advisor II
    CCMR Computing Facility
    dwb7@ccmr.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: potential for harm in DES AD/MIT trust

    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: potential for harm in DES AD/MIT trust

    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 Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >

    Hi Brian,

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

    ktpass -MitRealmName -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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread