--- /dev/null
+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.
projects / krb5.git / commitdiff