The following sections specify the encryption and checksum mechanisms
currently defined for Kerberos. The encodings, chaining, and padding
requirements for each are described. For encryption methods, it is
often desirable to place random information (often referred to as a
confounder) at the start of the message. The requirements for a
confounder are specified with each encryption mechanism.
Some encryption systems use a block-chaining method to improve the
the security characteristics of the ciphertext. However, these
chaining methods often don't provide an integrity check upon
decryption. Such systems (such as DES in CBC mode) must be augmented
with a checksum of the plaintext which can be verified at decryption
and used to detect any tampering or damage. Such checksums should be
good at detecting burst errors in the input. If any damage is
detected, the decryption routine is expected to return an error
indicating the failure of an integrity check. Each encryption type is
expected to provide and verify an appropriate checksum. The
specification of each encryption method sets out its checksum
requirements.
Finally, where a key is to be derived from a user's password, an
algorithm for converting the password to a key of the appropriate
type is included. It is desirable for the string to key function to
be one-way, and for the mapping to be different in different realms.
This is important because users who are registered in more than one
realm will often use the same password in each, and it is desirable
that an attacker compromising the Kerberos server in one realm not
obtain or derive the user's key in another.
For a discussion of the integrity characteristics of the candidate
encryption and checksum methods considered for Kerberos, the the
reader is referred to [13].
6.1. Encryption Specifications
The following ASN.1 definition describes all encrypted messages. The
enc-part field which appears in the unencrypted part of messages in
section 5 is a sequence consisting of an encryption type, an optional
key version number, and the ciphertext.
EncryptedData ::= SEQUENCE {
etype[0] INTEGER, -- EncryptionType
kvno[1] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
}
etype This field identifies which encryption algorithm was used
to encipher the cipher. Detailed specifications for
selected encryption types appear later in this section.
kvno This field contains the version number of the key under
which data is encrypted. It is only present in messages
encrypted under long lasting keys, such as principals'
secret keys.
cipher This field contains the enciphered text, encoded as an
OCTET STRING.
The cipher field is generated by applying the specified encryption
algorithm to data composed of the message and algorithm-specific
inputs. Encryption mechanisms defined for use with Kerberos must
take sufficient measures to guarantee the integrity of the plaintext,
and we recommend they also take measures to protect against
precomputed dictionary attacks. If the encryption algorithm is not
itself capable of doing so, the protections can often be enhanced by
adding a checksum and a confounder.
The suggested format for the data to be encrypted includes a
confounder, a checksum, the encoded plaintext, and any necessary
padding. The msg-seq field contains the part of the protocol message
described in section 5 which is to be encrypted. The confounder,
checksum, and padding are all untagged and untyped, and their length
is exactly sufficient to hold the appropriate item. The type and
length is implicit and specified by the particular encryption type
being used (etype). The format for the data to be encrypted is
described in the following diagram:
+-----------+----------+-------------+-----+
|confounder | check | msg-seq | pad |
+-----------+----------+-------------+-----+
The format cannot be described in ASN.1, but for those who prefer an
ASN.1-like notation:
CipherText ::= ENCRYPTED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL,
check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
msg-seq[2] MsgSequence,
pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
}
In the above specification, UNTAGGED OCTET STRING(length) is the
notation for an octet string with its tag and length removed. It is
not a valid ASN.1 type. The tag bits and length must be removed from
the confounder since the purpose of the confounder is so that the
message starts with random data, but the tag and its length are
fixed. For other fields, the length and tag would be redundant if
they were included because they are specified by the encryption type.
One generates a random confounder of the appropriate length, placing
it in confounder; zeroes out check; calculates the appropriate
checksum over confounder, check, and msg-seq, placing the result in
check; adds the necessary padding; then encrypts using the specified
encryption type and the appropriate key.
Unless otherwise specified, a definition of an encryption algorithm
that specifies a checksum, a length for the confounder field, or an
octet boundary for padding uses this ciphertext format (The ordering
of the fields in the CipherText is important. Additionally, messages
encoded in this format must include a length as part of the msg-seq
field. This allows the recipient to verify that the message has not
been truncated. Without a length, an attacker could use a chosen
plaintext attack to generate a message which could be truncated,
while leaving the checksum intact. Note that if the msg-seq is an
encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is
part of that encoding.). Those fields which are not specified will be
omitted.
In the interest of allowing all implementations using a particular
encryption type to communicate with all others using that type, the
specification of an encryption type defines any checksum that is
needed as part of the encryption process. If an alternative checksum
is to be used, a new encryption type must be defined.
Some cryptosystems require additional information beyond the key and
the data to be encrypted. For example, DES, when used in cipher-
block-chaining mode, requires an initialization vector. If required,
the description for each encryption type must specify the source of
such additional information.
6.2. Encryption Keys
The sequence below shows the encoding of an encryption key:
EncryptionKey ::= SEQUENCE {
keytype[0] INTEGER,
keyvalue[1] OCTET STRING
}
keytype This field specifies the type of encryption key that
follows in the keyvalue field. It will almost always
correspond to the encryption algorithm used to generate the
EncryptedData, though more than one algorithm may use the
same type of key (the mapping is many to one). This might
happen, for example, if the encryption algorithm uses an
alternate checksum algorithm for an integrity check, or a
different chaining mechanism.
keyvalue This field contains the key itself, encoded as an octet
string.
All negative values for the encryption key type are reserved for
local use. All non-negative values are reserved for officially
assigned type fields and interpretations.
6.3. Encryption Systems
6.3.1. The NULL Encryption System (null)
If no encryption is in use, the encryption system is said to be the
NULL encryption system. In the NULL encryption system there is no
checksum, confounder or padding. The ciphertext is simply the
plaintext. The NULL Key is used by the null encryption system and is
zero octets in length, with keytype zero (0).
6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
The des-cbc-crc encryption mode encrypts information under the Data
Encryption Standard [11] using the cipher block chaining mode [12].
A CRC-32 checksum (described in ISO 3309 [14]) is applied to the
confounder and message sequence (msg-seq) and placed in the cksum
field. DES blocks are 8 bytes. As a result, the data to be
encrypted (the concatenation of confounder, checksum, and message)
must be padded to an 8 byte boundary before encryption. The details
of the encryption of this data are identical to those for the des-
cbc-md5 encryption mode.
Note that, since the CRC-32 checksum is not collisionproof, an
attacker could use a probabilistic chosenplaintext attack to generate
a valid message even if a confounder is used [13]. The use of
collision-proof checksums is recommended for environments where such
attacks represent a significant threat. The use of the CRC-32 as the
checksum for ticket or authenticator is no longer mandated as an
interoperability requirement for Kerberos Version 5 Specification 1
(See section 9.1 for specific details).
6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
The des-cbc-md4 encryption mode encrypts information under the Data
Encryption Standard [11] using the cipher block chaining mode [12].
An MD4 checksum (described in [15]) is applied to the confounder and
message sequence (msg-seq) and placed in the cksum field. DES blocks
are 8 bytes. As a result, the data to be encrypted (the
concatenation of confounder, checksum, and message) must be padded to
an 8 byte boundary before encryption. The details of the encryption
of this data are identical to those for the descbc-md5 encryption
mode.
6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
The des-cbc-md5 encryption mode encrypts information under the Data
Encryption Standard [11] using the cipher block chaining mode [12].
An MD5 checksum (described in [16]) is applied to the confounder and
message sequence (msg-seq) and placed in the cksum field. DES blocks
are 8 bytes. As a result, the data to be encrypted (the
concatenation of confounder, checksum, and message) must be padded to
an 8 byte boundary before encryption.
Plaintext and DES ciphtertext are encoded as 8-octet blocks which are
concatenated to make the 64-bit inputs for the DES algorithms. The
first octet supplies the 8 most significant bits (with the octet's
MSbit used as the DES input block's MSbit, etc.), the second octet
the next 8 bits, ..., and the eighth octet supplies the 8 least
significant bits.
Encryption under DES using cipher block chaining requires an
additional input in the form of an initialization vector. Unless
otherwise specified, zero should be used as the initialization
vector. Kerberos' use of DES requires an 8-octet confounder.
The DES specifications identify some "weak" and "semiweak" keys;
those keys shall not be used for encrypting messages for use in
Kerberos. Additionally, because of the way that keys are derived for
the encryption of checksums, keys shall not be used that yield "weak"
or "semi-weak" keys when eXclusive-ORed with the constant
F0F0F0F0F0F0F0F0.
A DES key is 8 octets of data, with keytype one (1). This consists
of 56 bits of key, and 8 parity bits (one per octet). The key is
encoded as a series of 8 octets written in MSB-first order. The bits
within the key are also encoded in MSB order. For example, if the
encryption key is:
(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
parity bits, the first octet of the key would be B1,B2,...,B7,P1
(with B1 as the MSbit). [See the FIPS 81 introduction for
reference.]
To generate a DES key from a text string (password), the text string
normally must have the realm and each component of the principal's
name appended(In some cases, it may be necessary to use a different
"mix-in" string for compatibility reasons; see the discussion of
padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte
boundary. This string is then fan-folded and eXclusive-ORed with
itself to form an 8 byte DES key. The parity is corrected on the
key, and it is used to generate a DES CBC checksum on the initial
string (with the realm and name appended). Next, parity is corrected
on the CBC checksum. If the result matches a "weak" or "semiweak"
key as described in the DES specification, it is eXclusive-ORed with
the constant 00000000000000F0. Finally, the result is returned as
the key. Pseudocode follows:
string_to_key(string,realm,name) {
odd = 1;
s = string + realm;
for(each component in name) {
s = s + component;
}
tempkey = NULL;
pad(s); /* with nulls to 8 byte boundary */
for(8byteblock in s) {
if(odd == 0) {
odd = 1;
reverse(8byteblock)
}
else odd = 0;
tempkey = tempkey XOR 8byteblock;
}
fixparity(tempkey);
key = DES-CBC-check(s,tempkey);
fixparity(key);
if(is_weak_key_key(key))
key = key XOR 0xF0;
return(key);
}
6.4. Checksums
The following is the ASN.1 definition used for a checksum:
Checksum ::= SEQUENCE {
cksumtype[0] INTEGER,
checksum[1] OCTET STRING
}
cksumtype This field indicates the algorithm used to generate the
accompanying checksum.
checksum This field contains the checksum itself, encoded
as an octet string.
Detailed specification of selected checksum types appear later in
this section. Negative values for the checksum type are reserved for
local use. All non-negative values are reserved for officially
assigned type fields and interpretations.
Checksums used by Kerberos can be classified by two properties:
whether they are collision-proof, and whether they are keyed. It is
infeasible to find two plaintexts which generate the same checksum
value for a collision-proof checksum. A key is required to perturb
or initialize the algorithm in a keyed checksum. To prevent
message-stream modification by an active attacker, unkeyed checksums
should only be used when the checksum and message will be
subsequently encrypted (e.g., the checksums defined as part of the
encryption algorithms covered earlier in this section). Collision-
proof checksums can be made tamper-proof as well if the checksum
value is encrypted before inclusion in a message. In such cases, the
composition of the checksum and the encryption algorithm must be
considered a separate checksum algorithm (e.g., RSA-MD5 encrypted
using DES is a new checksum algorithm of type RSA-MD5-DES). For most
keyed checksums, as well as for the encrypted forms of collisionproof
checksums, Kerberos prepends a confounder before the checksum is
calculated.
6.4.1. The CRC-32 Checksum (crc32)
The CRC-32 checksum calculates a checksum based on a cyclic
redundancy check as described in ISO 3309 [14]. The resulting
checksum is four (4) octets in length. The CRC-32 is neither keyed
nor collision-proof. The use of this checksum is not recommended.
An attacker using a probabilistic chosen-plaintext attack as
described in [13] might be able to generate an alternative message
that satisfies the checksum. The use of collision-proof checksums is
recommended for environments where such attacks represent a
significant threat.
6.4.2. The RSA MD4 Checksum (rsa-md4)
The RSA-MD4 checksum calculates a checksum using the RSA MD4
algorithm [15]. The algorithm takes as input an input message of
arbitrary length and produces as output a 128-bit (16 octet)
checksum. RSA-MD4 is believed to be collision-proof.
6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4des)
The RSA-MD4-DES checksum calculates a keyed collisionproof checksum
by prepending an 8 octet confounder before the text, applying the RSA
MD4 checksum algorithm, and encrypting the confounder and the
checksum using DES in cipher-block-chaining (CBC) mode using a
variant of the key, where the variant is computed by eXclusive-ORing
the key with the constant F0F0F0F0F0F0F0F0 (A variant of the key is
used to limit the use of a key to a particular function, separating
the functions of generating a checksum from other encryption
performed using the session key. The constant F0F0F0F0F0F0F0F0 was
chosen because it maintains key parity. The properties of DES
precluded the use of the complement. The same constant is used for
similar purpose in the Message Integrity Check in the Privacy
Enhanced Mail standard.). The initialization vector should be zero.
The resulting checksum is 24 octets long (8 octets of which are
redundant). This checksum is tamper-proof and believed to be
collision-proof.
The DES specifications identify some "weak keys"; those keys shall
not be used for generating RSA-MD4 checksums for use in Kerberos.
The format for the checksum is described in the following diagram:
+--+--+--+--+--+--+--+--
| des-cbc(confounder
+--+--+--+--+--+--+--+--
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
rsa-md4(confounder+msg),key=var(key),iv=0) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The format cannot be described in ASN.1, but for those who prefer an
ASN.1-like notation:
rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(8),
check[1] UNTAGGED OCTET STRING(16)
}
6.4.4. The RSA MD5 Checksum (rsa-md5)
The RSA-MD5 checksum calculates a checksum using the RSA MD5
algorithm [16]. The algorithm takes as input an input message of
arbitrary length and produces as output a 128-bit (16 octet)
checksum. RSA-MD5 is believed to be collision-proof.
6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)
The RSA-MD5-DES checksum calculates a keyed collisionproof checksum
by prepending an 8 octet confounder before the text, applying the RSA
MD5 checksum algorithm, and encrypting the confounder and the
checksum using DES in cipher-block-chaining (CBC) mode using a
variant of the key, where the variant is computed by eXclusive-ORing
the key with the constant F0F0F0F0F0F0F0F0. The initialization
vector should be zero. The resulting checksum is 24 octets long (8
octets of which are redundant). This checksum is tamper-proof and
believed to be collision-proof.
The DES specifications identify some "weak keys"; those keys shall
not be used for encrypting RSA-MD5 checksums for use in Kerberos.
The format for the checksum is described in the following diagram:
+--+--+--+--+--+--+--+--
| des-cbc(confounder
+--+--+--+--+--+--+--+--
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
rsa-md5(confounder+msg),key=var(key),iv=0) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The format cannot be described in ASN.1, but for those who prefer an
ASN.1-like notation:
rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(8),
check[1] UNTAGGED OCTET STRING(16)
}
6.4.6. DES cipher-block chained checksum (des-mac)
The DES-MAC checksum is computed by prepending an 8 octet confounder
to the plaintext, performing a DES CBC-mode encryption on the result
using the key and an initialization vector of zero, taking the last
block of the ciphertext, prepending the same confounder and
encrypting the pair using DES in cipher-block-chaining (CBC) mode
using a a variant of the key, where the variant is computed by
eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0. The
initialization vector should be zero. The resulting checksum is 128
bits (16 octets) long, 64 bits of which are redundant. This checksum
is tamper-proof and collision-proof.
The format for the checksum is described in the following diagram:
+--+--+--+--+--+--+--+--
| des-cbc(confounder
+--+--+--+--+--+--+--+--
+-----+-----+-----+-----+-----+-----+-----+-----+
des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
+-----+-----+-----+-----+-----+-----+-----+-----+
The format cannot be described in ASN.1, but for those who prefer an
ASN.1-like notation:
des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(8),
check[1] UNTAGGED OCTET STRING(8)
}
The DES specifications identify some "weak" and "semiweak" keys;
those keys shall not be used for generating DES-MAC checksums for use
in Kerberos, nor shall a key be used whose veriant is "weak" or
"semi-weak".
6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
(rsa-md4-des-k)
The RSA-MD4-DES-K checksum calculates a keyed collision-proof
checksum by applying the RSA MD4 checksum algorithm and encrypting
the results using DES in cipherblock-chaining (CBC) mode using a DES
key as both key and initialization vector. The resulting checksum is
16 octets long. This checksum is tamper-proof and believed to be
collision-proof. Note that this checksum type is the old method for
encoding the RSA-MD4-DES checksum and it is no longer recommended.
6.4.8. DES cipher-block chained checksum alternative (desmac-k)
The DES-MAC-K checksum is computed by performing a DES CBC-mode
encryption of the plaintext, and using the last block of the
ciphertext as the checksum value. It is keyed with an encryption key
and an initialization vector; any uses which do not specify an
additional initialization vector will use the key as both key and
initialization vector. The resulting checksum is 64 bits (8 octets)
long. This checksum is tamper-proof and collision-proof. Note that
this checksum type is the old method for encoding the DESMAC checksum
and it is no longer recommended.
The DES specifications identify some "weak keys"; those keys shall
not be used for generating DES-MAC checksums for use in Kerberos.
7. Naming Constraints
7.1. Realm Names
Although realm names are encoded as GeneralStrings and although a
realm can technically select any name it chooses, interoperability
across realm boundaries requires agreement on how realm names are to
be assigned, and what information they imply.
To enforce these conventions, each realm must conform to the
conventions itself, and it must require that any realms with which
inter-realm keys are shared also conform to the conventions and
require the same from its neighbors.
There are presently four styles of realm names: domain, X500, other,
and reserved. Examples of each style follow:
domain: host.subdomain.domain (example)
X500: C=US/O=OSF (example)
other: NAMETYPE:rest/of.name=without-restrictions (example)
reserved: reserved, but will not conflict with above
Domain names must look like domain names: they consist of components
separated by periods (.) and they contain neither colons (:) nor
slashes (/).
X.500 names contain an equal (=) and cannot contain a colon (:)
before the equal. The realm names for X.500 names will be string
representations of the names with components separated by slashes.
Leading and trailing slashes will not be included.
Names that fall into the other category must begin with a prefix that
contains no equal (=) or period (.) and the prefix must be followed
by a colon (:) and the rest of the name. All prefixes must be
assigned before they may be used. Presently none are assigned.
The reserved category includes strings which do not fall into the
first three categories. All names in this category are reserved. It
is unlikely that names will be assigned to this category unless there
is a very strong argument for not using the "other" category.
These rules guarantee that there will be no conflicts between the
various name styles. The following additional constraints apply to
the assignment of realm names in the domain and X.500 categories: the
name of a realm for the domain or X.500 formats must either be used
by the organization owning (to whom it was assigned) an Internet
domain name or X.500 name, or in the case that no such names are
registered, authority to use a realm name may be derived from the
authority of the parent realm. For example, if there is no domain
name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
authorize the creation of a realm with that name.
This is acceptable because the organization to which the parent is
assigned is presumably the organization authorized to assign names to
its children in the X.500 and domain name systems as well. If the
parent assigns a realm name without also registering it in the domain
name or X.500 hierarchy, it is the parent's responsibility to make
sure that there will not in the future exists a name identical to the
realm name of the child unless it is assigned to the same entity as
the realm name.
7.2. Principal Names
As was the case for realm names, conventions are needed to ensure
that all agree on what information is implied by a principal name.
The name-type field that is part of the principal name indicates the
kind of information implied by the name. The name-type should be
treated as a hint. Ignoring the name type, no two names can be the
same (i.e., at least one of the components, or the realm, must be
different). This constraint may be eliminated in the future. The
following name types are defined:
name-type value meaning
NT-UNKNOWN 0 Name type not known
NT-PRINCIPAL 1 Just the name of the principal as in
DCE, or for users
NT-SRV-INST 2 Service and other unique instance (krbtgt)
NT-SRV-HST 3 Service with host name as instance
(telnet, rcommands)
NT-SRV-XHST 4 Service with host as remaining components
NT-UID 5 Unique ID
When a name implies no information other than its uniqueness at a
particular time the name type PRINCIPAL should be used. The
principal name type should be used for users, and it might also be
used for a unique server. If the name is a unique machine generated
ID that is guaranteed never to be reassigned then the name type of
UID should be used (note that it is generally a bad idea to reassign
names of any type since stale entries might remain in access control
lists).
If the first component of a name identifies a service and the
remaining components identify an instance of the service in a server
specified manner, then the name type of SRV-INST should be used. An
example of this name type is the Kerberos ticket-granting ticket
which has a first component of krbtgt and a second component
identifying the realm for which the ticket is valid.
If instance is a single component following the service name and the
instance identifies the host on which the server is running, then the
name type SRV-HST should be used. This type is typically used for
Internet services such as telnet and the Berkeley R commands. If the
separate components of the host name appear as successive components
following the name of the service, then the name type SRVXHST should
be used. This type might be used to identify servers on hosts with
X.500 names where the slash (/) might otherwise be ambiguous.
A name type of UNKNOWN should be used when the form of the name is
not known. When comparing names, a name of type UNKNOWN will match
principals authenticated with names of any type. A principal
authenticated with a name of type UNKNOWN, however, will only match
other names of type UNKNOWN.
Names of any type with an initial component of "krbtgt" are reserved
for the Kerberos ticket granting service. See section 8.2.3 for the
form of such names.
7.2.1. Name of server principals
The principal identifier for a server on a host will generally be
composed of two parts: (1) the realm of the KDC with which the server
is registered, and (2) a two-component name of type NT-SRV-HST if the
host name is an Internet domain name or a multi-component name of
type NT-SRV-XHST if the name of the host is of a form such as X.500
that allows slash (/) separators. The first component of the two- or
multi-component name will identify the service and the latter
components will identify the host. Where the name of the host is not
case sensitive (for example, with Internet domain names) the name of
the host must be lower case. For services such as telnet and the
Berkeley R commands which run with system privileges, the first
component will be the string "host" instead of a service specific
identifier.
8. Constants and other defined values
8.1. Host address types
All negative values for the host address type are reserved for local
use. All non-negative values are reserved for officially assigned
type fields and interpretations.
The values of the types for the following addresses are chosen to
match the defined address family constants in the Berkeley Standard
Distributions of Unix. They can be found in <sys/socket.h> with
symbolic names AF_xxx (where xxx is an abbreviation of the address
family name).
Internet addresses
Internet addresses are 32-bit (4-octet) quantities, encoded in MSB
order. The type of internet addresses is two (2).
CHAOSnet addresses
CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
order. The type of CHAOSnet addresses is five (5).
ISO addresses
ISO addresses are variable-length. The type of ISO addresses is
seven (7).
Xerox Network Services (XNS) addresses
XNS addresses are 48-bit (6-octet) quantities, encoded in MSB
order. The type of XNS addresses is six (6).
AppleTalk Datagram Delivery Protocol (DDP) addresses
AppleTalk DDP addresses consist of an 8-bit node number and a 16-
bit network number. The first octet of the address is the node
number; the remaining two octets encode the network number in MSB
order. The type of AppleTalk DDP addresses is sixteen (16).
DECnet Phase IV addresses
DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
order. The type of DECnet Phase IV addresses is twelve (12).
8.2. KDC messages
8.2.1. IP transport
When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
using IP transport, the client shall send a UDP datagram containing
only an encoding of the request to port 88 (decimal) at the KDC's IP
address; the KDC will respond with a reply datagram containing only
an encoding of the reply message (either a KRB_ERROR or a
KRB_KDC_REP) to the sending port at the sender's IP address.
8.2.2. OSI transport
During authentication of an OSI client to and OSI server, the mutual
authentication of an OSI server to an OSI client, the transfer of
credentials from an OSI client to an OSI server, or during exchange
of private or integrity checked messages, Kerberos protocol messages
may be treated as opaque objects and the type of the authentication
mechanism will be:
OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1),
security(5), kerberosv5(2)}
Depending on the situation, the opaque object will be an
authentication header (KRB_AP_REQ), an authentication reply
(KRB_AP_REP), a safe message (KRB_SAFE), a private message
(KRB_PRIV), or a credentials message (KRB_CRED). The opaque data
contains an application code as specified in the ASN.1 description
for each message. The application code may be used by Kerberos to
determine the message type.
8.2.3. Name of the TGS
The principal identifier of the ticket-granting service shall be
composed of three parts: (1) the realm of the KDC issuing the TGS
ticket (2) a two-part name of type NT-SRVINST, with the first part
"krbtgt" and the second part the name of the realm which will accept
the ticket-granting ticket. For example, a ticket-granting ticket
issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "MIT.EDU") (name).
8.3. Protocol constants and associated values
The following tables list constants used in the protocol and defines
their meanings.
---------------+-----------+----------+----------------+---------------
Encryption type|etype value|block size|minimum pad size|confounder size
---------------+-----------+----------+----------------+---------------
NULL 0 1 0 0
des-cbc-crc 1 8 4 8
des-cbc-md4 2 8 0 8
des-cbc-md5 3 8 0 8
-------------------------------+-------------------+-------------
Checksum type |sumtype value |checksum size
-------------------------------+-------------------+-------------
CRC32 1 4
rsa-md4 2 16
rsa-md4-des 3 24
des-mac 4 16
des-mac-k 5 8
rsa-md4-des-k 6 16
rsa-md5 7 16
rsa-md5-des 8 24
-------------------------------+-----------------
padata type |padata-type value
-------------------------------+-----------------
PA-TGS-REQ 1
PA-ENC-TIMESTAMP 2
PA-PW-SALT 3
-------------------------------+-------------
authorization data type |ad-type value
-------------------------------+-------------
reserved values 0-63
OSF-DCE 64
SESAME 65
-------------------------------+-----------------
alternate authentication type |method-type value
-------------------------------+-----------------
reserved values 0-63
ATT-CHALLENGE-RESPONSE 64
-------------------------------+-------------
transited encoding type |tr-type value
-------------------------------+-------------
DOMAIN-X500-COMPRESS 1
reserved values all others
--------------+-------+-----------------------------------------
Label |Value |Meaning or MIT code
--------------+-------+-----------------------------------------
pvno 5 current Kerberos protocol version number
message types
KRB_AS_REQ 10 Request for initial authentication
KRB_AS_REP 11 Response to KRB_AS_REQ request
KRB_TGS_REQ 12 Request for authentication based on TGT
KRB_TGS_REP 13 Response to KRB_TGS_REQ request
KRB_AP_REQ 14 application request to server
KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
KRB_SAFE 20 Safe (checksummed) application message
KRB_PRIV 21 Private (encrypted) application message
KRB_CRED 22 Private (encrypted) message to forward
credentials
KRB_ERROR 30 Error response
name types
KRB_NT_UNKNOWN 0 Name type not known
KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or
for users
KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
KRB_NT_SRV_HST 3 Service with host name as instance (telnet,
rcommands)
KRB_NT_SRV_XHST 4 Service with host as remaining components
KRB_NT_UID 5 Unique ID
error codes
KDC_ERR_NONE 0 No error
KDC_ERR_NAME_EXP 1 Client's entry in database has
expired
KDC_ERR_SERVICE_EXP 2 Server's entry in database has
expired
KDC_ERR_BAD_PVNO 3 Requested protocol version number
not supported
KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old
master key
KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old
master key
KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in
database
KDC_ERR_NULL_KEY 9 The client or server has a null key
KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
KDC_ERR_NEVER_VALID 11 Requested start time is later than
end time
KDC_ERR_POLICY 12 KDC policy rejects request
KDC_ERR_BADOPTION 13 KDC cannot accommodate requested
option
KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption
type
KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been
revoked
KDC_ERR_TGT_REVOKED 20 TGT has been revoked
KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again
later
KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again
later
KDC_ERR_KEY_EXPIRED 23 Password has expired - change
password to reset
KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information
was invalid
KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication
required*
KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field
failed
KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
KRB_AP_ERR_REPEAT 34 Request is a replay
KRB_AP_ERR_NOT_US 35 The ticket isn't for us
KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
KRB_AP_ERR_SKEW 37 Clock skew too great
KRB_AP_ERR_BADADDR 38 Incorrect net address
KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
KRB_AP_ERR_MODIFIED 41 Message stream modified
KRB_AP_ERR_BADORDER 42 Message out of order
KRB_AP_ERR_BADKEYVER 44 Specified version of key is not
available
KRB_AP_ERR_NOKEY 45 Service key not available
KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
KRB_AP_ERR_METHOD 48 Alternative authentication method
required*
KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in
message
KRB_ERR_GENERIC 60 Generic error (description in e-text)
KRB_ERR_FIELD_TOOLONG 61 Field is too long for this
implementation
*This error carries additional information in the e-data field. The
contents of the e-data field for this message is described in section
5.9.1.
9. Interoperability requirements
Version 5 of the Kerberos protocol supports a myriad of options.
Among these are multiple encryption and checksum types, alternative
encoding schemes for the transited field, optional mechanisms for
pre-authentication, the handling of tickets with no addresses,
options for mutual authentication, user to user authentication,
support for proxies, forwarding, postdating, and renewing tickets,
the format of realm names, and the handling of authorization data.
In order to ensure the interoperability of realms, it is necessary to
define a minimal configuration which must be supported by all
implementations. This minimal configuration is subject to change as
technology does. For example, if at some later date it is discovered
that one of the required encryption or checksum algorithms is not
secure, it will be replaced.
9.1. Specification 1
This section defines the first specification of these options.
Implementations which are configured in this way can be said to
support Kerberos Version 5 Specification 1 (5.1).
Encryption and checksum methods
The following encryption and checksum mechanisms must be supported.
Implementations may support other mechanisms as well, but the
additional mechanisms may only be used when communicating with
principals known to also support them: Encryption: DES-CBC-MD5
Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
Realm Names
All implementations must understand hierarchical realms in both the
Internet Domain and the X.500 style. When a ticket granting ticket
for an unknown realm is requested, the KDC must be able to determine
the names of the intermediate realms between the KDCs realm and the
requested realm.
Transited field encoding
DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be
supported. Alternative encodings may be supported, but they may be
used only when that encoding is supported by ALL intermediate realms.
Pre-authentication methods
The TGS-REQ method must be supported. The TGS-REQ method is not used
on the initial request. The PA-ENC-TIMESTAMP method must be supported
by clients but whether it is enabled by default may be determined on
a realm by realm basis. If not used in the initial request and the
error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENCTIMESTAMP
as an acceptable method, the client should retry the initial request
using the PA-ENC-TIMESTAMP preauthentication method. Servers need not
support the PAENC-TIMESTAMP method, but if not supported the server
should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in
a request.
Mutual authentication
Mutual authentication (via the KRB_AP_REP message) must be supported.
Ticket addresses and flags
All KDC's must pass on tickets that carry no addresses (i.e., if a
TGT contains no addresses, the KDC will return derivative tickets),
but each realm may set its own policy for issuing such tickets, and
each application server will set its own policy with respect to
accepting them. By default, servers should not accept them.
Proxies and forwarded tickets must be supported. Individual realms
and application servers can set their own policy on when such tickets
will be accepted.
All implementations must recognize renewable and postdated tickets,
but need not actually implement them. If these options are not
supported, the starttime and endtime in the ticket shall specify a
ticket's entire useful life. When a postdated ticket is decoded by a
server, all implementations shall make the presence of the postdated
flag visible to the calling server.
User-to-user authentication
Support for user to user authentication (via the ENC-TKTIN-SKEY KDC
option) must be provided by implementations, but individual realms
may decide as a matter of policy to reject such requests on a per-
principal or realm-wide basis.
Authorization data
Implementations must pass all authorization data subfields from
ticket-granting tickets to any derivative tickets unless directed to
suppress a subfield as part of the definition of that registered
subfield type (it is never incorrect to pass on a subfield, and no
registered subfield types presently specify suppression at the KDC).
Implementations must make the contents of any authorization data
subfields available to the server when a ticket is used.
Implementations are not required to allow clients to specify the
contents of the authorization data fields.
9.2. Recommended KDC values
Following is a list of recommended values for a KDC implementation,
based on the list of suggested configuration constants (see section
4.4).
minimum lifetime 5 minutes
maximum renewable lifetime 1 week
maximum ticket lifetime 1 day
empty addresses only when suitable restrictions appear
in authorization data
proxiable, etc. Allowed.
10. Acknowledgments
Early versions of this document, describing version 4 of the
protocol, were written by Jennifer Steiner (formerly at Project
Athena); these drafts provided an excellent starting point for this
current version 5 specification. Many people in the Internet
community have contributed ideas and suggested protocol changes for
version 5. Notable contributions came from Ted Anderson, Steve
Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows,
Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill
Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon,
Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted
T'so, and Stanley Zanarotti. Many others commented and helped shape
this specification into its current form.
11. References
[1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section
E.2.1: Kerberos Authentication and Authorization System",
M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
1987.
[2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
Authentication Service for Open Network Systems", pp. 191-202 in
Usenix Conference Proceedings, Dallas, Texas, February, 1988.
[3] Needham, R., and M. Schroeder, "Using Encryption for
Authentication in Large Networks of Computers", Communications
of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
[4] Denning, D., and G. Sacco, "Time stamps in Key Distribution
Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536,
August 1981.
[5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the
Kerberos Authentication Service", in an IEEE Computer Society
Text soon to be published, June 1992.
[6] Davis, D., and R. Swick, "Workstation Services and Kerberos
Authentication at Project Athena", Technical Memorandum TM-424,
MIT Laboratory for Computer Science, February 1990.
[7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K.
Raeburn, "Section E.1: Service Management System, M.I.T.
Project Athena, Cambridge, Mas sachusetts (1987).
[8] CCITT, Recommendation X.509: The Directory Authentication
Framework, December 1988.
[9] Neuman, C., "Proxy-Based Authorization and Accounting for
Distributed Systems," in Proceedings of the 13th International
Conference on Distributed Computing Systems", Pittsburgh, PA,
May 1993.
[10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
Attacks", Open Software Foundation DCE Request for Comments 26,
December 1992.
[11] National Bureau of Standards, U.S. Department of Commerce, "Data
Encryption Standard", Federal Information Processing Standards
Publication 46, Washington, DC (1977).
[12] National Bureau of Standards, U.S. Department of Commerce, "DES
Modes of Operation", Federal Information Processing Standards
Publication 81, Springfield, VA, December 1980.
[13] Stubblebine S., and V. Gligor, "On Message Integrity in
Cryptographic Protocols", in Proceedings of the IEEE Symposium
on Research in Security and Privacy, Oakland, California, May
1992.
[14] International Organization for Standardization, "ISO Information
Processing Systems - Data Communication High-Level Data Link
Control Procedure - Frame Structure", IS 3309, October 1984, 3rd
Edition.
[15] Rivest, R., "The MD4 Message Digest Algorithm", RFC1320, MIT
Laboratory for Computer Science, April 1992.
[16] Rivest, R., "The MD5 Message Digest Algorithm", RFC1321, MIT
Laboratory for Computer Science, April 1992.
[17] Bellovin S., and M. Merritt, "Limitations of the Kerberos
Authentication System", Computer Communications Review, Vol.
20(5), pp. 119-132, October 1990.
12. Security Considerations
Security issues are discussed throughout this memo.
13. Authors' Addresses
John Kohl
Digital Equipment Corporation
110 Spit Brook Road, M/S ZKO3-3/U14
Nashua, NH 03062
Phone: 603-881-2481
EMail: jtkohl@zk3.dec.com
B. Clifford Neuman
USC/Information Sciences Institute
4676 Admiralty Way #1001
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
EMail: bcn@isi.edu
A. Pseudo-code for protocol processing
This appendix provides pseudo-code describing how the messages are to
be constructed and interpreted by clients and servers.
A.1. KRB_AS_REQ generation
request.pvno := protocol version; /* pvno = 5 */
request.msg-type := message type; /* type = KRB_AS_REQ */
if(pa_enc_timestamp_required) then
request.padata.padata-type = PA-ENC-TIMESTAMP;
get system_time;
padata-body.patimestamp,pausec = system_time;
encrypt padata-body into request.padata.padata-value
using client.key; /* derived from password */
endif
body.kdc-options := users's preferences;
body.cname := user's name;
body.realm := user's realm;
body.sname := service's name; /* usually "krbtgt",
"localrealm" */
if (body.kdc-options.POSTDATED is set) then
body.from := requested starting time;
else
omit body.from;
endif
body.till := requested end time;
if (body.kdc-options.RENEWABLE is set) then
body.rtime := requested final renewal time;
endif
body.nonce := random_nonce();
body.etype := requested etypes;
if (user supplied addresses) then
body.addresses := user's addresses;
else
omit body.addresses;
endif
omit body.enc-authorization-data;
request.req-body := body;
kerberos := lookup(name of local kerberos server (or servers));
send(packet,kerberos);
wait(for response);
if (timed_out) then
retry or use alternate server;
endif
A.2. KRB_AS_REQ verification and KRB_AS_REP generation
decode message into req;
client := lookup(req.cname,req.realm);
server := lookup(req.sname,req.realm);
get system_time;
kdc_time := system_time.seconds;
if (!client) then
/* no client in Database */
error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);