The reason for my inquiry about the krb524 migration...
------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Tom Yu [mailto:[EMAIL PROTECTED] > Sent: Monday, March 17, 2003 2:21 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: MITKRB5-SA-2003-004: Cryptographic weaknesses in > Kerberos v4 protocol > > > -----BEGIN PGP SIGNED MESSAGE----- > > MIT krb5 Security Advisory 2003-004 > > 2003-03-17 > > Topic: Cryptographic weaknesses in Kerberos v4 protocol > > Severity: CRITICAL > > SUMMARY > ======= > > A cryptographic weakness in version 4 of the Kerberos protocol allows > an attacker to use a chosen-plaintext attack to impersonate any > principal in a realm. Additional cryptographic weaknesses in the krb4 > implementation included in the MIT krb5 distribution permit the use of > cut-and-paste attacks to fabricate krb4 tickets for unauthorized > client principals if triple-DES keys are used to key krb4 services. > These attacks can subvert a site's entire Kerberos authentication > infrastructure. > > Kerberos version 5 does not contain this cryptographic vulnerability. > Sites are not vulnerable if they have Kerberos v4 completely disabled, > including the disabling of any krb5 to krb4 translation services. > > IMPACT > ====== > > * An attacker controlling a krb4 shared cross-realm key can > impersonate any principal in the remote realm to any service in the > remote realm. This can lead to root-level compromise of a KDC, > along with compromise of any hosts that rely on authentication > provided by that KDC. > > * This attack may be performed against cross-realm principals, thus > allowing an attacker to hop realms and compromise any realm that > transitively shares a cross-realm key with the attacker's local > realm. > > * Related, but more difficult attacks may be possible without > requiring the control of a shared cross-realm key. At the very > least, an attacker capable of creating arbitrary principal names in > the target realm may be able to perform the attack. > > * An attacker may impersonate any principal to a service keyed with > triple-DES krb4 keys, given the ability to capture network traffic > containing tickets for the target client principal. > > * A leak has occurred of an unpublished paper containing enough > details about the vulnerability that an attacker familiar with the > krb4 protocol can easily construct an exploit. No exploit is known > to be circulating at this time, though. > > AFFECTED SOFTWARE > ================= > > * These are protocol vulnerabilities; ALL implementations of > vulnerable functionality are vulnerable. > > * All implementations of the Kerberos version 4 Key Distribution > Center that allow cross-realm authentication are vulnerable. > > * All implementations of the Kerberos version 5 Key Distribution > Center that also implement a KDC for the Kerberos version 4 protocol > and use the same keys for version 4 and version 5 are vulnerable. > > * MIT implementations of krb5 that include support for triple-DES keys > in krb4 are vulnerable. > > FIX > === > > * These are PROTOCOL vulnerabilities; fixes inherently involve > restricting the functionality of the protocol. > > * If you are using the implementation of krb4 contained in the MIT > krb5, apply the patch kit, which is available at > > > http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patch > kit.tar.gz > > The detached PGP signature of the patch kit is available at > > > http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patchkit.sig > > * Release 1.3 of MIT krb5 will include a fix. The fix has also been > committed to our development source tree. > > * If you are running MIT release krb5-1.2.6 or later, and you are > unable to patch your production code, setting the DISALLOW_ALL_TIX > or the DISALLOW_SVR attributes on all cross-realm principals should > disable cross-realm authentication without losing key information. > This will, of course, cause loss of krb5 cross-realm functionality. > Note that the functionality of these principal attributes has not > been extensively tested. > > * If using the Kerberos v4 implementation contained in MIT krb5, and > you are unable to patch your production systems, cease use of > triple-DES keys for Kerberos v4 services. > > * If using a different implementation of krb4, disable all krb4 > cross-realm functionality, both in KDC implementations and in any > krb524d implementations. > > * A possible workaround is to randomize all cross-realm keys. This > should be considered to be a last resort, as re-establishing > cross-realm keys can be time-consuming, and krb5 cross-realm > functionality will be lost. > > * The following text describes the patch kit for the MIT krb5 > implementation. > > 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. > > REFERENCES > ========== > > This announcement and related security advisories may be found on the > MIT Kerberos security advisory page at: > > http://web.mit.edu/kerberos/www/advisories/index.html > > The main MIT Kerberos web page is at: > > http://web.mit.edu/kerberos/www/index.html > > [note that these CERT Vulnerability Notes have not yet been published] > > CERT VU#623217 > > http://www.kb.cert.org/vuls/id/623217 > > CERT VU#442569 > > http://www.kb.cert.org/vuls/id/442569 > > ACKNOWLEDGMENTS > =============== > > This advisory was written by Sam Hartman and Tom Yu. Ken Raeburn > participated in the analysis of the cryptographic vulnerabilities. > > Steve Bellovin provided some hints that led us to discover this > vulnerability. > > Sam Hartman developed the patch kit for MIT krb5 implementations. > > CONTACT > ======= > > For more information, contact Sam Hartman <[EMAIL PROTECTED]>, or > Marshall Vale <[EMAIL PROTECTED]>. > > DETAILS > ======= > > * Abstract > ========== > > Several cryptographic vulnerabilities exist in the basic Kerberos > Version 4 protocol that could allow an attacker to impersonate any > user in a Kerberos realm and gain any privilege authorized through > that Kerberos realm. Knowledge of the key shared between two realms > for Kerberos 4 cross-realm authentication or the ability to create > arbitrary principals in a realm is sufficient to print any ticket in > the realm. As an example, knowing [EMAIL PROTECTED] > is sufficient to print an Athena TGT for any Athena realm client. > Additional vulnerabilities in a MIT extension to use triple DES keys > for Kerberos 4 tickets may allow attackers who can passively observer > the network to construct tickets for some users if certain alignment > constraints are met. > > The Kerberos 5 protocol is not vulnerable to this issue. However, > implementations that implement both Kerberos 4 and Kerberos 5 tend to > use the same keys for both protocols. As a result, the Kerberos 4 > vulnerabilities can be used to compromise Kerberos 5 services at sites > using these implementations. > > * Brief Problem Description > =========================== > > Kerberos version 4 tickets include neither a cryptographic hash of the > encrypted data, random padding, nor a random initial vector. As such, > if an attacker can cause the right text to be encrypted in a Kerberos > service key, then the attacker can fabricate a ticket. Normally an > attacker does not control much of the text in the ticket so this > cryptographic weakness is hard to exploit. > > The initial portion of a Kerberos 4 ticket is a one-byte flags field > (either 0 or 1) followed by the client name. Since all of this > initial text is constant, the beginning of a ticket for a given > client/service will be the same. An attacker thus knows the > encryption of the initial plaintext in the service key. If an > attacker can control client principals whose names he chooses, then he > can get the encryption of these plaintext values in the service key. > > As a result of concerns about single DES weaknesses, MIT implemented > support for Kerberos 4 tickets encrypted in triple DES service keys. > This support shares all the cryptographic weaknesses of single DES > Kerberos 4. In addition, since it uses CBC mode rather than PCBC > mode, it introduces new weaknesses not found in other Kerberos 4 > implementations. When certain alignment constraints are met, it is > possible to splice two tickets together, allowing an attacker to get a > ticket with a known session key for a client without knowing that > client's long term key. This attack does require sniffing a ticket > for that client. > > We do not believe the password changing service is vulnerable to the > single DES attacks as the KDC will never issue password changing > tickets in an appl request. It is probably vulnerable to the triple > DES splicing attacks. > > * Specific Vulnerabilities > ========================== > > 1) ECB Oracle for Single DES > > By controlling principals of an attackers choice, an attacker can > encrypt arbitrary plaintext in a single DES service key. > > 2) ECB Oracle for Triple DES > > By controlling principals of an an attacker's choice, an attacker > can encrypt arbitrary plaintext in a triple DES service key. > > 3) PCBC First Block > > It turns out that being able to encrypt arbitrary plaintext is not > quite enough to construct a ticket for a single DES service key. > You also need to be able to construct the first block of the > ticket; you don't know what plaintext to use because the IV for > the first block is the long-term service key. However since the > only thing in the first block of the ticket is the first seven > bytes of the client, controlling a principal with the same first > seven bytes as the principal being attacked is sufficient to get > the first block. As a practical matter, principals whose > principal and instance components fit within six bytes (including > trailing nulls) may be harder to attack. > > 4) Cross Realm > > If realms A and B share a cross-realm key and the attacker knows > that key or can get arbitrary plaintext encrypted in that key, > then the attacker may get A to issue tickets for any principal > claiming to be in realm B and vice versa. This is sufficient to > meet conditions of vulnerabilities (1) and (2) above and to > encrypt arbitrary plaintext in the service keys of realm A and B. > > 5) Kerberos 4 Ticket Printing > > The conditions of (2) above are sufficient to print arbitrary > tickets in a triple DES service key. The conditions of (1) and > (3) are sufficient to print any ticket in a single DES service > key. > > 6) Kerberos 5 Ticket Printing > > The conditions of (1) above are sufficient to construct a > des-cbc-md4 or des-cbc-md5 Kerberos 5 ticket if the KDC uses the > same DES key for v4 and v5. While the Kerberos 5 ticket does have > a confounder and checksum, the checksum is not keyed and thus the > confounder and checksum can be fabricated by an attacker. We > believe that des-cbc-crc is safe unless you can contain a > ciphertext block and a corresponding plaintext block. However, > most Kerberos implementations will allow des-cbc-md5 to be used > even if des-cbc-crc is normally used. We are not aware of any > vulnerabilities in des3-hmac-sha1-kd or rc4-hmac-md5. > > 7) Ticket Splicing Attack > > A Kerberos 4 ticket contains an eight-byte session key. If client > principal names are chosen carefully then this session key will > line up with a DES block boundary. For triple DES service keys > this creates an opportunity for an attack. Consider the case > where an attacker has obtained a ticket t1 with a known session > key K and has sniffed a ticket t2 with unknown session key for the > same service. The attacker can create a new valid ticket t2' by > replacing the part of t2 starting with the session key block with > the session key from t1. This new ticket will have a session key > K XOR-ed with the ciphertext blocks proceeding the session key in > t1 and t2. In other words, if triple DES service keys are used, > client principals with the wrong name lengths are inherently > vulnerable to sniffing. > > 8) Realm Hopping > > Kerberos 4 does not normally support multi-hop cross-realm > authentication. However cross-realm tickets are just normal > service keys; points (1), (2) and (3) are sufficient to satisfy > the conditions of point (4) for a service key. That is, an > attacker can hop through realms, exploiting these vulnerabilities > against any realm that is in the transitive closure of the initial > realm. Anyone who shares keys with ATHENA.MIT.EDU now trusts > ZONE.MIT.EDU. > > 9) Krb 524 Does Not Help > > Traditionally realms desiring higher security but still wishing to > have some Kerberos 4 services have disabled KDC support for V4 and > used krb524d to issue only the services that are needed. These > vulnerabilities work as well against any service key that the > krb524d knows as they do against service keys in a v4 KDC. Of > course a fabricated krb5 ticket can be converted to Kerberos 4 > using krb524d. > > * Potential Solutions > ===================== > > 1) V4 Cross Realm Considered Harmful > > Kerberos implementations should gain an option to disable Kerberos > 4 cross-realm authentication both in the KDC and in any > implementations of the krb524 protocol. This configuration should > be the default. > > 2) Application Migration > > Application vendors and sites should migrate from Kerberos version > 4 to Kerberos version 5. The OpenAFS community has introduced > features that allow Kerberos 5 to be used for AFS in OpenAFS > 1.2.8. Patches are available to add Kerberos 5 support to > OpenSSH. Several other implementations of the SSH protocol also > support Kerberos 5. Applications such as IMAP, POP and LDAP > already support Kerberos 5. > > 3) TGT Key Separation > > One motivation for the V4 triple DES support is that if a single > DES key exists for the TGT principal then an attacker can attack > that key both for v4 and v5 tickets. Kerberos implementations > should gain support for a DES TGT key that is used for v4 requests > but not v5 requests. > > 4) Remove Triple DES Kerberos 4 Support > > The cut and paste attack is a critical failure in MIT's attempt at > Kerberos 4 Triple DES. Even without cross-realm authentication, > this can be exploited in real-world situations. As such the > support for 3DES service keys should be disabled. > > REVISION HISTORY > ================ > > 2003-03-15 A draft version of this text was leaked to the > full-disclosure list by unknown persons. > > 2003-03-17 original release > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (SunOS) > > iQCVAwUBPnWBm6bDgE/zdoE9AQEqywP/djVs+A4aTwJUTXzUHno5kGz1qEEzeF6v > Uda7/NZyswe7Prc4J8vP9NEUSb/aETLcWuUmSmzViy0yCl4LwiVRPwtQNnTkjHbb > aWp1xqbEjGmXlEpsf2y5vylbGBC0fBImf38UD8mw0qmjByLJ9+MQGUX0ggIgN72H > GtnGXq1m+Jw= > =ws8J > -----END PGP SIGNATURE----- > _______________________________________________ > kerberos-announce mailing list > [EMAIL PROTECTED] > http://mailman.mit.edu/mailman/listinfo/kerberos-announce > _______________________________________________ > krbdev mailing list [EMAIL PROTECTED] > https://mailman.mit.edu/mailman/listinfo/krbdev > _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
