1krb5_fileformats(3) HeimdalKerberos5library krb5_fileformats(3)
2
6 krb5_fileformatsFile formats
7 -
8
10 This section documents the diffrent file formats that are used in
11 Heimdal and other Kerberos implementations.
12 keytab
14 The keytab binary format is not a standard format. The format has
15 evolved and may continue to. It is however understood by several
16 Kerberos implementations including Heimdal, MIT, Sun's Java ktab and
17 are created by the ktpass.exe utility from Windows. So it has
18 established itself as the defacto format for storing Kerberos keys.
19 The following C-like structure definitions illustrate the MIT keytab
21 file format. All values are in network byte order. All text is ASCII.
22 keytab {
24 uint16_t file_format_version; # 0x502
25 keytab_entry entries[*];
26 };
27 keytab_entry {
29 int32_t size;
30 uint16_t num_components; # subtract 1 if version 0x501
31 counted_octet_string realm;
32 counted_octet_string components[num_components];
33 uint32_t name_type; # not present if version 0x501
34 uint32_t timestamp;
35 uint8_t vno8;
36 keyblock key;
37 uint32_t vno; #only present if >= 4 bytes left in entry
38 uint32_t flags; #only present if >= 4 bytes left in entry
39 };
40 counted_octet_string {
42 uint16_t length;
43 uint8_t data[length];
44 };
45 keyblock {
47 uint16_t type;
48 counted_octet_string;
49 };
50 All numbers are stored in network byteorder (big endian) format.
52 The keytab file format begins with the 16 bit file_format_version which
54 at the time this document was authored is 0x502. The format of older
55 keytabs is described at the end of this document.
56 The file_format_version is immediately followed by an array of
58 keytab_entry structures which are prefixed with a 32 bit size
59 indicating the number of bytes that follow in the entry. Note that the
60 size should be evaluated as signed. This is because a negative value
61 indicates that the entry is in fact empty (e.g. it has been deleted)
62 and that the negative value of that negative value (which is of course
63 a positive value) is the offset to the next keytab_entry. Based on
64 these size values alone the entire keytab file can be traversed.
65 The size is followed by a 16 bit num_components field indicating the
67 number of counted_octet_string components in the components array.
68 The num_components field is followed by a counted_octet_string
70 representing the realm of the principal.
71 A counted_octet_string is simply an array of bytes prefixed with a 16
73 bit length. For the realm and name components, the counted_octet_string
74 bytes are ASCII encoded text with no zero terminator.
75 Following the realm is the components array that represents the name of
77 the principal. The text of these components may be joined with slashs
78 to construct the typical SPN representation. For example, the service
79 principal HTTP/www.foo.net@FOO.NET would consist of name components
80 'HTTP' followed by 'www.foo.net'.
81 Following the components array is the 32 bit name_type (e.g. 1 is
83 KRB5_NT_PRINCIPAL, 2 is KRB5_NT_SRV_INST, 5 is KRB5_NT_UID, etc). In
84 practice the name_type is almost certainly 1 meaning KRB5_NT_PRINCIPAL.
85 The 32 bit timestamp indicates the time the key was established for
87 that principal. The value represents the number of seconds since Jan 1,
88 1970.
89 The 8 bit vno8 field is the version number of the key. This value is
91 overridden by the 32 bit vno field if it is present. The vno8 field is
92 filled with the lower 8 bits of the 32 bit protocol kvno field.
93 The keyblock structure consists of a 16 bit value indicating the
95 encryption type and is a counted_octet_string containing the key. The
96 encryption type is the same as the Kerberos standard (e.g. 3 is des-
97 cbc-md5, 23 is arcfour-hmac-md5, etc).
98 The last field of the keytab_entry structure is optional. If the size
100 of the keytab_entry indicates that there are at least 4 bytes
101 remaining, a 32 bit value representing the key version number is
102 present. This value supersedes the 8 bit vno8 value preceeding the
103 keyblock.
104 Older keytabs with a file_format_version of 0x501 are different in
106 three ways:
107 · All integers are in host byte order [1].
109 · The num_components field is 1 too large (i.e. after decoding,
111 decrement by 1).
112 · The 32 bit name_type field is not present.
114 [1] The file_format_version field should really be treated as two
116 separate 8 bit quantities representing the major and minor version
117 number respectively.
118 Heimdal database dump file
120 Format of the Heimdal text dump file as of Heimdal 0.6.3:
121 Each line in the dump file is one entry in the database.
123 Each field of a line is separated by one or more spaces, with the
125 exception of fields consisting of principals containing spaces, where
126 space can be quoted with \ and \ is quoted by .
127 Fields and their types are:
129 Quoted princial (quote character is [string]
131 Keys [keys]
132 Created by [event]
133 Modified by [event optional]
134 Valid start time [time optional]
135 Valid end time [time optional]
136 Password end valid time [time optional]
137 Max lifetime of ticket [time optional]
138 Max renew time of ticket [integer optional]
139 Flags [hdb flags]
140 Generation number [generation optional]
141 Extensions [extentions optional]
142 Fields following these silently are ignored.
144 All optional fields will be skipped if they fail to parse (or comprise
146 the optional field marker of '-', w/o quotes).
147 Example:
149 fred@CODE.COM 27:1:16:e8b4c8fc7e60b9e641dcf4cff3f08a701d982a2f89ba373733d26ca59ba6c789666f6b8bfcf169412bb1e5dceb9b33cda29f3412:-:1:3:4498a933881178c744f4232172dcd774c64e81fa6d05ecdf643a7e390624a0ebf3c7407a:-:1:2:b01934b13eb795d76f3a80717d469639b4da0cfb644161340ef44fdeb375e54d684dbb85:-:1:1:ea8e16d8078bf60c781da90f508d4deccba70595258b9d31888d33987cd31af0c9cced2e:- 20020415130120:admin@CODE.COM 20041221112428:fred@CODE.COM - - - 86400 604800 126 20020415130120:793707:28 -
151 Encoding of types are as follows:
153 · keys
155 kvno:[masterkvno:keytype:keydata:salt]{zero or more separated by :}
157 kvno is the key version number.
159 keydata is hex-encoded
161 masterkvno is the kvno of the database master key. If this field is
163 empty, the kadmin load and merge operations will encrypt the key data
164 with the master key if there is one. Otherwise the key data will be
165 imported asis.
166 salt is encoded as '-' (no/default salt) or
168 salt-type /
170 salt-type / "string"
171 salt-type / hex-encoded-data
172 keytype is the protocol enctype number; see enum ENCTYPE in
174 include/krb5_asn1.h for values.
175 Example:
177 27:1:16:e8b4c8fc7e60b9e641dcf4cff3f08a701d982a2f89ba373733d26ca59ba6c789666f6b8bfcf169412bb1e5dceb9b33cda29f3412:-:1:3:4498a933881178c744f4232172dcd774c64e81fa6d05ecdf643a7e390624a0ebf3c7407a:-:1:2:b01934b13eb795d76f3a80717d469639b4da0cfb644161340ef44fdeb375e54d684dbb85:-:1:1:ea8e16d8078bf60c781da90f508d4deccba70595258b9d31888d33987cd31af0c9cced2e:-
179 kvno=27,{key: masterkvno=1,keytype=des3-cbc-sha1,keydata=..., default salt}...
182 · time
184 Format of the time is: YYYYmmddHHMMSS, corresponding to strftime format
186 '%Y%m%d%k%M%S'.
187 Time is expressed in UTC.
189 Time can be optional (using -), when the time 0 is used.
191 Example:
193 20041221112428
195 · event
197 time:principal
199 time is as given in format time
201 principal is a string. Not quoting it may not work in earlier versions
203 of Heimdal.
204 Example:
206 20041221112428:bloggs@CODE.COM
208 · hdb flags
211 Integer encoding of HDB flags, see HDBFlags in lib/hdb/hdb.asn1. Each
213 bit in the integer is the same as the bit in the specification.
214 · generation:
216 time:usec:gen
218 usec is a the microsecond, integer. gen is generation number, integer.
220 The generation can be defaulted (using '-') or the empty string
222 · extensions:
224 first-hex-encoded-HDB-Extension[:second-...]
226 HDB-extension is encoded the DER encoded HDB-Extension from
228 lib/hdb/hdb.asn1. Consumers HDB extensions should be aware that unknown
229 entires needs to be preserved even thought the ASN.1 data content might
230 be unknown. There is a critical flag in the data to show to the KDC
231 that the entry MUST be understod if the entry is to be used.
232Version 7.7.0 Fri Jun 7 2019 krb5_fileformats(3)