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 | |
---|