Add keytype support. Default to version 5 keys.
[heimdal.git] / doc / kerberos4.texi
blob7158ed0ced4024d429c8ea873282ff71759097b0
1 @node Kerberos 4 issues, Acknowledgments, Setting up a realm, Top
2 @comment  node-name,  next,  previous,  up
3 @chapter Kerberos 4 issues
5 If compiled with version 4 support, the KDC can serve requests from a
6 Kerberos 4 client. There are a few things you must do for this to work.
8 @menu
9 * Principal conversion issues::  
10 * Converting a version 4 database::  
11 @end menu
13 @node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues
14 @section Principal conversion issues
16 First, Kerberos 4 and Kerberos 5 principals are different. A version 4
17 principal consists of a name, an instance, and a realm. A version 5
18 principal has one or more components, and a realm @footnote{for the
19 common case of one and two component principals, we will refer to the
20 first component as the ``name'' and the second as the ``instance''}.
21 Also, in some cases the name of a version 4 principal differs from the
22 first component of the corresponding version 5 principal. One notable
23 example is the ``host'' type principals, where the version 4 name is
24 @samp{rcmd} (for ``remote command''), and the version 5 name is
25 @samp{host}. For the class of principals that has a hostname as
26 instance, there is an other major difference, Kerberos 4 uses only the
27 first component of the hostname, whereas Kerberos 5 uses the fully
28 qualified hostname.
30 Because of this it can in the general case can be hard or impossible to
31 correctly convert a version 4 principal to a version 5 principal
32 @footnote{the other way is not always trivial either, but usually
33 easier}. The biggest problem is to know if the conversion resulted in a
34 valid principal. To give an example, suppose you want to convert the
35 principal @samp{rcmd.foo}. 
37 The @samp{rcmd} name suggests that the instance is a hostname (even if
38 there are exceptions to this rule). To correctly convert the instance
39 @samp{foo} to a hostname, you have to know which host it referred to. You
40 can to this by either guessing (from the realm) which domain name to
41 append, or you have to have a list of possible hostnames. In the
42 simplest cases you can cover most principals with the first rule. If you
43 have several domains sharing a single realm this will not usually
44 work. If the exceptions are few you can probably come by with a lookup
45 table for the exceptions.
47 In a complex scenario you will need some kind of host lookup mechanism.
48 Using DNS for this is tempting, but DNS is error prone, slow and unsafe
49 @footnote{at least until secure DNS is commonly available}.
51 Fortunately, the KDC has a trump on hand: it can easily tell if a
52 principal exists in the database. The KDC will use
53 @code{krb5_425_conv_principal_ext} to convert principals.
55 @node Converting a version 4 database,  , Principal conversion issues, Kerberos 4 issues
56 @section Converting a version 4 database
58 If you want to convert an existing version 4 database, the principal
59 conversion issue arises too.
61 If you simply convert a database, this conversion will only take place
62 once. It is also possible to run a version 5 KDC as a slave. In this
63 case this conversion will happen every time the database is propagated.
64 When doing this conversion, there are a few things to look out for. If
65 you have stale entries in the database, these entries will not be
66 converted. This might be because these principals are not used anymore,
67 or it might be just because the principal couldn't be converted. 
69 You might also see problems with a many-to-one mapping of
70 principals. For instance, if you are using DNS lookups and you have two
71 principals @samp{rcmd.foo} and @samp{rcmd.bar}, where `foo' is a CNAME
72 for `bar', the resulting principals will be the same. Since the
73 conversion function can't tell which is correct, these conflicts will
74 have to be resolved manually.