Why use Kerberos V4, when V5 is around the corner? V4 has had large scale testing, both at MIT and across the Internet, at commercial and academic sites. It has been ported across Unix, VMS, Mac, and PC platforms. There is a great deal of experience with both the administrative and security aspects of Kerberos V4, while V5 is only in beta test now. V5 does include improvements, enhancements, and new features over V4. There are a small set of problems with V4 that have been uncovered; most of them are only inconvenient, or won't be problems until it is scaled to the entire Internet. A few are subtle cryptographic problems that need to be fixed but do not present a practical risk in normal operations. Inconveniences and scaling problems in V4 that are fixed in V5: V4 assumes IP. Kerberos V4 assumes that machines have IP addresses (it makes no assumptions about how the packets travel, only about how the machines are "named".) V5 fixes this by adding type tags to all network addresses. V4 assumes that there are only two byte orders. This is not a practical problem, but is addressed by the use of ASN.1 encoding for all messages in V5. V4 uses fixed length (40 character) names. While 40 characters is enough for names in current Unix environments, and it suffices for the domain name service as it stands, it is an arbitrary limit which will eventually be reached. V5 handles this by using the ASN.1 "GeneralString" type for all names. V4 requires n^2 key exchanges for interrealm authentication. Each pair of realms that need to cross-authentication with each other need to have a shared key securely installed. This requires n^2 key exchanges for n realms all mutually communicating, which would be a severe key management problem. V5 solves the problem by providing hierarchical trust with optional "shortcuts" along commonly-used trust paths, cutting size of the problem down to log n. V4 passwords generate same keys in different realms. If a user uses the same password in two different realms, the key generated from the password is the same, leaving the possibility of compromise in one realm by administrators in another even if there isn't cross realm trust. V5 addresses this by "seeding" the conversion with a realm-specific string. V4 tickets have sections of multiply encrypted data. Certain information in the V4 ticket is redundantly encrypted; the ticket layout has been redesigned in V5 keeping in mind the expense of encryption. Cryptographic problems in V4: V4 uses a flawed blocked-stream encryption method. V4 uses "permuted" cipher block chaining, and attempt to provide additional integrity checking by further propagating errors between encrypted blocks in a sequence. It was discovered that exchanging certain blocks in a message would exchange the corresponding blocks in the plaintext. In a practical sense, this would be very difficult to exploit, as it would require being able to spoof the underlying stream protocol well enough that reordering of 8 byte blocks wasn't detected through some other means, and there would have to be a circumstance in which performing the reordering of unknown encrypted data would provide a meaningful result. V5 solves this by using explicit cryptographic checksums to protect against reordering, and abandons the use of PCBC. V4 uses a flawed cryptographic checksum. The V4 implementation of quadratic checksum doesn't actually match the mathematical specification of it; it is unknown how secure it is (no successful attacks have yet been made.) V5 tags the checksum type used, and includes CRC32, DES MAC, and MD-4 implementations. V4 only uses DES encryption. While DES has not been "broken" as an encryption system, it is possible that in the next several decades it may become vulnerable to brute force attacks if nothing else. V5 tags all encrypted data with the encryption technique used, so that other encryption systems can be dropped in as needed. V4 is vulnerable to offline password attacks. Once an initial ticket is requested, it can be attacked "at leisure" by itself without further interaction with the server; once the key is discovered, it can be used in a new request. This is merely a brute force attack, which is best addressed by choice of good passwords. However, it is possible to use alternate authentication devices to provide further protection for this; V5 includes hooks for adding such support (although no such support actually exists yet.) What new things have been added to V5? V5 has "user to user authentication." Under V4, there is an asymmetry in authentication caused by the use of the Ticket Granting Ticket. This minimizes the exposure of the initial password, but also means that user keys are treated slightly differently than stored keys for services. This means that you can only meaningfully authenticate to a service, not to a user. V5 provides a way to directly authenticate to a user, which allows users to provide services directly on their own behalf rather than in the name of the machine they're using. V5 has ticket life time enhancements. V5 makes it possible to request tickets that can be renewed or have more unusual lifetimes than the 21 hour range that V4 limits you to. V5 allows forwardable tickets. V4 binds tickets to the machine you are on as an additional security feature; this can be inconvenient, so V5 adds (as a site-local security option) the ability to have tickets that can be forwarded for use from other machines. This does provide an additional user security risk and can thus be disabled. V5 supports "authorization data." Kerberos V4 kept authentication and authorization completely separate. V5 has some experimental extensions to support direct authorization, though it is still kept application specific. V5 is being proposed as an Internet Standard. One of the reasons to clean up even the minor inconveniences for V5 is that it is being proposed as an Internet Standard. It is unknown as yet what affect this process will have.