keytab.txt

   1 The Kerberos Keytab Binary File Format
   2 Copyright (C) 2006 Michael B Allen <mba2000 ioplex.com>
   3 http://www.ioplex.com/utilities/keytab.txt
   4 Last updated: Fri May  5 13:39:40 EDT 2006
   5
   6 The MIT keytab binary format is not a standard format, nor is it
   7 documented anywhere in detail. The format has evolved and may continue
   8 to. It is however understood by several Kerberos implementations including
   9 Heimdal and of course MIT and keytab files are created by the ktpass.exe
  10 utility from Windows. So it has established itself as the defacto format
  11 for storing Kerberos keys.
  12
  13 The following C-like structure definitions illustrate the MIT keytab
  14 file format. All values are in network byte order. All text is ASCII.
  15
  16   keytab {
  17       uint16_t file_format_version;                    /* 0x502 */
  18       keytab_entry entries[*];
  19   };
  20
  21   keytab_entry {
  22       int32_t size;
  23       uint16_t num_components;    /* sub 1 if version 0x501 */
  24       counted_octet_string realm;
  25       counted_octet_string components[num_components];
  26       uint32_t name_type;   /* not present if version 0x501 */
  27       uint32_t timestamp;
  28       uint8_t vno8;
  29       keyblock key;
  30       uint32_t vno; /* only present if >= 4 bytes left in entry */
  31   };
  32
  33   counted_octet_string {
  34       uint16_t length;
  35       uint8_t data[length];
  36   };
  37
  38   keyblock {
  39       uint16_t type;
  40       counted_octet_string;
  41   };
  42
  43 The keytab file format begins with the 16 bit file_format_version which
  44 at the time this document was authored is 0x502. The format of older
  45 keytabs is described at the end of this document.
  46
  47 The file_format_version is immediately followed by an array of
  48 keytab_entry structures which are prefixed with a 32 bit size indicating
  49 the number of bytes that follow in the entry. Note that the size should be
  50 evaluated as signed. This is because a negative value indicates that the
  51 entry is in fact empty (e.g. it has been deleted) and that the negative
  52 value of that negative value (which is of course a positive value) is
  53 the offset to the next keytab_entry. Based on these size values alone
  54 the entire keytab file can be traversed.
  55
  56 The size is followed by a 16 bit num_components field indicating the
  57 number of counted_octet_string components in the components array.
  58
  59 The num_components field is followed by a counted_octet_string
  60 representing the realm of the principal.
  61
  62 A counted_octet_string is simply an array of bytes prefixed with a 16
  63 bit length. For the realm and name components, the counted_octet_string
  64 bytes are ASCII encoded text with no zero terminator.
  65
  66 Following the realm is the components array that represents the name of
  67 the principal. The text of these components may be joined with slashs
  68 to construct the typical SPN representation. For example, the service
  69 principal HTTP/www.foo.net@FOO.NET would consist of name components
  70 "HTTP" followed by "www.foo.net".
  71
  72 Following the components array is the 32 bit name_type (e.g. 1 is
  73 KRB5_NT_PRINCIPAL, 2 is KRB5_NT_SRV_INST, 5 is KRB5_NT_UID, etc). In
  74 practice the name_type is almost certainly 1 meaning KRB5_NT_PRINCIPAL.
  75
  76 The 32 bit timestamp indicates the time the key was established for that
  77 principal. The value represents the number of seconds since Jan 1, 1970.
  78
  79 The 8 bit vno8 field is the version number of the key. This value is
  80 overridden by the 32 bit vno field if it is present.
  81
  82 The keyblock structure consists of a 16 bit value indicating the keytype
  83 (e.g. 3 is des-cbc-md5, 23 is arcfour-hmac-md5, 16 is des3-cbc-sha1,
  84 etc). This is followed by a counted_octet_string containing the key.
  85
  86 The last field of the keytab_entry structure is optional. If the size of
  87 the keytab_entry indicates that there are at least 4 bytes remaining,
  88 a 32 bit value representing the key version number is present. This
  89 value supersedes the 8 bit vno8 value preceeding the keyblock.
  90
  91 Older keytabs with a file_format_version of 0x501 are different in
  92 three ways:
  93
  94   1) All integers are in host byte order [1].
  95   2) The num_components field is 1 too large (i.e. after decoding,
  96      decrement by 1).
  97   3) The 32 bit name_type field is not present.
  98
  99 [1] The file_format_version field should really be treated as two
 100     separate 8 bit quantities representing the major and minor version
 101     number respectively.
 102
 103 Permission to copy, modify, and distribute this document, with or
 104 without modification, for any purpose and without fee or royalty is
 105 hereby granted, provided that you include this copyright notice in ALL
 106 copies of the document or portions thereof, including modifications.