The following text was taken from the patchkit disabling cross-realm
authentication and triple-DES in krb4.

PATCH KIT DESCRIPTION
=====================

** FLAG DAY REQUIRED **

One of the things we decided to do (and must do for security reasons)
was drop support for the 3DES krb4 TGTs.  Unfortunately the current
code will only accept 3DES TGTs if it issues 3DES TGTs.  Since the new
code issues only DES TGTs, the old code will not understand its v4
TGTs if the site has a 3DES key available for the krbtgt principal.
The new code will understand and accept both DES and 3DES v4 TGTs.

So, the easiest upgrade option is to deploy the code on all KDCs at
once, being sure to deploy it on the master KDC last.  Under this
scenario, a brief window exists where slaves may be able to issue
tickets that the master will not understand.  However, the slaves will
understand tickets issued by the master throughout the upgrade.

An alternate and more annoying upgrade strategy exists.  At least one
max TGT life time before the upgrade, the TGT key can be changed to be
a single-des key.  Since we support adding a new TGT key while
preserving the old one, this does not create an interruption in
service.  Since no 3DES key is available then both the old and new
code will issue and accept DES v4 TGTs.  After the upgrade, the TGT
key can again be rekeyed to add 3DES keys.  This does require two TGT
key changes and creates a window where DES is used for the v5 TGT, but
creates no window in which slaves will issue TGTs the master cannot
accept.

* What the patch does
=====================

1) Kerberos 4 cross-realm authentication is disabled by default.  A
   "-X" switch is added to both krb524d and krb5kdc to enable v4
   cross-realm.  This switch logs a note that a security hole has been
   opened in the KDC log.  We said while designing the patch, that we
   were going to try to allow per-realm configuration; because of a
   design problem in the kadm5 library, we could not do this without
   bumping the ABI version of that library.  We are unwilling to bump
   an ABI version in a security patch release to get that feature, so
   the configuration of v4 cross-realm is a global switch.

2) Code responsible for v5 TGTs has been changed to require that the
   enctype of the ticket service key be the same as the enctype that
   would currently be issued for that kvno.  This means that even if a
   service has multiple keys, you cannot use a weak key to fake the
   KDC into accepting tickets for that service.  If you have a non-DES
   TGT key, this separates keys used for v4 and v5.  We actually relax
   this requirement for cross-realm TGT keys (which in the new code
   are only used for v5) because we cannot guarantee other Kerberos
   implementations will choose keys the same way.

3) We no longer issue 3DES v4 tickets either in the KDC or krb524d.
   We add code to accept either DES or 3DES tickets for v4.  None of
   the attacks discovered so far can be implemented given a KDC that
   accepts but does not issue 3DES tickets, so we believe that leaving
   this functionality in as compatibility for a version or two is
   reasonable.  Note however that the attacks described do allow
   successful attackers to print future tickets, so sites probably
   want to rekey important keys after installing this update.  Note
   also that even if issuance of 3DES v4 tickets has been disabled,
   outstanding tickets may be used to perform the 3DES cut-and-paste
   attack.

* Test Cases
============

This code is difficult to test for two reasons.  First, you need a
cross-realm  relationship between two KDCs.  Secondly, you need a KDC
that will issue 3DES v4 tickets even though the code  with the patch
applied can no longer do this.

I propose to meet these requirements by setting up a cross-realm 3DES
key between  a realm I control and the test environment.  In order to
provide concrete examples of what I plan to test with the automated
tests,  I assume a shared key between a realm PREPATCH.KRBTEST.COM and the
test realm PATCH.

In all of the following tests  I assume the following configuration.
A principal v4test@PREPATCH.KRBTEST.COM exists with known password and
without requiring preauthentication.  The PREPATCH.KRBTEST.COM KDC will
issue v4 tickets for this principal.  A principal test@PATCH exists
with known password and without requiring preauthentication.    A
principal service@PATCH exists.  The TGT for the PATCH realm has a
3des and des key.  The shared TGT keys between PATCH and
PREPATCH.KRBTEST.COM are identical in both directions (required for v4) and
support both 3DES and DES keys.

1) Run krb524d and krb5kdc for PATCH with no special options using a
   krb5.conf without permitted_enctypes (fully permissive).


A) Get v4 tickets as v4test@PREPATCH.KRBTEST.COM.  Confirm that  kvno -4
service@PATCH  fails with an unknown principal error and logs an error
about cross-realm being denied to the PATCH KDC log. This confirms
that v4 cross-realm is not accepted.

B) Get v5 tickets as v4test@PREPATCH.KRBTEST.COM.  Confirm that krb524init
-p service@PATCH fails with a prohibited by policy  error, but that
klist -5 includes a ticket for service@PATCH.  This confirms that v5
cross-realm works but the krb524d denies converting such a ticket into
a cross-realm ticket. Note that the krb524init currently in the
mainline source tree will not be useful for this test because the
client denies cross-realm for the simple reason that the v4 ticket
file format is not flexible enough to support it.  The krb524init in
the  1.2.x release is useful for this test.


2) Restart the krb5kdc and krb524d for PATCH with the -X option
   enabling v4 cross-realm.

A) Confirm that the security warning is written to kdc.log.

B) Get v4 tickets as v4test@PREPATCH.KRBTEST.COM.  Confirm that kvno -4
service@PATCH works and leaves a service@PATCH ticket in the cache.
This confirms that v4 cross-realm works in the KDC.  It also  confirms
that the KDC can accept 3DES v4 TGTs.  The code path for decrypting a
TGT is the same for the local realm and for foreign realms, so I don't
see a need to test local 3DES TGTs in an automated manner although I
did test it manually.

C) Get v5 tickets as v4test@PREPATCH.KRBTEST.COM.  Confirm that krb524init
-p service@PATCH works.    This confirms that krb524d will issue
cross-realm tickets.  They're completely useless because the v4 ticket
file can't represent them, but that's not our problem today.

3) Start the kdc and krb524d with a krb5.conf that  includes
   permitted_enctypes only listing des-cbc-crc.  Get tickets as
   test@PATCH.  Restart the KDC  and confirm that kvno service fails
   logging an error about permitted enctypes.  This confirms that if
   you manage to obtain a ticket of the wrong enctype it will not be
   accepted later.

These tests do not check to make sure that  3DES tickets are not
issued by the v4 code.  I'm fairly certain that is true as I've
physically remove the calls to the routine that generates 3DES tickets
from the code in both the KDC and krb524d.  These tests also do not
check to make sure that  cross-realm TGTs are not required to follow
the strict enctype policy.  I've tested that manually  but don't know
how to test that without  significantly complicating the test setup.
