[8788] | 1 | Why use Kerberos V4, when V5 is around the corner? |
---|
| 2 | V4 has had large scale testing, both at MIT and across the |
---|
| 3 | Internet, at commercial and academic sites. It has been ported |
---|
| 4 | across Unix, VMS, Mac, and PC platforms. There is a great deal of |
---|
| 5 | experience with both the administrative and security aspects of |
---|
| 6 | Kerberos V4, while V5 is only in beta test now. |
---|
| 7 | V5 does include improvements, enhancements, and new features |
---|
| 8 | over V4. There are a small set of problems with V4 that have been |
---|
| 9 | uncovered; most of them are only inconvenient, or won't be |
---|
| 10 | problems until it is scaled to the entire Internet. A few are |
---|
| 11 | subtle cryptographic problems that need to be fixed but do not |
---|
| 12 | present a practical risk in normal operations. |
---|
| 13 | |
---|
| 14 | Inconveniences and scaling problems in V4 that are fixed in V5: |
---|
| 15 | V4 assumes IP. |
---|
| 16 | Kerberos V4 assumes that machines have IP addresses (it |
---|
| 17 | makes no assumptions about how the packets travel, only |
---|
| 18 | about how the machines are "named".) V5 fixes this by |
---|
| 19 | adding type tags to all network addresses. |
---|
| 20 | V4 assumes that there are only two byte orders. |
---|
| 21 | This is not a practical problem, but is addressed by the |
---|
| 22 | use of ASN.1 encoding for all messages in V5. |
---|
| 23 | V4 uses fixed length (40 character) names. |
---|
| 24 | While 40 characters is enough for names in current Unix |
---|
| 25 | environments, and it suffices for the domain name service |
---|
| 26 | as it stands, it is an arbitrary limit which will |
---|
| 27 | eventually be reached. V5 handles this by using the ASN.1 |
---|
| 28 | "GeneralString" type for all names. |
---|
| 29 | V4 requires n^2 key exchanges for interrealm authentication. |
---|
| 30 | Each pair of realms that need to cross-authentication with |
---|
| 31 | each other need to have a shared key securely installed. |
---|
| 32 | This requires n^2 key exchanges for n realms all mutually |
---|
| 33 | communicating, which would be a severe key management |
---|
| 34 | problem. V5 solves the problem by providing hierarchical |
---|
| 35 | trust with optional "shortcuts" along commonly-used trust |
---|
| 36 | paths, cutting size of the problem down to log n. |
---|
| 37 | V4 passwords generate same keys in different realms. |
---|
| 38 | If a user uses the same password in two different realms, |
---|
| 39 | the key generated from the password is the same, leaving |
---|
| 40 | the possibility of compromise in one realm by |
---|
| 41 | administrators in another even if there isn't cross realm |
---|
| 42 | trust. V5 addresses this by "seeding" the conversion with a |
---|
| 43 | realm-specific string. |
---|
| 44 | V4 tickets have sections of multiply encrypted data. |
---|
| 45 | Certain information in the V4 ticket is redundantly |
---|
| 46 | encrypted; the ticket layout has been redesigned in V5 |
---|
| 47 | keeping in mind the expense of encryption. |
---|
| 48 | |
---|
| 49 | Cryptographic problems in V4: |
---|
| 50 | V4 uses a flawed blocked-stream encryption method. |
---|
| 51 | V4 uses "permuted" cipher block chaining, and attempt to |
---|
| 52 | provide additional integrity checking by further |
---|
| 53 | propagating errors between encrypted blocks in a sequence. |
---|
| 54 | It was discovered that exchanging certain blocks in a |
---|
| 55 | message would exchange the corresponding blocks in the |
---|
| 56 | plaintext. In a practical sense, this would be very |
---|
| 57 | difficult to exploit, as it would require being able to |
---|
| 58 | spoof the underlying stream protocol well enough that |
---|
| 59 | reordering of 8 byte blocks wasn't detected through some |
---|
| 60 | other means, and there would have to be a circumstance in |
---|
| 61 | which performing the reordering of unknown encrypted data |
---|
| 62 | would provide a meaningful result. V5 solves this by using |
---|
| 63 | explicit cryptographic checksums to protect against |
---|
| 64 | reordering, and abandons the use of PCBC. |
---|
| 65 | V4 uses a flawed cryptographic checksum. |
---|
| 66 | The V4 implementation of quadratic checksum doesn't |
---|
| 67 | actually match the mathematical specification of it; it is |
---|
| 68 | unknown how secure it is (no successful attacks have yet |
---|
| 69 | been made.) V5 tags the checksum type used, and includes |
---|
| 70 | CRC32, DES MAC, and MD-4 implementations. |
---|
| 71 | V4 only uses DES encryption. |
---|
| 72 | While DES has not been "broken" as an encryption system, it |
---|
| 73 | is possible that in the next several decades it may become |
---|
| 74 | vulnerable to brute force attacks if nothing else. V5 tags |
---|
| 75 | all encrypted data with the encryption technique used, so |
---|
| 76 | that other encryption systems can be dropped in as needed. |
---|
| 77 | V4 is vulnerable to offline password attacks. |
---|
| 78 | Once an initial ticket is requested, it can be attacked "at |
---|
| 79 | leisure" by itself without further interaction with the |
---|
| 80 | server; once the key is discovered, it can be used in a new |
---|
| 81 | request. This is merely a brute force attack, which is best |
---|
| 82 | addressed by choice of good passwords. However, it is |
---|
| 83 | possible to use alternate authentication devices to provide |
---|
| 84 | further protection for this; V5 includes hooks for adding |
---|
| 85 | such support (although no such support actually exists yet.) |
---|
| 86 | |
---|
| 87 | What new things have been added to V5? |
---|
| 88 | V5 has "user to user authentication." |
---|
| 89 | Under V4, there is an asymmetry in authentication caused by |
---|
| 90 | the use of the Ticket Granting Ticket. This minimizes the |
---|
| 91 | exposure of the initial password, but also means that user |
---|
| 92 | keys are treated slightly differently than stored keys for |
---|
| 93 | services. This means that you can only meaningfully |
---|
| 94 | authenticate to a service, not to a user. V5 provides a way |
---|
| 95 | to directly authenticate to a user, which allows users to |
---|
| 96 | provide services directly on their own behalf rather than |
---|
| 97 | in the name of the machine they're using. |
---|
| 98 | V5 has ticket life time enhancements. |
---|
| 99 | V5 makes it possible to request tickets that can be renewed |
---|
| 100 | or have more unusual lifetimes than the 21 hour range that |
---|
| 101 | V4 limits you to. |
---|
| 102 | V5 allows forwardable tickets. |
---|
| 103 | V4 binds tickets to the machine you are on as an additional |
---|
| 104 | security feature; this can be inconvenient, so V5 adds (as |
---|
| 105 | a site-local security option) the ability to have tickets |
---|
| 106 | that can be forwarded for use from other machines. This |
---|
| 107 | does provide an additional user security risk and can thus |
---|
| 108 | be disabled. |
---|
| 109 | V5 supports "authorization data." |
---|
| 110 | Kerberos V4 kept authentication and authorization |
---|
| 111 | completely separate. V5 has some experimental extensions to |
---|
| 112 | support direct authorization, though it is still kept |
---|
| 113 | application specific. |
---|
| 114 | V5 is being proposed as an Internet Standard. |
---|
| 115 | One of the reasons to clean up even the minor |
---|
| 116 | inconveniences for V5 is that it is being proposed as an |
---|
| 117 | Internet Standard. It is unknown as yet what affect this |
---|
| 118 | process will have. |
---|
| 119 | |
---|