source: trunk/third/cns/doc/why-v4.text @ 8789

Revision 8789, 6.2 KB checked in by ghudson, 28 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r8788, which included commits to RCS files with non-trunk default branches.
Line 
1Why 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
14Inconveniences 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
49Cryptographic 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
87What 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
Note: See TracBrowser for help on using the repository browser.