For an overview of this chapter, see
For the convenience of the reader, cross-references between this document and RFC 1510 are explicitly indicated generously throughout this chapter, using notation of the form "[RFC 1510: x.y.z]" as a reference to RFC 1510, Section x.y.z.
This chapter employs the "ASN.1/BER/DER" standards for data
description/representation (IDL is used only in
Furthermore, implementations that transmit any currently unspecified bits of BIT STRING must reset them, for reasons of future extensibility and compatibility. (Note that some existing implementations emit full BER, not just the DER subset-new implementations that want to interoperate with those old implementations should therefore accept full BER, but in order to be conformant to this document they must generate DER.)
[RFC 1510: 1]
These (especially cells) often appear as subscripts (for example,
KDSZ, KDSX,Y),
but in order to improve legibility of embedded subscripts they will
upgraded when they themselves appear in subscripts
(for example, KKDSZ, KKDSXY
instead of KKDSZ,
KKDS\dX,Y).
[RFC 1510: 8.2]
The semantics of
RPC binding handle, bound by the client C to a KDS server
KDSZ.
Length, in bytes, of KDS Request.
(Array) value (that is, data bytes, or "contents octets") of KDS Request.
Length of buffer supplied (response[]) to receive KDS Response.
(Pointer to) length, in bytes, of KDS Response.
(Array) value of KDS Response.
(Pointer to) status code.
The currently registered values for status (returnable by
Success in the communications sense; that is, a (purported) KDS has
successfully received, processed and responded to the request-
hence, there is a well-formed response in the response[] output
parameter. Whether or not the request was successful in the security
sense must be determined by the examination of response[], as
specified in
The contents, formats and semantics of request[] and
response[] (including their lengths, request_count and
response_count) are defined below (beginning in
[RFC 1510: 1]
AS Request/AS Response message pair (that is,
request[] is a value of data type ASRequest, and
response[] is a value of data type ASResponse).
This is the service by which clients acquire new initial tickets.
TGS Request/TGS Response message pair (that is,
request[] is a value of data type TGSRequest, and
response[] is a value of data type TGSResponse).
This is the service by which clients either acquire new subsequent
tickets, or manipulate old (initial or subsequent) tickets.
Thus, a KDS Request message is either an AS Request or TGS Request message,
and a KDS Response message is either an AS Response or TGS Response message.
The KDS supports one additional kind of response message, for reporting
errors:
[RFC 1510: 1, 1.1, 2.1]
The KDS server(s) (which are trusted third parties) that
(cooperatively) issued this ticket, also said to be
the issuing authorities for the ticket.
The client that this ticket authenticates to the targeted server
(called B in next item).
The ticket is also said to be issued in the name of A.
The server that this ticket authenticates to the named client
(called A in previous item).
As will be seen below, there are relationships amongst
A, B, X, Y and Z´, ···,
Z´´ that must be satisfied for a ticket to be valid,
namely a trust chain must be established:
Here, the arrows denote links in the trust chain, not communicated
messages; more precisely (as discussed below), the above trust chain
notation is actually shorthand for the trust chain of principals:
The following notation can be used:
for a ticket as described above. The home cells X and Y can be
omitted from the notation because they are implicitly known from knowledge of
A and B, but it is convenient to include them for information.
All the issuing authorities can even be omitted from the notation if
they are implicitly understood or are uninteresting in a given context:
The simple special case of intra-cell tickets can be abbreviated:
As described in
It is stored in the RSZ datastore of C's home
cell Z, and it is considered to be secure if and only if it
is known only by C and TCBZ (or other
TCB components; for example, on the local host). Long-term
keys are primarily used to protect internal protocol meta-data (tickets).
It is not stored in any RS datastore, but rather is generated dynamically
for transmittal by a ticket or an authentication header or
reverse-authentication header (these are defined later).
It is considered to be secure if and only if it is known only by A
and B, and by third parties they (implicitly or explicitly) trust:
TCBX, TCB
Tickets are further classified into two broad kinds of category:
Targeted to (that is, protected with the long-term key of) a KDS server or
to a non-KDS server, respectively. (In general, the distinction
between ticket-granting-tickets and service-tickets is to be avoided, unless
it is absolutely necessary.)
Issued on the basis of, respectively, an unauthenticated (or merely
preauthenticated) request, or an authenticated request.
That is, the issuing authority(ies) are, respectively, uncertain
or certain (in the sense of "certainty" afforded by a
ticket-granting-ticket naming the client)
that the identity of the requesting client
(a communications concept), C, is the same as that of the ticket's
named client or "claimed identity" (a security concept).
Equivalently, initial tickets are those issued on the basis
of the AS Request/Response message exchange, while subsequent tickets
are those issued on the basis of the TGS Request/Response exchange.
(See the definition of the tkt-Initial flag in
[RFC 1510: 8.3]
Its semantics are that it identifies the KDS protocol version in use.
Values for protocol version numbers are centrally registered. Currently
registered values are collected in
[RFC 1510: 8.3]
[RFC 1510: 8.3]
Its semantics are that it identifies KDS protocol messages. Values for
protocol message types are centrally registered. Currently registered values
are collected in
[RFC 1510: 8.3]
(Note that the other protocol message types defined in RFC 1510
are not defined or used in DCE.)
[RFC 1510: 5.2, 5.3.2]
The only allowable values of this data type are in the range [0, 999999].
Nominally, the semantic of this data type is to indicate the number of
microseconds past an accompanying (second-granularity) timestamp.
However, the real security semantic of this data type is to function as a
per-second nonce (see
[RFC 1510: 1.2]
All timestamp interpretations in this chapter are to be understood
"modulo
maxClockSkew"
(where the word
"modulo"
is here used in its common English sense, not in its technical
mathematical sense, for which the short form "mod" is reserved).
For example, to say that two timestamps,
T
[RFC 1510: 5.2]
Its semantics are that it provides references to cells by means of a
"global naming/directory service" (see the referenced Open Group DCE 1.1 Directory Services Specification),
which is "external" to security services (contrast this with
RS names, below). Cell names themselves carry enough syntactic
information to distinguish amongst different global naming services
(hence a separate "-Type" field is not necessary for cell
names, as it is for RS names). Acceptable syntaxes for cell names are
centrally registered. Currently registered syntaxes are collected in
[RFC 1510: 7.1]
The Internet Domain Naming System (DNS) syntax is specified in the
referenced Open Group DCE 1.1 Directory Services Specification. It provides a hierarchical (little-endian)
namespace, with "." as (non-escapable) component-separating
metacharacter, and the characters "/", ":" are not
permitted in names; for example, abc.def.com
(or /.../abc.def.com in the fully qualified DCE syntax).
The DCE X.500 syntax is specified in the referenced Open Group DCE 1.1 Directory Services Specification.
It provides a hierarchical (big-endian) namespace, with
"/" as
(escapable) component-separating metacharacter (other metacharacters
"=", ",", "\" are used for other purposes), and
the character ":" cannot occur in any component before the
"=" (meta)character; for example, c=xy/o=fed/ou=cba
(or /.../c=xy/o=fed/ou=cba in the fully qualified DCE syntax).
The prefixed name type has the syntax:
where NAMETYPE is a centrally registered prefix that contains no
".", "/" or ":", and where rest-of-name is
a string whose syntax is determined by the value of NAMETYPE.
Currently, there are no registered NAMETYPE prefixes.
All other cell naming syntaxes are reserved for future extensibility.
[RFC 1510: 5.3.1]
Its semantics are that it indicates the trust chain of KDS servers
that have participated in a cross-cell authentication. Its fields are the
following:
The kind of transit path that transitPath-Value represents, including
its syntax.
The transited path information itself, to be interpreted according to
the value of transitPath-Type.
Values of TransitPathType are reserved for centrally registered
transit path data types. The currently registered values are collected in
[RFC 1510: 8.3, 3.3.3.1]
This transit path type is used for transit paths through cells with DNS
and X.500 cell names, with an (optional) compression technique
(where "optional" means that implementations need not employ
compression on output, though they must accept it on input).
It is defined as follows.
The transit paths (values of type transitPath-Value) of this
transit path type represent the (underlying OCTET STRINGs of the)
cell names (that is, CellName GeneralStrings) of the successive
transited cells, treated as an unordered set (in other words, not
necessarily in the order in which they were visited),
expressed in a syntax that supports
lexical compression (to conserve
communications bandwidth), as specified below.
This transit path type depends on the Internet DNS and DCE X.500
syntaxes being the only cell name types in effect; transit paths of
this type typically contain no upper-case letters (since the
"canonicalised" forms of names in these syntaxes contain no upper-case
letters), though implementations must accept both cases on input.
Compressed transit paths represent expanded transit paths, by expanding
their compressed components one at a time, left to right, according to
the following rules (examples are given below):
Here are some examples of some compressed transit paths, and their
expansions (where, for clarity in the expansions, the client and server
cells are shown explicitly, and the symbol "->" is used with them
and also in place of the "," metacharacter). (Recall that the
initial "/.../" of the DCE naming syntax is only
implicitly, not explicitly, present.)
Expands to:
Expands to:
Expands to:
Expands to (since it is not compressed to begin with):
Expands to:
Expands to the same thing as in the preceding example, assuming the
client and server cells are the same as in that example.
[RFC 1510: 5.2]
Its semantics are that it indicates the per-cell hierarchical names
supported by the RS datastores. Its fields are the following:
The kind of name that rsName-Value represents, including its
syntax.
The name information itself, to be interpreted according to the value of
rsName-Type. The entries rsName-Value[0],
rsName-Value[1], ···, are called the components
of the RS name.
Values of RSNameType are reserved for
centrally registered principal names types.
The currently registered values are collected in
[RFC 1510: 7.2, 8.2.3]
Identifies principals registered in the RS datastore.
The first component (rsName-Value[0]) of the RS name identifies an
abstract service, and the remaining components
(rsName-Value[i], i >= 1)
identify various concrete instances; that is, principal identities
under which this service renders its services.
As discussed in
The main use of the RS name type rsNameType-SERVER-INSTANCE is for the
KDS itself, especially in cross-cell registrations. In that
application, rsName-Value[0] is krbtgt (a name which is
reserved for this use), and (the underlying GeneralString of)
rsName-Value[1] is identical to the string-name
of the cross-registered cell's KDS. This is
illustrated by the following examples, assuming X and Y are
cells with names cellX and cellY, respectively
(actually, "cellX" and "cellY" denote cell names with an
internal syntactic structure (for example, Internet DNS syntax or DCE
X.500 syntax), but that is irrelevant for this example):
The RS name of KDS
The RS name of KDS
Unless stated otherwise, all RS names in this chapter
identifying KDSs (including their surrogates) are assumed to have type
rsNameType-SERVER-INSTANCE, and all non-KDSs are assumed to have
type rsNameType-PRINCIPAL.
[RFC 1510: 5.2]
Its semantics are that it represents a "fully qualified" (in the
semantic sense, not the syntactic sense) principal name, consisting of a
cell name and an RS name.
The relationship between the semantic CellAndRSName data type and
the DCE syntactic
string forms of principal names (or just stringnames, for
short) is as follows: if cellAndRSName is a value of type
CellAndRSName, whose underlying cellName is, say,
cellX, and whose underlying rsName-Values (that is, their
underlying GeneralStrings, disregarding their
rsName-Types) are, say, <rsName
Note that the CellAndRSName data type doesn't occur directly in the
remaining data types and protocols defined in the remainder of this
chapter: the concept of principal name is used throughout, though
its two component fields (cellName and rsName) appear
separately, not bound together in a CellAndRSName data type.
[RFC 1510: 5.2]
Its semantics are that it represents the host (that is,
computer) address(es) (zero or more of them) at which a host is
connected to a communications (network) substrate.
Its fields are the following:
The kind of address that hostAddr-Value
represents, including its syntax.
The address information itself, to be interpreted
according to the value of hostAddr-Type.
Non-negative values of HostAddressType are reserved for
centrally registered host address types; negative values are
unreserved (and may, therefore, be assigned locally). The currently
registered values are collected in
[RFC 1510: 8.1]
Internet address (corresponding HostAddressValue is 4 octets
long).
CHAOSnet address (corresponding HostAddressValue is 2 octets
long).
XNS address (corresponding HostAddressValue is 6 octets long).
ISO address (corresponding HostAddressValue has variable
length).
DECnet Phase IV address (corresponding HostAddressValue is 2
octets long).
AppleTalk DDP address (corresponding HostAddressValue is 3
octets long).
[RFC 1510: 3.2.2, 5.3.2]
Its semantics are that it indicates the sequence number of
a message in a multi-message sequence (for example, the
(potentially) several fragments of a fragmented message).
The detailed use of sequence numbers is application-specific.
Typically, the initial sequence number is chosen randomly (see below
for "random" numbers), and subsequent sequence numbers are unit
increments from the initial one.
For security purposes, the individual messages (fragments) and
the sequence numbers
themselves must be bound together and protected in an appropriate
application-specific way.
(In the case of DCE RPC applications, the use of sequence numbers is
specified as part of the RPC protocol specifications-see
[RFC 1510: 5.2]
Its semantics are that it indicates information maintained by a
principal's home KDS of the principal's most recent KDS service requests.
Its fields are the following:
The kind of last request that lastReq-Value represents.
The time of the request, to be interpreted according to the value of
lastReq-Type.
All values of LastRequestType are reserved for centrally registered
last request types. The currently registered values are collected in
[RFC 1510: 5.2]
No information is conveyed by lastReq-Value.
Time of most recent previous AS Request by this principal for an
(initial) ticket-granting-ticket.
Time of most recent previous AS Request by this principal (for an
initial ticket, whether a ticket-granting-ticket or a service-ticket).
Authentication time (see
Time of most recent previous successful renewal by this principal.
Time of most recent previous KDS Request (AS Request or TGS Request) by
this principal, of any type, successful or not.
[RFC 1510: 5.9.1]
Their semantics are that they indicate error conditions of a
failed KDS Request. Values of these three data types always occur
as a triple consisting of an ErrorStatusCode,
an ErrorStatusText (optionally) and an ErrorStatusData
(optionally). The value of ErrorStatusCode identifies an error that
occurred; ErrorStatusText is a character string accompanying
ErrorStatusCode explaining the error in a human-readable fashion,
and ErrorStatusData is supplementary information further
explaining the error in machine-readable fashion.
Note that since ErrorStatusData is merely an "opaque" OCTET
STRING, its interpretation must be implicit from the corresponding
ErrorStatusCode.
Values of error status codes (with associated error text and data) are
centrally registered. The currently registered values are collected in
[RFC 1510: 8.3]
Values of ErrorStatusCode data type.
Values of ErrorStatusText data type.
Values of ErrorStatusData data type.
Registered status codes without accompanying registered status text
and/or status data indicates that the latter are not currently specified
(but may be in a later revision of this document).
(Some terminology is used in these descriptions that won't be formally
introduced until later.)
No error (that is, success).
Client entry in RS datastore has expired.
Server entry in RS datastore has expired.
Protocol version number not supported.
Client's key encrypted in an old (expired) master key, in the following sense.
It is recommended that implementations of DCE protect all copies
of the RS datastore
other than those actually in use (in the address spaces of trusted
programs) at any given moment
(such as on-disk files, tape backups, and so on) by encrypting them
(or at least
the sensitive data contained in them, especially accounts' long-term
keys), using some policy-dependent or implementation-dependent trusted
encryption mechanism. An encryption key used for this purpose is known
as a master key. A master key is said to be "old" if it is
expired or
unavailable (for whatever reason-it may just have been lost). In
such a case, accounts' keys are unavailable; that is, accounts are
"locked out" until a new key is established by the security
administrator.
(Typical implementations use different master keys for different
datastore entries, disambiguating them with version numbers, so that the
datastore can be incrementally upgraded from one master key to
another.) Thus, the master key plays no direct part in the protocol,
but surfaces only in this failure code.
Server's key encrypted in old master key. (For explanation, see
preceding error code.)
Client entry not found in RS datastore.
Server entry not found in RS datastore.
Multiple entries for principal found in RS datastore.
Principal has NULL long-term key in RS datastore.
Ticket not eligible for postdating.
Requested ticket lifetime is too short (for example, this is always
the case if the requested start time is later than the requested
expiration time).
Request not supported by local cell policy (as held in RS).
Cannot accommodate requested option.
Encryption type(s) not supported.
Checksum type not supported.
Authentication data type not supported.
Transit path type not supported.
Credentials for client have been revoked.
Credentials for server have been revoked.
Ticket has been revoked.
Client not (yet) valid, perhaps due to a transitory condition ("try
again later").
Server not (yet) valid, perhaps due to a transitory condition ("try
again later").
Unsuccessful decryption (detected by the "built-in integrity" feature
of DCE encryption types-see
Ticket expired (that is, server's system time is later than ticket's
expiration time (modulo
maxClockSkew)).
Ticket is invalid (that is, its invalid option is selected).
Request is a repeat of an earlier one.
Request intended for another server, not this one.
Ticket and authenticator do not match.
Clock skew is (apparently) greater than
maxClockSkew.
Bad host address.
Protocol version number mismatch.
Invalid protocol message type.
Bad checksum.
(Unless the checksum was incorrectly generated, this means that
message stream modification has been detected.)
Message is out of order (that is, doesn't conform to the protocol).
Bad key version number.
Server's key not available.
Mutual authentication failure.
Bad message direction (client <­-> server direction reversed).
Alternative authentication method is required.
It is (the underlying OCTET STRING of) a value of the data type
AuthnMethodData, defined by:
Its semantics are that it indicates the alternative authentication method
required. Its fields are the following:
The kind of authentication method required.
Any additional information required,
to be interpreted according to the value of authnMethod-Type.
Non-negative values of AuthnMethodType are reserved for centrally
registered authentication data types; negative values are unreserved (and may,
therefore, be assigned locally). There are no currently registered values.
Bad sequence number (that is, message fragment is out of order).
Bad type of checksum being used (for example, one which has been found to be
insecure).
Generic, catch-all error code.
Field is too long for this implementation.
The data types defined in this section are specifically related to
cryptography and security.
[RFC 1510: 5.4.1, 5.8.1]
Its semantics are that it indicates a per-context unique (or distinct,
or "one-time") number; that is, a number which is always
distinguishable
from any other when used in a given context (where an appropriate notion
of "context" must be specified whenever nonces are used).
In the particular application of nonces in this chapter (.cX sec4-12-3
and
[RFC 1510: 3.1.3, 3.2.6]
Its semantics are that it indicates a number which is unpredictable.
That is, it is required that random number generators used in any
implementation of the DCE Security Services are of cryptographic
high-quality; that is, it must be computationally infeasible to
predict the next random number to be generated, even if the sequence of
all previously generated random numbers are known. In essence, this
means that every possible value has equal probability of being generated
as every other value, at every invocation of the random number
generator, but there may be occasions when slight modifications of this
idea are warranted (for example, when keys are "changed", the "new" key
should be guaranteed to be different than the "old" key).
[RFC 1510: 6.2]
Its semantics are that it indicates the key for (one or more) encryption
mechanism(s) and/or checksum mechanisms (see below).
Its fields are the following:
The encKey-Type's key type; that is, the
kind of encryption key that encKey-Value represents.
The encKey-Type's encryption key information itself, to be
interpreted according to the value of encKey-Type.
Non-negative values of EncryptionKeyType are reserved for centrally
registered encryption key types; negative values are unreserved (and
may, therefore, be assigned locally). The currently registered values
are collected in
[RFC 1510: 6.3.1, 8.3]
K has type encKeyType-TRIVIAL if and only if K is the
trivial key; that is, it is the empty OCTET STRING, of length 0.
K has type encKeyType-DES if and only if K is a DES
key (64 bits long, though with only 56 "active" bits, and of odd
parity-see
[RFC 1510: 6.4]
Its semantics are that it indicates a (non-invertible) checksum (or
message digest, or one-way function) of some plaintext (which must be
specified in context). Its fields are the following:
The CheckSum's checksum type; that is, the kind of checksum
mechanism used to generate the cksum-Value.
The CheckSum's checksumtext; that is, the actual cryptographic
information conveyed by this data structure, to be interpreted according
to the value of cksum-Type. It is the checksumtext, of checksum type
cksum-Type, of (the underlying byte string of) an
application-specific data value.
Non-negative values of CheckSumType are reserved for centrally
registered checksum mechanism types; negative values are unreserved (and
may, therefore, be assigned locally). The currently registered values
are collected in
[RFC 1510: 6.4.5, 8.3, 9.1]
[RFC 1510: 6.3.1]
Let K be an encryption key of type encKeyType-DES, and let
P be a plaintext bit-message. Then the corresponding
cksum-Value, denoted:
is defined by the following pseudocode algorithm:
Let K be an encryption key of type encKeyType-DES, and let
P be a plaintext bit-message. Then the corresponding
cksum-Value, denoted:
is defined by the following pseudocode algorithm:
Checksum used in the CL-RPC Conversation Manager protocol-see
Checksum used in the CO-RPC protocol-see
[RFC 1510: 6.1]
Its semantics are that it indicates an (invertible) encryption of some
plaintext (which must be specified in context).
Its fields are the following:
The EncryptedData's encryption type; that is, the kind of
encryption mechanism used to generate the encData-CipherText.
Encryption mechanisms depend on encryption keys, so the
encData-EncType implicitly declares an associated
EncryptionKey encKey-Type (though a given encKey-Type may be
associated with multiple encData-EncTypes).
Once it has been negotiated (that is, agreed upon, in an
application-specific manner), it remains constant throughout a given
client-server conversation, until it is renegotiated or the
conversation ends.
As used in DCE, the key version number is (using notation and
terminology introduced later in this chapter):
The key version number is generally omitted from the notations of this
chapter, and usually speaks of "the" encryption type in a given context
(this will never cause confusion).
The EncryptedData's encryption key version number;
that is, a number selecting the precise encryption key (value of type
EncryptionKey, appropriate to encryption type
encData-EncType) used to generate the
encData-CipherText.
It need only be present under conditions where multiple keys may be
outstanding. It is generally omitted from the notations of this chapter,
preferring to speak of "the" key (modulo its version
number) in a given context (this will never cause confusion).
The EncryptedData's ciphertext; that is, the actual cryptographic
information (the encryption of some plaintext bit-string)
conveyed by this data structure, to be interpreted according
to the values of encData-EncType and encData-KeyVersNum.
It is the ciphertext, of encryption type encData-EncType and key
version number encData-KeyVersNum (if present), of (the underlying
bit-string of) an application-specific data value.
Non-negative values of EncryptionType are reserved for
centrally registered encryption types; negative values are
unreserved (and may, therefore, be assigned locally). The currently
registered values are collected in
[RFC 1510: 6.1, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 8.3, 9.1]
Let K be an encryption key of type encKeyType-TRIVIAL, and let
P be a plaintext bit-message. Then the corresponding
encData-CipherText is simply the plaintext P itself, 0-padded if
necessary to have length a non-negative multiple of 8 bits (because it
must be an OCTET STRING). This encryption type does not afford
an adequate basis for security in a potentially hostile ("open")
environment.
Let K be an encryption key of type encKeyType-DES, and let
P be a plaintext bit-message. Then the corresponding
encData-CipherText, denoted:
is defined by the following pseudocode algorithm:
The krb5rpc RPC Interface
AS and TGS Services
Tickets, Keys, and Cross-Registration
Z´, ···,
KDSZ´´
X,X ->
KDSX,Z´ ->
··· ->
KDSZ´´,Y ->
KDSY,Y ->
B
A,X,Z´,···,Z´´,Y,B or
TktA,Z´,···,Z´´,B
A,···,B or TktA,B
A,X,B (instead of
TktA,X,X,B)
A,B
Some Basic Data Types
Protocol Version Numbers
Registered Protocol Version Numbers
Protocol Message Types
Registered Protocol Message Types
Timestamps, Microseconds, and Clock Skew
Maximum Allowable Clock Skew
Cell Names
Registered Syntaxes for Cell Names
Transit Paths
Registered Transit Path Types
RS Names
Registered RS Name Types
X,X, which is the principal of the
KDS server, KDSX, for cell X.
It is held as a datastore item in RSX's datastore.
Principal Names
0/···/
rsNamer-1
Host Addresses
Registered Host Address Types
Sequence Numbers
Last Requests
Registered Last Request Types
Error Status Codes/Text/Data
Registered Error Status Codes/Text/Data
Cryptography- and Security-Related Data Types
Nonces
Random Numbers
Encryption Keys
Registered Encryption Key Types
f0 is weak
or semi-weak; and they should avoid generating keys for which K
or K ^ Kf0 is possibly weak (though they should
accept such keys from foreign sources).
(The reason for the conditions concerning the variant key is because of
the use of variant keys in the algorithm of
Checksums
Registered Checksum Types
64 = RANDOM64();
P' = <R64, P>;
C128 = MD4(P');
P" = <R64, C128>;
K' = K ^ Kf0;
MD4-DES(K, P) = DES-CBC(K', P");
Encrypted Data
Registered Encryption Types
Let K be an encryption key of type encKeyType-DES, and let P be a plaintext bit-message. Then the corresponding encData-CipherText, denoted:
is defined by the following pseudocode algorithm:
In words: First generate a random 64-bit vector, R64
(called a confounder when used in this context-see
Let K be an encryption key of type encKeyType-DES, and let P be a plaintext bit-message. Then the corresponding encData-CipherText, denoted:
is defined by the following pseudocode algorithm:
In words: First generate a random 64-bit vector, R64
(called a confounder when used in this context-see
Note that the degree of assurance of this built-in integrity depends upon the strength of the cryptographic algorithms involved. In particular, non-collision-proof checksums (such as CRC-32) may be susceptible to attacks (such as truncation attacks) that render some assertions invalid (such as the one in the preceding paragraph about not needing to explicitly convey the length of the plaintext).
[RFC 1510: 1.2, 6]
Its semantics are that it indicates a (byte string representation of a)
character string (typically a "memorisable but unguessable" one,
relative to some natural language) associated with a principal, C,
from which the long-term encryption key KC for
C (relative to a specified encryption type encType),
held in the RS datastore, is derived. The notion of passwords exists
because there is a need for humans to be able to securely store a
secret, and the best way to do that is to memorise it ("store it in
their brain"), which is within normal human capabilities for passwords
but not for random ("strong") encryption keys. DCE specifies
one or more password-to-encryption-key mapping for each supported encryption
key type, and these mappings are centrally registered. The currently
registered ones are collected in
[RFC 1510: 6.3.4]
The password itself. It is a value of type PassWord; that is, a byte
string. Typically it is derived from the character string password input
parameter to
An initialising string (also called seed, pepper, mix-in string, and so on). Its value is a byte string. If no salt is explicitly specified, it defaults to the default salt, which consists (in a manner specified below) of:
The (home) cell of the principal whose password is to be mapped; that is, the name of the cell in whose RS datastore the principal is registered. It is a value of type CellName, which is a GeneralString.
The RS name of the principal whose password is to be mapped. It is a value of type RSName, which consists of an rsName-Type and of an rsName-Value which is a sequence of GeneralStrings-call the components of this sequence rsName0, ···, rsNamer-1.
Corresponding to the input parameters cellName and rsName (which are GeneralStrings), the underlying BER string of "contents octets" of their GeneralStrings is denoted (that is, the BER encoding stripped of its "identifier octets" and "length octets"-no "end-of-contents octets" are present because of the DER in force), which are strings of octets, by respectively:
The default salt, mentioned above but not yet specified explicitly, is now defined to be:
In words: DEFAULTSALT is the concatenation of (the underlying strings of octets of) CN and of the components of RSN.
With the above notations, the currently registered password-to-key mappings, corresponding to the currently registered encryption key types, are defined as follows.
All passWords, cellNames and rsNames map to the unique (trivial) key of type encKeyType-TRIVIAL.
The mapping of a passWord and salt (the latter, unless explicitly indicated otherwise, defaults to DEFAULTSALT) to a key K of type encKeyType-DES is defined by the following algorithm.
First, pad the password and salt:
In words: PWS ("password-with-salt") is the concatenation of (the byte strings) passWord and of salt, appended with 0-bits to a (positive) multiple of 64 bits. PWS is considered to be a (pseudocode) array of 64-bit blocks, denoted:
where each PWS[j] has length 64 bits. The key K is
then defined by the following pseudocode:
[RFC 1510: 5.4.1]
Its semantics are that it indicates
information that is exchanged between clients and
KDS servers (in KDS Request/Response exchanges), which may be required
before KDS services (that is, ticket issuance) can be accessed.
(Note that the KDS does not support ACLs for access control to its
AS/TGS services-just the opposite: tickets are
required before PACs can be obtained, on which ACLs are based.) In
the case of AS Request/Responses (as opposed to TGS
Request/Responses), this information is usually referred to as
pre-authentication data, because AS Request/Responses are, in
fact, "unauthenticated" (in the sense of not containing an
"authentication header" as defined in
The kind of authentication data that AuthnData-Value represents, including its format.
The authentication data information itself, to be interpreted according to the value of authnData-Type.
Non-negative values of AuthnDataType are reserved for
centrally registered authentication data types; negative values are
unreserved (and may, therefore, be assigned locally). The currently
registered values are collected in
[RFC 1510: 8.3]
authnData-Value contains (the underlying OCTET STRING of) an
authentication header (defined in
authnData-Value contains (encoded as an OCTET STRING)
a "salt" (whose underlying contents octets are to be used in
computing the principal's key from its password-see
[RFC 1510: 5.2]
Its semantics are that it indicates information that may be (depending on application-specific authorisation policy) needed by a server in order to determine a client's access to the server's services. Its fields are the following:
The kind of authorisation data that authzData-Value represents, including its format.
The authorisation data information itself, to be interpreted according to the value of authzData-Type.
Non-negative values of AuthzDataType are reserved for centrally
registered authorisation data types; negative values are unreserved
(and may, therefore, be assigned locally). The currently registered
values are collected in
-
-
if (authzData[0], ···, authzData[n-1] all grant access) {
GRANT access;
} else {
DENY access;
}
[RFC 1510: 8.3]
Pickled PACs, as specified in
[RFC 1510: 5.3.1]
Its semantics have been described in
The protocol version number of the Ticket data type.
Its value is protoVersNum-KRB5.
B's home cell, Y.
B's RS name in RSY.
The encryption type (encData-EncType), key version number
(encData-KeyVersNum) and ciphertext (encData-CipherText)
encryption of (the underlying BER-encoded bit-string of) a value of type
TicketEncryptPart, which is defined in
Part of Ticket to be Encrypted
[RFC 1510: 5.3.1]
Its fields are the following:
Options (represented by flag bits) selected by this ticket. The
TicketFlags data type is defined in detail in
The session key, KA,B, associated with this ticket; that is, the actual data item that represents the ensuing client-server session. (Either it or a subsequently negotiated conversation ("true session") key can be used to protect client-server communications.) Any principal that knows this session key is considered to be "the same principal (relative to this ticket)" as the principal A.
A's home cell, X.
A's RS name in RSX.
The transit path of this ticket.
The authentication time of this ticket; that is, the time of A's original (AS) authentication (the time at which A's home KDS server, KDSX, issued the original initial ticket-granting-ticket, TktA,KDSX, on which TktA,B is ultimately based, by a sequence of TGS Requests).
The start time of this ticket; that is, the time before which TktA,B is not to be honoured (accepted as evidence of authentication by B). Together with the expiration time of this ticket (tkt-ExpireTime), this field determines the lifetime of the ticket, namely, the time interval [tkt-StartTime, tkt-ExpireTime] (modulo maxClockSkew). This field must be present if TktA,B is postdated (tkt-Postdated flag is set), and it may be present at other (depending on local policy); in its absence, the start time of this ticket defaults to the ticket's authentication time (tkt-AuthnTime).
The (relative) expiration time of this ticket; that is, the time
after which TktA,B is not to be honoured by B.
Thus, the (relative) lifetime of the ticket is the time interval
[tkt-StartTime, tkt-ExpireTime] (modulo
maxClockSkew).
The absolute (or maximum) expiration time of this
ticket; that is, the time beyond
which KDS servers will not issue a renewed ticket based on
TktA,B. Thus,
the absolute (or maximum) lifetime of the ticket is
the time interval
[tkt-StartTime, tkt-MaxExpireTime] (modulo
maxClockSkew).
This field is present if and only if TktA,B's
tkt-Renewable flag is set, in which case it
must indicate a time later than tkt-ExpireTime;
in its absence, the absolute expiration time of this ticket defaults to the
ticket's expiration time (tkt-ExpireTime).
Zero (if absent) or more (if present) client host addresses. In the zero-address case, the ticket can be used from any "location" (that is, transport address-this is discussed further shortly); in the non-zero-address case, these are the addresses from which the ticket is "supposed" to be used (depending on server policy). In the RFC 1510 environment (as opposed to the DCE environment), this means the following:
In particular, the HostAddressType field(s) of the
HostAddresses data type (see
The authorisation data associated with this ticket. If it is not present, no authorisation data is associated with the ticket (and therefore a server relying on the presence of such data for its access decisions must deny access).
[RFC 1510: 2, 5.2, 5.3.1]
The semantics of these bits are that if a value of type TicketFlags has the corresponding bit set (to 1) then the option is selected; if the bit is reset (to 0), the option is deselected. The bits indicate the following options (bits not currently specified are reserved for future usage):
This TktA,B is forwardable; that is, this flag grants KDS servers the right to issue a forwarded Tkt*A,B (which may even be a ticket-granting-ticket) based on TktA,B. By a forwarded Tkt*A,B is meant a ticket that is used by the (same) client A from a (potentially) different "location" (host address, tkt-ClientAddrs) than A's "location" when TktA,B was originally issued. (Here, the notion of "same client A" is relative to a ticket, and it means any client that knows the session key carried in the ticket.)
This TktA,B has either itself been forwarded (see just above), or has been issued based on a ticket that had previously been forwarded.
This TktA,B is proxiable; that is, this flag grants KDS servers the right to issue a proxied Tkt*A,B (but not a ticket-granting-ticket -this is the only difference between forwarding and proxying from the point of view of the KDS, though applications may opt to distinguish between them for other purposes) based on TktA,B. By a proxied Tkt*A,B is meant a ticket that is used by the (same) client A from a (potentially) different host address (tkt-ClientAddrs) than that to which TktA,B was originally issued. (Here, the notion of "same client A" is relative to a ticket, and it means any client that knows the session key carried in the ticket.)
This TktA,B has either itself been proxied (see just above), or has been issued based on a ticket that had previously been proxied.
This TktA,B is postdatable; that is, this flag
grants KDS servers the right to issue a postdated
Tkt*A,B based on TktA,B.
By a postdated Tkt*A,B is meant a ticket that
has substantially the same information in it as
TktA,B but with a new start time
(tkt-StartTime).
This TktA,B has been postdated.
This TktA,B is invalid; that is, this flag
grants KDS servers the right to issue a valid
Tkt*A,B based on TktA,B.
By a valid (or validated) Tkt*A,B
is meant a ticket that has substantially the same information in it as
TktA,B but with its invalid option
(tkt-Invalid) deselected, with the semantic that target
(non-KDS) end-servers B are to honour only valid tickets.
This flag is used in conjunction with the tkt-Postdated flag.
This TktA,B is renewable;
that is, this flag grants KDS servers the right to issue a renewed
Tkt*A,B based on
TktA,B. By a renewed
Tkt*A,B is meant a ticket that has substantially
the same information in it as TktA,B but with a new
(later) expiration time (tkt-ExpireTime).
This TktA,B is an initial ticket; that is, it was issued in response to an AS Request to A's home KDSX. If tkt-Initial is reset, the ticket is said to be a subsequent ticket; that is, it was issued in response to a TGS Request to some KDS server.
Note that the above descriptions do not give complete details.
For that, see that detailed descriptions of these flags, in
[RFC 1510: 3.2.3, 5.3.2]
Its semantics are that it accompanies TktA,B in a
client-server service request, and proves to B that this request is
"really from A", in the sense that it was sent from A
"now" (modulo
maxClockSkew).
Its fields are the following:
The protocol version number of the Authenticator data type. Its
value is protoVersNum-KRB5.
A's home cell.
A's RS name in its cell.
The checksum of the (application-specific) message that this authenticator
accompanies. (This is used internally in the KDS protocol itself in the KDS
Request "application", as specified below.)
A's microsecondstamp, interpreted in conjunction with A's
timestamp (authnr-ClientTime, below).
The timestamp and microsecond timestamp pair,
<T, M> (= <authnr-ClientTime,
authnr-ClientMicroSec>), is used (differently) by clients and
servers as a nonce.
It is used by clients as a nonce to match up request/reply
(authentication header/reverse-authentication header) pairs
(see, for example,
A's timestamp when it generated this authenticator.
This timestamp (modulo
maxClockSkew)
has the semantics
of convincing the receiving server B that the communication it is
having with client A (securely identified in the accompanying
Tkt
A,B) is happening in real-time.
In colloquial terms: "A is `online' and is communicating with
B `now'."
A's choice of a conversation (or subsession or "true session") key, K^A,B, indicating that A prefers this key to be used to protect client-server communications. If absent, the session key KA,B in TktA,B (tkt-SessionKey) is to be used as the conversation key. This is part of conversation key negotiation between A and B.
A's choice of sequence number. If absent, this application is not using sequence numbers, or no sequence number is applicable to this message (for example, it might be a non-fragmented message).
Additional authorisation data included by A.
This is authorisation data additional to that specified in the
accompanying TktA,B (tkt-AuthzData). Note
that its contents are completely up to A's discretion, unlike the
tkt-AuthzData which is sealed in the ticket by the KDS server.
Therefore, even though its use depends on application-specific
authorisation policy, it is typically used only to "further restrict"
A's access rights at B; that is, it is typically used to
determine access in the manner paraphrased as: "If both
tkt-AuthzData and authnr-AuthzData grant access, then
access is granted, otherwise it is denied". Or in pseudocode:
[RFC 1510: 5.5.1]
Its semantics are that it supplies the forward authentication
information that actually "authenticates a client A to a
server B", by binding together an authenticator and a ticket,
TktA,B (naming A and targeted to B),
associated with one another. Its fields are the following:
The protocol version number of the AuthnHeader data type. Its
value is protoVersNum-KRB5.
The kind of protocol message this AuthnHeader represents. Its
value is protoMsgType-AUTHN-HEADER.
Selected authentication header options.
The AuthnHeaderFlags data type is defined in
The ticket, Tkt
A,B, associated
with the client-server session that this authentication header is
authenticating.
The encryption type (encData-EncType), key version number (encData-KeyVersNum) and ciphertext (encData-CipherText) encryption of (the underlying BER-encoded bit-string of) the authenticator (of type Authenticator) associated with the client-server session that this authentication header is authenticating. The "pre-encrypted" plaintext of this field (which is a value of the data type Authenticator) is denoted by authnHdr-EncryptAuthnr.
[RFC 1510: 5.2, 5.5.1]
The semantics of these bits are that if a value of type AuthnHeaderFlags has the corresponding bit set then the option is selected; if the bit is reset, the option is deselected. The bits represent the following options (bits not currently specified are reserved for future usage):
Usually (that is, if this option is deselected), TktA,B
is protected with B's long-term
key, KB. But if this option is selected, then the
TktA,B (authnHdr-Tkt) in this authentication
header is protected with a session key, K*,
carried in an auxiliary (ticket-granting-)ticket targeted to B,
Tkt*.
For more explanation, see
A expects B to return a reverse-authentication header
(of data type
RevAuthnHeader), thereby completing mutual authentication
by "authenticating the server to the client" (see
[RFC 1510: 3.2.3]
Recall (see
A,KDS
where TktA,B = {A, KA,B}KB. The main point to focus on for the purposes of this discussion is that TktA,B is protected with the long-term key KB of B. This requires, in order for B to be able to decrypt TktA,B, that B "knows" (has access to) its long-term key. But the requirement of having its long-term key readily accessible could be a risk for B, especially if the machine on which B runs is not physically secured (for example, a "public workstation").
The above protocol can be modified so that TktA,B
is replaced by another ticket,
Tkt*A,B, which is protected
with a short-term (session) key (whose compromise represents a
much smaller risk), K* = KB,KDS, as follows.
Suppose that A has obtained a copy of B's
(ticket-granting-)ticket, TktB,KDS,
(= {B, KB,KDS}KKDS);
note this is not a security risk to A or B,
and the manner of A's obtaining B's ticket need not be secure
-for example, B might have sent a copy of
TktB,KDS to A, or
B might have "published" its TktB,KDS
in a public place
(such as in a directory service datastore) and A retrieved a copy of it.
Then the required protocol can be achieved by:
A,KDS,
TktB,KDS
where TktB,KDS (also denoted "Tkt*", without subscripts, in this context) is an "additional ticket" (trusted by B) that conveys to the KDS (via the use-session-key option) the session key KB,KDS (also denoted "K*", without subscripts, in this context) that is used to protect Tkt*A,B; that is, Tkt*A,B = {A, KA,B}K*.
Reverse-Authentication Headers
[RFC 1510: 5.5.2]
Its semantics are that it supplies the reverse authentication information that actually "authenticates a server B to a client A", by extracting certain information from a corresponding authentication header (that the client trusts is only accessible by the legitimate server) and returning it (securely) to the client. Its fields are the following:
The protocol version number of the RevAuthnHeader data type. Its value is protoVersNum-KRB5.
The kind of protocol message this RevAuthnHeader represents. Its value is protoMsgType-REVAUTHN-HEADER.
The encryption type (encData-EncType), key version number
(encData-KeyVersNum) and ciphertext (encData-CipherText)
encryption of (the underlying BER-encoded bit-string of) a value of type
RevAuthnHeaderEncryptPart, which is defined in
[RFC 1510: 5.5.2]
Its fields are the following:
The corresponding authentication header's client timestamp (authnr-ClientTime).
The corresponding authentication header's client microsecondstamp
(authnr-ClientMicroSec).
B's choice of a conversation key, Kx^^'1xu'A,B, indicating that B prefers this key to be used to protect client-server communications instead of either the session key KA,B in the corresponding authentication header's TktA,B (tkt-SessionKey), or the client's choice of conversation key K^A,B (authnr-ConversationKey) if present, as part of conversation key negotiation between A and B.
B's indication of sequence number. It is equal to the authnr-SeqNum field of the corresponding authentication header (or is absent if that field was omitted).
[RFC 1510: 5.4.1]
Its semantics are to indicate a calling client A's request to a
KDS server KDSZ to return a
TktA,B targeted to a
server B (where B may be another KDS server,
KDSZ´).
KDS servers (such as KDSZ) support
requests for the following two distinct kinds of services:
(Re-)issue a ticket that has substantially previously existed, by
manipulating a presented ticket (in req-AuthnData).
(A rigorous definition is given in
Validate an (invalid) ticket.
Renew a (renewable) ticket.
Forward a (forwardable) (ticket-granting- or service-)ticket.
Proxy a (proxiable) (non-ticket-granting-)service-ticket.
Issue a ticket that hasn't substantially previously existed.
(A rigorous definition is given in
The fields of KDSRequest are the following:
The protocol version number of the KDSRequest data type. Its value is protoVersNum-KRB5.
The kind of protocol message this KDSRequest represents. If this is an AS Request, its value is protoMsgType-AS-REQUEST; if a TGS Request, it is protoMsgType-TGS-REQUEST.
This KDS Request's authentication data-it has different semantics depending on exactly what kind of KDS Request this is:
The body bgcolor="#FFFFFF" of this KDSRequest, of type
KDSRequestBody, which is defined in
[RFC 1510: 5.4.1]
Its fields are the following:
KDS options selected by this KDS Request (requested by the calling
client A, or interpreted by the KDS server KDSZ).
The KDSRequestFlags data type is defined in
A's RS name in its cell.
B's cell.
B's RS name in its cell.
A's desired start time for a new postdated ticket.
A's desired expiration time for a new ticket.
The particular value endOfTimeStamp (see
A's desired absolute expiration time for a new renewable ticket.
Nonce generated by A (to be returned in KDS Response, defined in
A list of A's preferences of encryption types to be used to protect a new ticket.
A's desired client host addresses for a new (potentially proxiable and/or forwardable) ticket.
The encryption type (encData-EncType), key version number
(encData-KeyVersNum) and ciphertext (encData-CipherText)
encryption of (the underlying BER-encoded bit-string of) a value of type
AuthzData. It is used to indicate A's request for authorisation
data. If this is an AS Request, it is not present. (See
Additional tickets, to be used in conjunction with this KDS Request's
selected KDS options (req-Flags) which require such additional
tickets. Each option that requires an additional ticket requires exactly one
such additional ticket, and the list req-AdditionalTkts is in
one-to-one
correspondence with such selected option(s), in the same order as the
ordinal number(s) of such selected option(s). Currently, there is only
one option that requires an additional ticket: the use-session-key option
(req-UseSessionKey), which requires a Tkt*
to carry the session key K* indicated by the option (see
[RFC 1510: 5.2, 5.4.1]
The semantics of these bits are that if a value of type KDSRequestFlags has the corresponding bit set then the option is selected; if the bit is reset, the option is deselected. The bits represent the following options (bits not currently specified are reserved for future usage):
New ticket is to be forwardable.
Old ticket is to be forwarded.
New ticket is to be proxiable.
Old ticket is to be proxied.
New ticket is to be postdatable.
New ticket is to be postdated.
New ticket is to be renewable.
New ticket is preferred to be non-renewable
and have A's desired maximum lifetime,
but if KDSZ declines to issue
such a ticket then A will accept a renewable ticket whose maximum
lifetime is as close as possible to (but not exceeding) the
desired maximum lifetime.
New ticket is to be protected with the session key
(tkt-SessionKey) of a presented additional ticket
(req-AdditionalTkts), instead of with B's long-term key.
In order to use this option, A must somehow acquire possession of an
appropriate additional ticket.
Internally (in the KDS protocols), this option is not used.
Old ticket is to be renewed.
Old ticket is to be validated.
[RFC 1510: 5.4.2]
Its semantics are to indicate the called KDSZ's response to a client A's request for a ticket. Its fields are the following:
The protocol version number of the KDSResponse data type. Its value is protoVersNum-KRB5.
The kind of protocol message this KDSResponse represents. If this is an AS Response, its value is protoMsgType-AS-RESPONSE; if a TGS Response, it is protoMsgType-TGS-RESPONSE.
This KDS Response's authentication data.
It is used to return information to A. (See
A's cell.
A's RS name in its cell.
The issued ticket.
If this is an AS Response, it is an initial ticket.
If this is a TGS Response, it is a subsequent ticket, and it is a
new or old ticket depending on the TGS Request options selected.
A KDS server KDSZ always returns a ticket whose named client
is the requested one (however in the case of an AS Request, which is
unauthenticated, the message itself could be modified in transit, so the
message A sends may not be the message KDSZ receives).
It also usually returns a ticket whose targeted server B is the
requested one, the only exception being in the case that B's home cell is
not Z, in which KDSZ returns a special cross-cell
referral ticket (see
The encryption type (encData-EncType), key version number
(encData-KeyVersNum) and ciphertext (encData-CipherText)
encryption of (the underlying BER-encoded bit-string of) a value of type
KDSResponseEncryptPart, which is defined in
[RFC 1510: 5.4.2]
Its fields are the following.
Note that most of this duplicates information that is present
in the enclosed TktA,B (resp-Tkt), so that
A can check its conformance to what it had requested in the
corresponding KDS Request (A cannot actually decrypt
TktA,B itself, unless A happens to know the
long-term key of the targeted server B).
(The only information in TktA,B that is not repeated in
KDSResponseEncryptPart are its transit path and authorisation data.)
Duplicate of resp-Tkt's session key (tkt-SessionKey).
Last request information that KDSX
(A's home KDS server) has pertaining to client A.
Typically only usefully present in an AS Response. It
is legal in a TGS Response (in fact, it's not an
optional field, though implementations typically
support a policy of returning only an empty
array of resp-LastRequests in TGS Responses),
and some implementations may indeed return last
request information in TGS Responses, but it's not
normally useful there-the last request
information is normally intended to be displayed to
the user, for example, at login-time, but most service-level
applications do not do that.
Copy of the corresponding KDS Request's nonce (req-Nonce).
The time at which A's long-term key KA
(of the selected encryption type, held in RSX)
is scheduled to expire; that is, later than which (modulo
maxClockSkew)
KDSX (A's home KDS server) will not use
it for protecting AS Responses and tickets targeted to A
(which are the only data KDS servers protect
with long-term keys). This supports principal long-term key management
(subject to local policy).
Typically only present in AS Responses, not TGS Responses.
Duplicate of resp-Tkt's ticket flags (tkt-Flags).
Duplicate of resp-Tkt's authentication
time (tkt-AuthnTime).
Duplicate of resp-Tkt's start time, if present
(tkt-StartTime).
Duplicate of resp-Tkt's expiration time
(tkt-ExpireTime).
Duplicate of resp-Tkt's absolute expiration time, if present
(tkt-MaxExpireTime).
B's cell.
B's RS name in its cell.
Duplicate of resp-Tkt's client host addresses, if present
(tkt-ClientAddrs).
KDS Errors
[RFC 1510: 5.9.1]
The protocol version number of this KDSError data type. Its value is protoVersNum-KRB5.
The kind of protocol message this KDSError represents. Its value is protoMsgType-KDS-ERROR.
A's timestamp from accompanying authenticator (authnHdr-EncryptAuthnr.authnr-ClientTime), if present. Otherwise, it is absent.
A's microsecondstamp from accompanying authenticator (authnHdr-EncryptAuthnr.authnr-ClientMicroSec), if present. Otherwise, it is absent.
C's system time at which the error occurred.
C's system microsecond time at which the error occurred.
Status code identifying the kind of error that occurred.
A's cell from accompanying ticket (tkt-EncryptPart.tkt-ClientCell), if present (not from accompanying authenticator, authnHdr-EncryptAuthnr.authnr-ClientCell, if present). Otherwise, it is absent.
A's RS name from accompanying ticket (tkt-EncryptPart.tkt-ClientName, if present (not from accompanying authenticator, authnHdr-EncryptAuthnr.authnr-ClientName, if present). Otherwise, it is absent.
C's cell.
C's RS name in its cell.
Status text associated to err-StatusCode.
Status data associated to err-StatusCode.
[RFC 1510: 4]
This cell's name.
RS name of the KDS server in this cell. If the cell name of this cell Z is, say, cellZ, then the RSZ name of KDSZ is krbtgt/cellZ.
The protocol version numbers supported by KDSZ {errStatusCode-BAD-PROTO-VERS-NUM}.
The authentication methods supported by KDSZ {errStatusCode-BAD-AUTHN-METHOD}.
The authentication data types supported by KDSZ {errStatusCode-AUTHN-DATA-TYPE-NOT-SUPPORTED}.
The transit path types supported by KDSZ {errStatusCode-TRANSIT-PATH-TYPE-NOT-SUPPORTED}.
The encryption key types supported by KDSZ.
The encryption types supported by KDSZ.
The checksum types supported by KDSZ {errStatusCode-CHECKSUM-TYPE-NOT-SUPPORTED, errStatusCode-BAD-CHECKSUM-TYPE}.
Entries for end-principals (that is, non-KDS-principals) stored in RSZ's datastore.
Entries for KDS principals KDSZ,Z´ from foreign cells Z´ cross-registered with cell Z. If the cell name of foreign cell Z´ is, say, cellZ´, then the RSZ name of KDSZ,Z´ is krbtgt/cellZ´ {errStatusCode-NOT-US}.
One (or more, as distinguished by their key version numbers) key(s) for each encryption type supported. "The" key (modulo its version number, and eliding the encryption type from the notation) for principal C and is denoted KC {errStatusCode-CLIENT-OLD-MASTER-KEY-VERS-NUM, errStatusCode-SERVER-OLD-MASTER-KEY-VERS-NUM, errStatusCode-NULL-KEY, errStatusCode-SERVER-NO-KEY, errStatusCode-BAD-KEY-VERS-NUM}.
Information used by principals to use in combination with their
passwords (which are not, in general, stored in the RS
datastore), in order to derive their long-term keys (see
Boolean indicating whether KDSZ will accept client-supplied (in authentication headers, authnHdr-EncryptAuthnr.authnr-ConversationKey) conversation keys be used to protect client-KDS sessions, or KDSZ will insist on supplying them itself (in reverse-authentication headers, revAuthnHdr-ConversationKey).
Value(s) (certainly a cell-value one, though
potentially also per-principal values) of
maxClockSkew
(see
The time later than which (modulo maxClockSkew) KDSZ will not use a principal's long-term key for protecting AS Responses and tickets targeted to C (which are the only data KDS servers protect with long-term keys).
Boolean indicating whether or not KDSZ will issue new postdatable or postdated tickets {errStatusCode-CANNOT-POSTDATE}.
Boolean indicating whether or not KDSZ will issue new renewable tickets.
Boolean indicating whether or not KDSZ will issue new proxiable tickets.
Boolean indicating whether or not KDSZ will issue new forwardable tickets.
Minimum lifetime for which KDSZ will issue a new ticket. (A ticket request that would result in a ticket with a lifetime less than this minimum will be rejected by the KDS.) {errStatusCode-NEVER-VALID}.
Default lifetime for which KDSZ will issue a new ticket-granting-ticket.
Maximum lifetime for which KDSZ will issue a new ticket.
Maximum lifetime for which KDSZ will issue a new ticket naming or targeting a principal C.
Furthest date in the future for which KDSZ will issue a
postdatable ticket naming or targeting a principal C.
Furthest date in the future for which KDSZ will issue a postdatable ticket.
Maximum lifetime for which KDSZ will issue a new renewable ticket (if it issues new renewable tickets at all).
Maximum lifetime for which KDSZ will issue a new renewable ticket naming or targeting a principal C (if it issues new renewable tickets at all).
Boolean indicating whether KDSZ requires client addresses (tkt-ClientAddrs) to be present in all tickets.
Last request(s) information maintained for C, per local policy.
Replay cache used by KDSZ (see
Information about (potentially) compromised entities (clients, servers, tickets, and so on), which have therefore been revoked (no longer supported by the security services). These entities comprise RSZ's hot list. For example, whenever a hot-listed (revoked) ticket is presented to KDSZ in (the req-AuthnData field of) a TGS Request, KDSZ will refuse to honour it. (Note that when a ticket's maximum expiration time has passed, KDSZ will not honour it under any circumstances, so there is no need to keep such tickets on the hot list.) {errStatusCode-CLIENT-REVOKED, errStatusCode-SERVER-REVOKED, errStatusCode-TKT-REVOKED}.
Information about what cell a client should visit next (among those cross-registered with Z) if the server requested by the client in a TGS Request is not registered in RSZ. There are various (policy-dependent) strategies for determining next hops. For example, some links may be more trusted than others, hence more suitable for some purposes than others.
[RFC 1510: 1, 3.1]
The details of the three steps of the success case are specified next.
(For the failure case, see
[RFC 1510: 3.1.1, A.1]
The protocol version number (asReq.req-ProtoVersNum) is set to
protoVersNum-KRB5.
The protocol message type (asReq.req-ProtoMsgType) is set to
protoMsgType-AS-REQUEST.
The client name (asReq.req-Body.req-ClientName) is set to
A's RS name in RSX.
The server cell (asReq.req-Body.req-ServerCell) is set to
KDSX's cell name; that is, to the name of
the cell X, say cellX.
This is also A's cell name-a KDS server can
issue initial tickets naming only clients in its own cell, and targeted
only to servers in its own cell.
The server name (asReq.req-Body.req-ServerName) is set to
B's RS name in its cell. (In the usual case of an AS Request for an
initial ticket-granting-ticket; that is, B = KDSX,
this RS name will be krbtgt/cellX,
assuming that the cell name is cellX).
If A desires that Tkt
A,B be forwardable, the
forwardable option (asReq.req-Body.req-Flags.req-Forwardable)
is selected.
If A desires that TktA,B be proxiable, the proxiable option (asReq.req-Body.req-Flags.req-Proxiable) is selected.
If A desires that TktA,B be postdatable, the postdatable option (asReq.req-Body.req-Flags.req-Postdatable) is selected.
If A desires that TktA,B be postdated, the postdate option (asReq.req-Body.req-Flags.req-Postdate) is selected.
If A desires that TktA,B be renewable, the renewable option (asReq.req-Body.req-Flags.req-Renewable) is selected.
If A does not desire that TktA,B be renewable, but A will nevertheless accept a renewable TktA,B with a shorter lifetime than desired in lieu of no TktA,B at all, then the renewable-okay option (asReq.req-Body.req-Flags.req-RenewableOK) is selected.
All of asReq's options that have not been selected by any of the above steps are deselected. Currently, these include the use-session-key (asReq.req-Body.req-Flags.req-UseSessionKey), validate (asReq.req-Body.req-Flags.req-Validate), renew (asReq.req-Body.req-Flags.req-Renew), proxy (asReq.req-Body.req-Flags.req-Proxy) and forward (asReq.req-Body.req-Flags.req-Forward) options.
If the postdate option for TktA,B has been selected, then the start time (asReq.req-Body.req-StartTime) is set to the desired starting time. Otherwise, the start time is omitted.
The expiration time (asReq.req-Body.req-ExpireTime) is set to the desired expiration time for TktA,B.
If the renewable option has been selected, then the maximum expiration time (asReq.req-Body.req-MaxExpireTime) is set to the desired maximum expiration time for TktA,B. Otherwise, the maximum expiration time is omitted.
The additional tickets field
(asReq.req-Body.req-AdditionalTkts) is omitted.
The nonce field (asReq.req-Body.req-Nonce) is set to a nonce value.
The encryption types field (asReq.req-Body.req-EncTypes)
is set to the list of encryption types acceptable to A
for protecting TktA,B.
A arranges this list in
priority order of desirability (from A's
point of view), beginning with the most
desirable and ending with the least desirable.
(For maximum interoperability, the client A should send a
list consisting of a single entry, indicating encryption type
encType-DES-CBC-CRC, since all KDS servers are required to
support clients requesting that single encryption type-
at least for the present revision of this document.)
If A desires that TktA,B contain client host addresses, then the client address field (asReq.req-Body.req-ClientAddrs) is set to the desired addresses. Otherwise, the client address field is omitted. In the present revision of DCE, clients must supply at least one address, or else the KDS will reject the AS Request.
The authorisation data field (asReq.req-Body.req-EncryptedAuthzData) is omitted.
The (pre-)authentication data (asReq.req-AuthnData) is (currently) omitted.
At this point, the asReq message is well-formed, and A sends it to KDSX.
[RFC 1510: 2.1, 3.1.2, 3.1.3, A.2]
The (pre-)authentication data (asReq.req-AuthnData)
is processed according to local policy (typically, it is absent).
The new initial ticket's protocol version number
(asTkt.tkt-ProtoVersNum) is set to protoVersNum-KRB5.
The requested server cell name (asReq.req-Body.req-ServerCell)
is checked to be X's cell name.
(This is because KDSX can issue initial tickets naming only
clients in its own cell, since it must have access to their long-term
key, with which it will protect asResp.)
The requested server name (asReq.req-Body.req-ServerName)
is checked to be KDSX's RS name.
KDSX copies this into the new initial ticket's
server name (asTkt.tkt-ServerName).
KDSX also checks that it itself has a datastore
entry in RSX
{errStatusCode-SERVER-UNKNOWN}.
The client cell (asTkt.tkt-EncryptPart.tkt-ClientCell)
is set to X's cell name (which must be A's cell name, too).
The requested client name (asReq.req-Body.req-ClientName)
(that is, A's RS name)
is checked to have a datastore entry in RSX
{errStatusCode-CLIENT-UNKNOWN}. KDSX
copies A's RS name into the new initial
ticket's client name (asTkt.tkt-EncryptPart.tkt-ClientName).
A thereby becomes the client named by the new initial ticket
Tkt
A,B.
KDSX selects from the list of requested encryption types (asReq.req-Body.req-EncTypes) the earliest one on the list that it is willing to accommodate (according to local policy)-call this encType. (Recall that the list had been generated in priority order of desirability, from A's point of view. For guaranteed interoperability, all KDS servers are required to support clients requesting the single encryption type enctype-DES-CBC-CRC-at least for the present revision of this document.) {errStatusCode-ENCRYPTION-TYPE-NOT-SUPPORTED}.
KDSX retrieves A's most recent long-term key KA (and its key version number, for the selected encryption type encType) from RSX.
KDSX generates a new (random) session key (of the selected encryption type, encType), KA,KDSX, and copies it into TktA,B's session key field (asTkt.tkt-EncryptPart.tkt-SessionKey).
TktA,B's authentication time (asTkt.tkt-EncryptPart.tkt-AuthnTime) is set to KDSX's system time.
If the requested start time (asReq.req-Body.req-StartTime) is absent, or if it indicates a time earlier than TktA,B's authentication time (asTkt.tkt-EncryptPart.tkt-AuthnTime), then TktA,B's start time (asTkt.tkt-EncryptPart.tkt-StartTime) is omitted (indicating a default to the authentication time). Otherwise (that is, a requested start time is present and indicates a time later than or equal to the authentication time), if the postdate option (asReq.req-Body.req-Flags.req-Postdate) is selected, then TktA,B's start time is set to the requested start time; if the postdate option is deselected, TktA,B's start time is omitted (indicating a default to the authentication time) or is set to KDSX's system time (see also the postdated and invalid options, below) {errStatusCode-POLICY}.
KDSX sets TktA,B's expiration
time (asTkt.tkt-EncryptPart.tkt-ExpireTime) to the
earliest of the following:
A,B's start time (or authentication time, if the
start time is absent) plus the maximum ticket lifetime associated with
the named client A.
KDSX checks that the resulting lifetime of TktA,B is greater than or equal to the cell-wide minimum ticket lifetime associated with the issuing authority KDSX {errStatusCode-NEVER-VALID}.
If either the renewable option
(asReq.req-Body.req-Flags.req-Renewable) has been selected,
or if the renewable-okay option
(asReq.req-Body.req-Flags.req-RenewableOK) has been selected
and TktA,B's expiration time is earlier than the
requested expiration time, then TktA,B's maximum
expiration time (asTkt.tkt-EncryptPart.tkt-MaxExpireTime) is
present (otherwise it is omitted) and is set to the earliest of:
A,B's start time (or authentication time, if the
start time is absent) plus the maximum renewable ticket lifetime
associated with the named client A.
TktA,B's transit path (asTkt.tkt-EncryptPart.tkt-TransitPath) is omitted.
TktA,B's client address field (asTkt.tkt-EncryptPart.tkt-ClientAddrs) is set to the requested client addresses (asReq.req-Body.req-ClientAddrs), if present. (In particular, no attempt is made to check that this AS Request originated from one of the requested client addresses, if present.) Otherwise, it is omitted. In the present revision of DCE, at least one client address must be supplied by the client, otherwise the KDS will fail the AS Request.
KDSX checks that the requested authorisation data asReq.req-Body.req-EncryptedAuthzData) is omitted. (Since the AS Request is unauthenticated, KDSX cannot vouch for such authorisation data.) TktA,B's authorisation data field (asTkt.tkt-EncryptPart.tkt-AuthzData) is omitted.
KDSX checks that no additional tickets (asReq.req-Body.req-AdditionalTkts) are present.
If the forwardable option (asReq.req-Body.req-Flags.req-Forwardable) has been requested and if forwardability is permitted by KDSX, then TktA,B's forwardable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwardable) is selected.
If the Proxiable option (asReq.req-Body.req-Flags.req-Proxiable) has been requested and if proxiability is permitted by KDSX, and if B != KDSX, then TktA,B's proxiable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxiable) is selected. (If B = KDSX, then this AS request is denied, because ticket-granting-tickets are not proxiable.)
If the postdatable option (asReq.req-Body.req-Flags.req-Postdatable) has been requested and if postdatability is permitted by KDSX, then TktA,B's postdatable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdatable) is selected.
If TktA,B's start time is present, then TktA,B's postdated option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdated) is selected.
If TktA,B's postdated option is selected (above), then TktA,B's invalid option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid) is selected.
If TktA,B's maximum expiration time is present and if renewability is permitted by KDSX, then TktA,B's renewable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable) is selected.
KDSX checks that no other KDS options have been requested. Currently, these are the use-session-key (asReq.req-Body.req-Flags.req-UseSessionKey), validate (asReq.req-Body.req-Flags.req-Validate), renew (asReq.req-Body.req-Flags.req-Renew), proxy (asReq.req-Body.req-Flags.req-Proxy) and forward (asReq.req-Body.req-Flags.req-Forward) options {errStatusCode-BAD-OPTION}.
TktA,B's initial option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Initial) is selected. (This marks TktA,B as an initial ticket.)
All of TktA,B's options that have not been selected by any of the above steps are deselected. Additionally, the forwarded (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwarded) and proxied (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxied) options are deselected.
KDSX encrypts asTkt.tkt-EncryptPart using KDSX's long-term key KKDSX (of the chosen encryption type encType, and key version number). This is the ciphertext portion of TktA,B (asTkt.tkt-EncryptedPart.encData-CipherText). KDSX also sets the encryption type (asTkt.tkt-EncryptedPart.encData-EncType) to encType and the key version number (asTkt.tkt-EncryptedPart.encData-KeyVersNum) to KKDSX's version number.
At this point, TktA,B is well-formed,
and KDSX turns its attention to completing the
construction of the AS Response message, asResp.
The protocol version number (asResp.resp-ProtoVersNum) is set
to protoVersNum-KRB5.
The protocol message type (asResp.resp-ProtoMsgType) is set to
protoMsgType-AS-RESPONSE.
The authentication data (asResp.resp-AuthnData) is either
omitted, or it consists of a single element
(asResp.resp-AuthnData[0]); in the latter case, the type
(asResp.resp-AuthnData[0].authnData-Type) is
authnDataType-PW-SALT and the value
(asResp.resp-AuthnData[0].authnData-Value) is the
salt to be used by the client to derive its long-term key (via
the algorithm of
The client cell (asResp.resp-ClientCell) is set to
Tkt
A,B's client cell
(asTkt.tkt-EncryptPart.tkt-ClientCell).
The client name (asResp.resp-ClientName) is set to TktA,B's client name (asTkt.tkt-EncryptPart.tkt-ClientName).
The ticket (asResp.resp-Tkt) is set to the newly created TktA,B (asTkt).
The session key (asResp.resp-EncryptPart.resp-SessionKey) is set to TktA,B's session key, KA,KDSX (asTkt.tkt-EncryptPart.tkt-SessionKey).
The nonce (asResp.resp-EncryptPart.resp-Nonce) is set to the nonce that the calling client sent (asReq.req-Body.req-Nonce).
The client address field (asResp.resp-EncryptPart.resp-ClientAddrs) is set to TktA,B's client address field (asTkt.tkt-EncryptPart.tkt-ClientAddrs), if present. Otherwise, it is omitted.
The server cell (asResp.resp-EncryptPart.resp-ServerCell) is set to TktA,B's server cell (asTkt.tkt-ServerCell).
The server name (asResp.resp-EncryptPart.resp-ServerName) is set to TktA,B's server name (asTkt.tkt-ServerName).
The authentication time (asResp.resp-EncryptPart.resp-AuthnTime) is set to TktA,B's authentication time (asTkt.tkt-EncryptPart.tkt-AuthnTime).
The start time (asResp.resp-EncryptPart.resp-StartTime) is set to TktA,B's start time (asTkt.tkt-EncryptPart.tkt-StartTime), if present. Otherwise, it is omitted.
The expiration time (asResp.resp-EncryptPart.resp-ExpireTime)
is set to TktA,B's expiration time
(asTkt.tkt-EncryptPart.tkt-ExpireTime).
The maximum expiration time (asResp.resp-EncryptPart.resp-MaxExpireTime) is set to TktA,B's maximum expiration time (asTkt.tkt-EncryptPart.tkt-MaxExpireTime), if present. Otherwise, it is omitted.
The key expiration date (asResp.resp-EncryptPart.resp-KeyExpireDate) is set to the expiration date of A's long-term key (of the selected encryption type and key version number), KA.
The last requests field (asResp.resp-EncryptPart.resp-LastRequests) is set to A's last requests information.
The options (asResp.resp-EncryptPart.resp-Flags) are set to TktA,B's options (asTkt.tkt-EncryptPart.tkt-Flags).
KDSX encrypts asResp.resp-EncryptPart using A's long-term key KA (using the chosen encryption type encType). This is the ciphertext portion of the AS Response (asResp.resp-EncryptedPart.encData-CipherText). KDSX also sets the encryption type (asResp.resp-EncryptedPart.encData-EncType) to encType and the key version number (asResp.resp-EncryptedPart.encData-KeyVersNum) to the version number of the client's long-term key.
At this point, the KDS Response is well-formed, and KDSX returns it to the calling client.
[RFC 1510: 3.1.5, A.3, A.4]
The named client's cell (asResp.resp-ClientCell) is
checked for conformance to A's cell name (which A had implicitly
sent (asReq.req-Body.req-ServerCell),
by sending its AS Request to KDSX).
The client name (asResp.resp-ClientName) is
checked for conformance to what A requested
(asReq.req-Body.req-ClientName); that is, to A's RS name.
The authentication data (asResp.resp-AuthnData), if
present, is scanned for its least element (that is, the minimal i)
for which the type
(asResp.resp-AuthnData[i].authnData-Type) is
authnDataType-PW-SALT, and then the client derives its
long-term key, KA, from its password and the included salt
(asResp.resp-AuthnData[i].authnData-Value) (see
Tkt
A,B (asTkt, asResp.resp-Tkt) is
not directly interpretable (in the sense of being decryptable) by A,
but the information in it is largely available elsewhere in asResp.
The encryption type, encType
(asResp.resp-EncryptedPart.encData-EncType), is checked for
conformance to what A had requested
(asReq.req-Body.req-EncTypes). If it is acceptable,
then A attempts to decrypt the ciphertext portion of the AS Response
(asResp.resp-EncryptedPart.encData-CipherText), using its
long-term key KA
(which A must know or derive; for example,
from its password and salt as described above), of encryption
type encType and the indicated key version number
(asResp.resp-EncryptedPart.encData-KeyVersNum).
A successful decryption is recognised by the built-in
integrity afforded by the ciphertext itself.
In this way, A learns the information carried in
asResp.resp-EncryptPart.
If A encounters an unsuccessful decryption, it takes
application-specific action-this presumably includes rejection of
asResp as untrustworthy (the ability to successfully decrypt
asResp.resp-EncryptedPart proves to A that it was
encrypted by the legitimate KDSX
(since A trusts its long-term
key KA to be secure), and
that it is not being spoofed by a counterfeit KDSX).
In particular, if A is not the client requested in
asResp (and named in asTkt), in the sense of not knowing
the correct long-term key of that client, then A will not be able to
successfully decrypt asResp, and consequently will not be able to
gain access to the information in asResp.resp-EncryptPart (in
particular, its session key, KA,KDSX
(asResp.resp-EncryptPart.resp-SessionKey)).
A,B". In order for arbitrary
other parties (other than A) to become convinced of the genuineness of
TktA,B, the subtler protocols involved in
"certification of TktA,B" (see
The nonce (asResp.resp-EncryptPart.resp-Nonce) is checked for equality with the requested nonce (asReq.req-Body.req-Nonce). If it is not equal, then this asResp does not correspond to asReq, and a "replay attack" may be suspected, and A takes application-specific action.
The last requests (asResp.resp-EncryptPart.resp-LastRequests) are inspected. If they do not match A's own knowledge of its previous requests, then a potential breach of security may be suspected, and A typically invokes recovery measures consistent with local policy.
The key expiration date
(asResp.resp-EncryptPart.resp-KeyExpireDate) is inspected if
present. If it indicates a date in the "near" future, then A should
invoke key update procedures according to local policy (see
The server cell (asResp.resp-EncryptPart.resp-ServerCell) is checked for conformance to what A requested (asReq.req-Body.req-ServerCell); that is, to KDSX's cell name, or to X's cell name.
The server name (asResp.resp-EncryptPart.resp-ServerName) is checked for conformance to what A requested (asReq.req-Body.req-ServerName); that is, to KDSX's RS name.
The session key (which A trusts is secure), KA,KDSX (asResp.resp-EncryptPart.resp-SessionKey), is saved for later use in protecting communications with KDSX; that is, subsequent TGS Requests.
The authentication time (asResp.resp-EncryptPart.resp-AuthnTime) is checked for conformance to what A expects (typically, it should be equal to A's system time (modulo maxClockSkew)).
The start time (asResp.resp-EncryptPart.resp-StartTime) is checked for conformance to what A requested. Namely, if A requested TktA,B to be postdated, then the start time is checked to be present and checked for conformance to the start time A requested (asReq.req-Body.req-StartTime); otherwise, the start time should be absent.
The expiration time (asResp.resp-EncryptPart.resp-ExpireTime) is checked for conformance to what A requested (asReq.req-Body.req-ExpireTime).
The maximum expiration time
(asResp.resp-EncryptPart.resp-MaxExpireTime) is
checked for conformance to what A requested. It should be only
present (at most) if A had selected the renewable option
(asReq.req-Body.req-Flags.req-Renewable) and supplied a
requested maximum expiration time
(asReq.req-Body.req-MaxExpireTime), or if A had
selected the renewable-okay option
(asReq.req-Body.req-Flags.req-RenewableOK).
If A requested that TktA,B contain client host addresses, then the client address field (asResp.resp-EncryptPart.resp-ClientAddrs) is checked to be present and checked for conformance to what A requested (asReq.req-Body.req-ClientAddrs). Otherwise, the client addresses should be absent.
The options field (asResp.resp-EncryptPart.resp-Flags) is inspected for conformance to what A requested (asReq.req-Body.req-Flags).
This completes the specification of the AS Request/Response exchange.
[RFC 1510: 1, 3.2.1]
The details of the three steps of the success case are specified next.
Note that it is A's responsibility to know (or to securely determine) all the information necessary to correctly formulate its message to B-especially, B's cell name and RS name.
[RFC 1510: 3.2.2, A.9]
The following algorithm first discusses how A constructs the newly generated authenticator, authnr, and then how it constructs the rest of the authentication header, authnHdr.
The protocol version number (authnr.authnr-ProtoVersNum) is set to protoVersNum-KRB5.
The client cell (authnr.authnr-ClientCell) is set to A's cell name; that is, to X's cell name.
The client name (authnr.authnr-ClientName) is set to A's RS name.
The client timestamp (authnr.authnr-ClientTime) is set to A's system time.
The client microsecond stamp (authnr.authnr-ClientMicroSec) is set to A's system microsecond time.
If A desires to use a conversation key of its own choosing, say K^A,B (of the same encryption type, encType), instead of the KDSY-generated session key KA,B, to protect this client-server session, then it sets the conversation key (authnr.authnr-ConversationKey) to K^A,B. Otherwise this field is omitted. (The keys KA,B, K^A,B and Kx^^`1xu`A,B all have the same encryption type, encType.)
If this application uses checksums, then
A uses an application-specific checksum type
(authnr.authnr-Cksum.cksum-Type) to set the checksum
value (authnr.authnr-Cksum.cksum-Value) to the checksum of some
application-specific plaintext (typically, this will be the checksum of
the "service" portion of the message that this authenticator is
authenticating).
Otherwise the checksum is omitted. (In the case of DCE RPC
applications, the use of checksums is specified as part of the RPC
protocol specifications-see
The sequence number (authnr.authnr-SeqNum) is processed in an application-specific manner (perhaps omitting it).
If this application uses additional authorisation data, then A sets the authorisation data field (authnr.authnr-AuthzData) to application-specific additional authorisation data. Otherwise, this field is omitted.
A encrypts authnr, using the encryption type encType and the session key KA,B (not the conversation key K^A,B, even if present) in the accompanying TktA,B. This is the ciphertext portion of the authentication header (authnHdr.authnHdr-EncryptedAuthnr.encData-CipherText). A also sets the encryption type (authnHdr.authnHdr-EncryptedAuthnr.encData-EncType) to encType and the key version number (authnHdr.authnHdr-EncryptedAuthnr.encData-KeyVersNum) to an appropriate application-specific value, if any (usually it is omitted).
At this point, authnr is well-formed and encrypted, and A turns its attention to completing the construction of the authentication header, authnHdr.
The protocol version number (authnHdr.authnHdr-ProtoVersNum) is set to protoVersNum-KRB5.
The protocol message type (authnHdr.authnHdr-ProtoMsgType) is set to protoMsgType-AUTHN-HEADER.
The ticket (authnHdr.authnHdr-Tkt) is set to TktA,B (kdsTkt).
The encrypted authenticator (authnHdr.authnHdr-EncryptedAuthnr) is set to the encryption of authnr as constructed above.
If the accompanying TktA,B (kdsTkt,
authnHdr.authnHdr-Tkt), is protected with a session key,
K* (carried in a (ticket-granting-)ticket targeted to
B), instead of with B's long-term key KB,
then the use-session-key option
(authnHdr.authnHdr-Flags.authnHdr-UseSessionKey) is selected
(see
If A desires that B return a reverse-authentication header with its response, the mutual authentication option (authnHdr.authnHdr-Flags.authnHdr-MutualRequired) is selected.
All of authnHdr's options that have not been selected by any of the above steps are deselected (unless they are used in application-specific ways). Currently, there are no other options that haven't already been mentioned above.
At this point, authnHdr is well-formed, and A sends it to B.
[RFC 1510: 3.2.3, 3.2.4, A.10, A.11]
The following algorithm first discusses how B processes authnHdr, and then, if the mutual authentication option (authnHdr.authnHdr-Flags.authnHdr-MutualRequired) has been selected, how B constructs a reverse-authentication header, revAuthnHdr (of type RevAuthnHeader), to return to A.
If the use-session-key option
(authnHdr.authnHdr-Flags.authnHdr-UseSessionKey) is deselected,
B knows that ahTkt is protected with its long-term
key KB.
If it is selected, B knows that ahTkt is protected with a
session key, K* (see
If the mutual authentication option (authnHdr.authnHdr-Flags.authnHdr-MutualRequired) is selected, B knows A expects a reverse-authentication header to be returned.
The protocol version number (ahTkt.tkt-ProtoVersNum) is checked to be protoVersNum-KRB5.
The server cell (ahTkt.tkt-ServerCell) is checked to be the name of B's cell; that is, Y's cell name.
The server name (ahTkt.tkt-ServerName) is checked to be B's RS name.
The encryption type protecting TktA,B, encType (ahTkt.tkt-EncryptedPart.encData-EncType), is checked for support by B, as is the key version number (ahTkt.tkt-EncryptedPart.encData-KeyVersNum) if present. If the use-session-key option is deselected, B uses its long-term key KB to attempt to decrypt TktA,B's ciphertext (ahTkt.tkt-EncryptedPart.encData-CipherText); otherwise, B uses the session key, K*. A successful decryption is recognised by the built-in integrity afforded by the ciphertext itself. In this way, B learns the information carried in TktA,B, in particular its session key KA,B (ahTkt.tkt-EncryptPart.tkt-SessionKey).
The encryption type protecting the authenticator (authnHdr.authnHdr-EncryptedAuthnr.encData-EncType) is checked to be the same as that protecting TktA,B, namely encType. B decrypts the authenticator's ciphertext (authnHdr.authnHdr-EncryptedAuthnr.encData-CipherText) using the session key KA,B (not K*, even if the use-session-key option is selected). The key version number (authnHdr.authnHdr-EncryptedAuthnr.encData-KeyVersNum), if present, is processed in an application-specific way (usually, it is omitted). A successful decryption is recognised by the built-in integrity afforded by the ciphertext itself-this is what convinces B that A knows the session key KA,B; that is, this is what actually "authenticates" A to B. In this way, B learns the information carried in authnr (authnHdr.authnHdr-EncryptAuthnr).
The authenticator's protocol version number (authnr.authnr-ProtoVersNum) is checked to be protoVersNum-KRB5.
The client cells from ahTkt (ahTkt.tkt-EncryptPart.tkt-ClientCell) and from authnr (authnr.authnr-ClientCell) are checked to be the same (namely, to A's cell name; that is, X's cell name).
The client names from ahTkt (ahTkt.tkt-EncryptPart.tkt-ClientName) and from authnr (authnr.authnr-ClientName) are checked to be the same (namely, to A's RS name).
If there are client addresses present in ahTkt (ahTkt.tkt-EncryptPart.tkt-ClientAddrs) and if B requires that client addresses be used, then B checks that A is communicating from one of them (as reported by B's operating system, according to the level of trust B places in that); that is, that authnHdr was received from one of the addresses on the list.
A's timestamp (authnr.authnr-ClientTime) is checked to be equal to B's system time (modulo maxClockSkew). It is in this way that B becomes convinced that it is communicating with A in real-time.
A's microsecondstamp (authnr.authnr-ClientMicroSec), together with its timestamp, are checked to not be present in B's replay cache. They are then stored in the replay cache.
The authentication time
(ahTkt.tkt-EncryptPart.tkt-AuthnTime) is typically ignored by
application-level servers (see
The start time (ahTkt.tkt-EncryptPart.tkt-StartTime)
is checked to be earlier than or equal to B's system time (modulo
maxClockSkew).
The expiration time (ahTkt.tkt-EncryptPart.tkt-ExpireTime) is checked to be later than or equal to B's system time (modulo maxClockSkew).
The maximum expiration time
(ahTkt.tkt-EncryptPart.tkt-MaxExpireTime)
is typically ignored by application-level servers (see
The sequence number (authnr.authnr-SeqNum) is processed in an application-specific manner.
If a conversation key K^A,B (authnr.authnr-ConversationKey) is present, B decides (in an application-specific way) whether it will use it to protect this client-server session, or if it will use ahTkt's session key KA,B or will generate its own conversation key Kx^^'1xu'A,B for this purpose (informing A of it in the accompanying revAuthnHdr).
The transit path (ahTkt.tkt-EncryptPart.tkt-TransitPath)
is typically ignored by application-level servers (see
If a checksum (authnr.authnr-Cksum) is present, it is processed in an application-specific way.
The invalid option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid)
is typically checked by application-level servers to be deselected (see
All other options are ignored by application-level servers (see
If ticket authorisation data (ahTkt.tkt-EncryptPart.tkt-AuthzData) is present, B uses it (in an application-specific way) to make authorisation decisions.
If additional authenticator authorisation data (authnr.authnr-AuthzData) is present, B uses it (in an application-specific way) to make authorisation decisions.
The protocol version number (revAuthnHdr.revAuthnHdr-ProtoVersNum) is set to protoVersNum-KRB5.
The protocol message type (revAuthnHdr.revAuthnHdr-ProtoMsgType) is set to protoMsgType-REVAUTHN-HEADER.
The client timestamp (revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-ClientTime) is set to the timestamp A sent in its authentication header (authnr.authnr-ClientTime).
The client microsecondstamp (revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-ClientMicroSec) is set to the microsecondstamp A sent in its authentication header (authnr.authnr-ClientMicroSec).
If B wants to protect the current client-server session with a key of its own choosing, instead of either the KDSY-generated session key (KA,B) or the A-generated conversation key (K^A,B) if present, then B generates a conversation key Kx^^'1xu'A,B (of the same encryption type, encType) and returns it in the conversation key field (revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-ConversationKey). Otherwise, it is omitted.
The sequence number (revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-SeqNum) is processed in an application-specific manner (perhaps omitting it).
B encrypts revAuthnHdr.revAuthnHdr-EncryptPart, using the encryption type encType and session key KA,B (not K^A,B or Kx^^'1xu'A,B, even if they exist) specified by the authentication header authnHdr. This is the ciphertext portion of the reverse-authentication header (revAuthnHdr.revAuthnHdr-EncryptedPart.encData-CipherText). B also sets the encryption type (revAuthnHdr.revAuthnHdr-EncryptedPart.encData-EncType) to encType and the key version number (revAuthnHdr.revAuthnHdr-EncryptedPart.encData-KeyVersNum) to an appropriate application-specific value.
At this point, the revAuthnHdr is well-formed, and B returns it to the calling client.
[RFC 1510: 3.2.5, A.12]
The encryption type of the reverse-authentication header, encType
(revAuthnHdr.revAuthnHdr-EncryptedPart.encData-EncType), is
checked for conformance for what A had requested
(authnHdr.authnHdr-Tkt.tkt-EncryptedPart.encData-EncType).
If it is acceptable,
A then attempts to decrypt the ciphertext portion of the
reverse-authentication header
(revAuthnHdr.revAuthnHdr-EncryptedPart.encData-CipherText),
using the session key K
A,B
(authnHdr.authnHdr-Tkt.tkt-EncryptPart.tkt-SessionKey)
of encryption type encType and key version number
authnHdr.authnHdr-EncryptedPart.encData-KeyVersNum if present
(not K^A,B or
Kx^^'1xu'A,B, even if these exist).
A successful decryption is recognised by the built-in
integrity afforded by the ciphertext itself.
If A encounters an "unsuccessful" decryption, it takes
application-specific action-this presumably includes rejection of
revAuthnHdr as untrustworthy.
The client timestamp (revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-ClientTime) is checked for conformance with the client timestamp that A had sent B (authnHdr.authnHdr-EncryptPart.authnr-ClientTime).
The client microsecondstamp (revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-ClientMicroSec) is checked for conformance with the client microsecondestamp that A had sent to B (authnHdr.authnHdr-EncryptPart.authnr-ClientMicroSec). It is this step and the previous one that convince A it is securely communicating with B ("now").
If a conversation key Kx^^'1xu'A,B
(revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-ConversationKey)
is present, A processes it in an application-specific way
(typically, it is used to protect this client-server session).
The sequence number (revAuthnHdr.revAuthnHdr-EncryptPart.revAuthnHdr-SeqNum) is processed in an application-specific manner.
This completes the specification of the Authentication/Reverse-authentication Header exchange.
[RFC 1510: 1, 3.3]
The details of the three steps of the success case are specified next.
[RFC 1510: 3.3.1, A.5]
A,···,B =
TktA,X,···,W,Y,B
As always, TktA,···,B is one of two kinds
of ticket, depending on the kind of server (B) it is targeted to:
A,···,B may be a service-ticket, in
which case B is a non-KDS server.
Since TktA,···,B names A, A knows the contents of TktA,···,B, especially its session key, which is denoted KA,B (which is of the same encryption type, encType, as is used to protect TktA,···,B). Note that the key KA,B can always be used as a session key between A and KDSY (even though it is nominally only a session key between A and B, with possibly B != KDSY). This is because TktA,···,B is protected in the long-term key of B, which KDSY knows, so KDSY has access to KA,B too.
What A wants to do is "present"
TktA,···,B
to KDSY, and receive in return another ticket,
which is denoted:
A,···,B*
which is "based on TktA,···,B",
naming A, and targeted to another (perhaps the same) server B* in
Y. That is, A wants to send to KDSY
a TGS Request tgsReq (a value of the data type
TGSRequest) containing TktA,···,B
(ahTkt, in its tgsReq.req-AuthnData field,
as the authnHdr.authnHdr-Tkt field of an authentication header
authnHdr), and receive in response a TGS Response tgsResp
(a value of data type TGSResponse) containing
Tkt*A,···,B* (tgsTkt, in its
tgsResp.resp-Tkt field).
A prepares tgsReq according to the algorithm below and
"sends it" (that is, calls
There are two distinct cases to consider throughout, according to what kind of service A requests:
Tkt*
Tkt*A,···,B* will be a "new" ticket targeted to another KDS server B* = KDSY,Z (Z != W) which is (cross-)registered with Y.
The protocol version number (tgsReq.req-ProtoVersNum) is set to protoVersNum-KRB5.
The protocol message type (tgsReq.req-ProtoMsgType) is set to protoMsgType-TGS-REQUEST.
The client name (tgsReq.req-Body.req-ClientName) is set to A's RS name in RSX.
The server cell (tgsReq.req-Body.req-ServerCell) is set to the cell name of the ultimate end-server that A desires Tkt*A,···,B* to be targeted to. (If this is a request for a manipulated old Tkt*A,···,B*, this ultimate server cell name is the same as TktA,···,B's targeted server's cell name (ahTkt.tkt-ServerCell); that is, Y's cell name.)
The server name (tgsReq.req-Body.req-ServerName) is set to the RS name of the ultimate server that A desires Tkt*A,···,B* to be targeted to. (If this is a request for a manipulated old Tkt*A,···,B*, this ultimate server RS name is the same as TktA,···,B's targeted server's RS name (ahTkt.tkt-ServerName), which must exist in RSY.)
If it is desired that a newly issued ticket be forwardable, the forwardable option (tgsReq.req-Body.req-Flags.req-Forwardable) is selected.
If it is desired that a newly issued ticket (which must be a service-ticket, not a ticket-granting-ticket) be proxiable, the proxiable option (tgsReq.req-Body.req-Flags.req-Proxiable) is selected.
If it is desired that a newly issued ticket be postdatable, the postdatable option (tgsReq.req-Body.req-Flags.req-Postdatable) is selected.
If it is desired that a newly issued ticket be postdated, the postdate option (tgsReq.req-Body.req-Flags.req-Postdate) is selected.
If it is desired that a newly issued ticket be renewable, the renewable option (tgsReq.req-Body.req-Flags.req-Renewable) is selected.
If it is not desired that a newly issued ticket be renewable but A will nevertheless accept a renewable ticket with a shorter lifetime than desired in lieu of no ticket at all, then the renewable-okay option (tgsReq.req-Body.req-Flags.req-RenewableOK) is selected.
The use-session-key option (tgsReq.req-Body.req-Flags.req-UseSessionKey) is deselected.
If it is desired that an old ticket be validated, the validate option (tgsReq.req-Body.req-Flags.req-Validate) is selected.
If it is desired that an old ticket be renewed, the renew option (tgsReq.req-Body.req-Flags.req-Renew) is selected.
If it is desired that an old ticket (which must be a service-ticket, not a ticket-granting-ticket) be proxied, the proxy option (tgsReq.req-Body.req-Flags.req-Proxy) is selected.
If it is desired that an old ticket be forwarded, the forward option (tgsReq.req-Body.req-Flags.req-Forward) is selected.
If the postdate option has been selected, then the start time (tgsReq.req-Body.req-StartTime) is set to the desired starting time. Otherwise, the start time is omitted.
The expiration time (tgsReq.req-Body.req-ExpireTime) is set to the desired expiration time. (In the case of a request to manipulate an old ticket, this can be used to "clip" the lifetime of the manipulated ticket to a shorter time.)
If the renewable option has been selected, then the maximum expiration time (tgsReq.req-Body.req-MaxExpireTime) is set to the desired maximum expiration time. (In the case of a request to manipulate an old ticket, this can be used to "clip" the lifetime of the manipulated ticket to a shorter maximum time.) Otherwise, the maximum expiration time is omitted.
The additional tickets field (tgsReq.req-Body.req-AdditionalTkts) is omitted. (The only option that currently requires an additional ticket is the use-session-key option, and that option is deselected in TGS Requests.)
The nonce field (asReq.req-Body.req-Nonce) is set to a nonce value.
The encryption types field (tgsReq.req-Body.req-EncTypes) is set to the list of encryption types acceptable to A for protecting a newly issued ticket. The list is arranged in priority order of desirability, beginning with most desirable and ending with least desirable. (For maximum interoperability, the client A should send a list consisting of a single entry, indicating the same encryption type, encType, as that used to protect the presented ticket TktA,···,B. It is to be presumed that if this TGS request is a request for a manipulated old ticket, the resulting manipulated ticket will be re-encrypted in the newly chosen encryption type if it is different from encType-however, that is not apparent from RFC 1510.)
If A desires that a newly issued ticket contain client host addresses, then the client address field (tgsReq.req-Body.req-ClientAddrs) is set to the desired addresses. Otherwise, the client address field is omitted. (If this is a request to manipulate an old ticket, these addresses will only be used in the manipulated ticket if the old ticket is forwarded or proxied; otherwise, the client addresses in the ticket authenticating this request-see the bullet on authentication data, below-will be used.)
If A desires that a newly issued ticket
contain authorisation data supplied by A, such data (a value of type
AuthzData) is encrypted
using the encryption type encType and
using the conversation key K^A,B
(authnr.authnr-ConversationKey, see below) if present,
otherwise using the session key KA,B,
and the authorisation data field
(tgsReq.req-Body.req-EncryptedAuthzData)
is then set to the resulting encrypted value (a value of type
EncryptedData). Otherwise this field is omitted.
(Typically, it is omitted, an exception being where A is a
privilege server PSX, requesting a
privilege-(ticket-granting-)ticket from KDSX (in the case
where PSX and KDSX are not co-located, so
that an message must be transmitted)-see
The first entry (tgsReq.req-AuthnData[0]) in the list
(tgsReq.req-AuthnData)
of authentication data items is set to have authentication data type
(tgsReq.req-AuthnData[0].authnData-Type)
authnDataType-TGS-REQ, and its authentication data value
(tgsReq.req-AuthnData[0].authnData-Value) is set to
(the underlying OCTET STRING of) an authentication header,
authnHdr, that A constructs, based on
TktA,···,B
(authnHdr.authnHdr-Tkt).
The construction of authnHdr proceeds as in
The conversation key field (authnr.authnr-ConversationKey) is set
to a newly generated conversation key, K^
A,B
(of the same encryption key type, encType),
if A desires such a key to be used (instead of
KA,B) to protect this client-server session
(between A and KDSY). (If authorisation data
(tgsReq.req-Body.req-EncryptedAuthzData)
and K^A,B are both present, note that
K^A,B had to be generated earlier in order to be
used to encrypt the authorisation data-see above.)
A sets the checksum type (authnr.authnr-Cksum.cksum-Type) to a checksum type that uses the same encryption key type as the encryption type encType (except that if encType = encKeyType-TRIVIAL, then authnr.authnr-Cksum is omitted altogether), and uses it to compute the checksum value (authnr.authnr-Cksum.cksum-Value), over the KDS Request body bgcolor="#FFFFFF" (tgsReq.req-Body, which is well-formed at this point). (For maximum interoperability, the client A should use the checksum type cksumType-MD4-DES, since all KDS servers are required to support clients using that checksum type-at least for the present revision of this document.)
The sequence number (authnr.authnr-SeqNum) is omitted.
The authorisation data field (authnr.authnr-AuthzData) is omitted.
A encrypts authnr, using the encryption type encType and the session key KA,B (not K^A,B, even if present). This is the ciphertext portion of the authentication header (authnHdr.authnHdr-EncryptedAuthnr.encData-CipherText). A also sets the encryption type (authnHdr.authnHdr-EncryptedAuthnr.encData-EncType) to encType and the key version number (authnHdr.authnHdr-EncryptedAuthnr.encData-KeyVersNum) to an appropriate value depending on local policy, if any (typically, it is omitted).
The use-session-key option (tgsReq.req-Body.req-Flags.req-UseSessionKey) is deselected.
The mutual authentication option
(authnHdr.authnHdr-Flags.authnHdr-MutualRequired) is deselected.
(As seen in
The other entries (tgsReq.req-AuthnData[i], i >= 1) in the list of authentication data are omitted.
At this point, the tgsReq message is well-formed, and A sends it to KDSY.
[RFC 1510: 3.3.2, 3.3.3, A.6]
The following algorithm discusses (in an appropriate order)
how KDSY handles the authentication header
authnHdr (and therefore the authenticator authnr
and presented ticket, ahTkt
(TktA,···,B)) accompanying tgsReq,
how it manipulates the old or issues the new ticket
Tkt*A,···,B*,
and how it constructs the remainder of the TGS Response, tgsResp
(which does not include a reverse-authentication header).
(The manner in which KDSY handles the authentication
header is an extension of the "mainline" usage of the authentication
header by not-necessarily-KDS servers as specified in
The first entry (tgsReq.req-AuthnData[0])
in the authentication data list (tgsReq.req-AuthnData)
is checked to be present and to be of authentication
data type (tgsReq.req-AuthnData[0].authnData-Type)
authnDataType-TGS-REQ. (Other entries
(tgsReq.req-AuthnData[i], i >= 1),
if present, are ignored.) Thus, the authentication data value
(tgsReq.req-AuthnData[0].authnData-Value) is regarded as (the
underlying OCTET STRING of) an authentication header,
authnHdr, containing an authenticator authnr
(authnHdr.authnHdr-EncryptAuthnr) constructed by A,
and an "authenticating ticket" Tkt
A,···,B
(ahTkt, authnHdr.authnHdr-Tkt) naming
A and targeted to some server B in cell Y
(which may be either a non-KDS server or KDSY
in one of its guises KDSW,Y)
{errStatusCode-AUTHN-DATA-TYPE-NOT-SUPPORTED}.
The protocol version number of TktA,···,B (ahTkt.tkt-ProtoVersNum) is checked to be protoVersNum-KRB5.
The server cell in TktA,···,B (ahTkt.tkt-ServerCell) is checked to be KDSY's cell name; that is, Y's cell name.
The server name in TktA,···,B (ahTkt.tkt-ServerName) is checked to indicate either a non-KDS server B in Y, or KDSY in one of its guises KDSW,Y.
If the use-session-key option (authnHdr.authnHdr-Flags.authnHdr-UseSessionKey) is selected, then KDSY rejects this TGS Request, returning a KDS Error. Otherwise, KDSY knows that the "authenticating" ticket, ahTkt (TktA,···,B), is protected with the long-term key KB of the server B it is targeted to (as indicated by ahTkt.tkt-ServerCell and ahTkt.tkt-ServerName) (KB = KKDSWY if B = KDSW,Y).
If the mutual authentication option
(authnHdr.authnHdr-Flags.authnHdr-MutualRequired) is selected
(so that A expects a reverse-authentication header, to be returned),
then KDSY rejects this TGS Request,
returning a KDS Error (see
KDSY uses the key protecting ahTkt (KB = KKDSWY, determined above), together with the indicated encryption type encType (ahTkt.tkt-EncryptedPart.encData-EncType) and key version number (ahTkt.tkt-EncryptedPart.encData-KeyVersNum) if relevant, to decrypt the ciphertext (ahTkt.tkt-EncryptedPart.encData-CipherText) of the authenticating ticket ahTkt (TktA,···,B). A successful decryption is recognised by the built-in integrity afforded by the ciphertext itself. In this way, KDSY learns the information carried in ahTkt (TktA,···,B), especially its session key (KA,B, or KA,KDSWY).
KDSY uses ahTkt's session key (KA,B, or KA,KDSWY), together with the encryption type encType (which must be the same as (authnHdr.authnHdr-EncryptedAuthnr.encData-EncType), to decrypt the authentication header's ciphertext (authnHdr.authnHdr-EncryptedAuthnr.encData-CipherText). (The key version number (authnHdr.authnHdr-EncryptedAuthnr.encData-KeyVersNum) should not be present.) A successful decryption is recognised by the built-in integrity afforded by the ciphertext itself-this is what convinces KDSY that A knows ahTkt's session key; that is, this is what actually "authenticates" A to KDSY (modulo timestamp considerations, below). In this way, KDSY learns the information carried in authnr (authnHdr.authnHdr-EncryptAuthnr).
The authenticator's protocol version number (authnr.authnr-ProtoVersNum) is checked to be protoVersNum-KRB5.
The client cells from ahTkt (ahTkt.tkt-EncryptPart.tkt-ClientCell) and from authnr (authnr.authnr-ClientCell) are checked to be the same (namely, to A's cell name; that is, X's cell name).
The client names from ahTkt (ahTkt.tkt-EncryptPart.tkt-ClientName) and from authnr (authnr.authnr-ClientName) are checked to be the same (namely, to A's RS name).
If there are client addresses present in ahTkt (ahTkt.tkt-EncryptPart.tkt-ClientAddrs), then KDSY checks that A is communicating from one of them (as reported by KDSY's operating system, according to the level of trust KDSY places in that); that is, that authnHdr was received from one of the addresses on the list.
A's timestamp (authnr.authnr-ClientTime) is
checked to be equal to KDSY's system time (modulo
maxClockSkew).
It is in this way that KDSY becomes convinced that it is
communicating with A in real-time (and this completes the
"authentication" of A to KDSY).
A's microsecondstamp (authnr.authnr-ClientMicroSec),
together with its timestamp, are checked to not be present in
KDSY's replay cache.
They are then stored in the replay cache.
(They can be purged from the replay cache later, as discussed in
ahTkt's start time (ahTkt.tkt-EncryptPart.tkt-StartTime) is checked to be earlier than or equal to KDSY's system time (modulo maxClockSkew).
ahTkt's expiration time (ahTkt.tkt-EncryptPart.tkt-ExpireTime) is checked to be later than (or later-than-or-equal-to, on an implementation-dependent basis) KDSY's system time (modulo maxClockSkew). (In particular, an expired ahTkt (TktA,···,B) cannot be renewed by the renew option processing step, below.)
ahTkt's maximum expiration time (ahTkt.tkt-EncryptPart.tkt-MaxExpireTime) is dealt with below.
The sequence number (authnr.authnr-SeqNum) is processed in an application-specific manner.
If a conversation key K^A,B (authnr.authnr-ConversationKey), of encryption type encType is present, KDSY will use it (instead of ahTkt's session key KA,B (or KA,KDSWY)) to protect this client-server session (but it will not generate its own conversation key, Kx^^'1xu'A,B, for this purpose, because KDSY does not return a reverse-authentication header).
ahTkt's transit path (ahTkt.tkt-EncryptPart.tkt-TransitPath) is dealt with below.
The checksum (authnr.authnr-Cksum) is checked to be present (unless encType = encType-TRIVIAL, in which case it must be absent), its checksum type (authnr.authnr-Cksum.cksum-Type) is checked to be supported by and acceptable to KDSY (in particular, this checksum type must use the same encryption key type as the encryption type encType, and the checksum value (authnr.authnr-Cksum.cksum-Value) is checked to be the checksum of the KDS Request body bgcolor="#FFFFFF" (tgsReq.req-Body). (For guaranteed interoperability, all KDS servers are required to support the checksum type cksumType-MD4-DES-at least for the present revision of this document.)
If ahTkt's invalid option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid) is selected, then KDSY checks that this tgsReq's validate option (tgsReq.req-Body.req-Flags.req-Validate) is selected.
All other ahTkt options are dealt with below. Currently, these include forwardable (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwardable), forwarded (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwarded), proxiable (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxiable), proxied (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxied), postdatable (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdatable), postdated (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdated), renewable (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable), and initial (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Initial).
At this point, KDSY has completed its preliminary
processing of the
authentication header authnHdr (including authnr and
ahTkt (TktA,···,B)),
and now turns its attention to constructing
the manipulated old or newly-to-be-issued tgsTkt
(Tkt*A,···,B*).
tgsTkt's protocol version number
(tgsTkt.tkt-ProtoVersNum) is set to protoVersNum-KRB5.
tgsTkt's client cell
(tgsTkt.tkt-EncryptPart.tkt-ClientCell) is set to
A's (authenticated) cell name (that is, to X's cell name).
tgsTkt's client name
(tgsTkt.tkt-EncryptPart.tkt-ClientName) is set to
A's (authenticated) RS name in RSX.
If the requested server cell name (tgsReq.req-Body.req-ServerCell)
is not KDSY's cell name-that is, not Y's cell
name (this will be the case if A is requesting a service-ticket to an
ultimate end-server in some cell other than Y)-
then KDSY sets tgsTkt's cell name
(tgsTkt.tkt-ServerCell) to that of a cell, Z,
that A is supposed to use as the next hop towards the requested
server cell, if possible-this indicates to A that
tgsTkt is to be used as a new cross-cell
referral ticket (see
If tgsTkt is a new cross-cell referral ticket (see preceding step),
then KDSY sets tgsTkt's server name
(tgsTkt.tkt-ServerName)
to the RS name of the chosen cross-registered
surrogate KDS server, KDS
Y,Z,
in RSZ. Otherwise, the requested server name
(tgsReq.req-Body.req-ServerName)
is checked to have a datastore entry in RSY, and
KDSY sets tgsTkt's server name
to the requested server name.
KDSY selects from the list of requested encryption types (tgsReq.req-Body.req-EncTypes) the earliest one on the list that it can accommodate, depending on policy-call this encType. (Typically, encType* = encType. This will happen, for example, in the common case of a client A sending a list consisting of a single entry, indicating the same encryption type, encType, as that used to protect the presented ticket TktA,···,B.) {errStatusCode-ENCRYPTION-TYPE-NOT-SUPPORTED}.
KDSY generates a new (random) session key (of the selected encryption type, encType*), K*A,B*, and copies it into tgsTkt's session key field (tgsTkt.tkt-EncryptPart.tkt-SessionKey).
tgsTkt's authentication time (tgsTkt.tkt-EncryptPart.tkt-AuthnTime) is set to ahTkt's authentication time (ahTkt.tkt-EncryptPart.tkt-AuthnTime).
If the requested start time (tgsReq.req-Body.req-StartTime) is absent, or if it is present and indicates a time earlier than tgsTkt's (that is, ahTkt's) authentication time or KDSY's system time, then tgsTkt's start time (tgsTkt.tkt-EncryptPart.tkt-StartTime) is set to tgsTkt's authentication time or KDSY's system time, whichever is later. Otherwise (that is, a start time is present and indicates a time later than or equal to both tgsTkt's authentication time and KDSY's system time), if the postdated option (tgsReq.req-Body.req-Flags.req-Postdate) is selected, KDSY sets tgsTkt's start time to the requested start time; otherwise, tgsTkt's start time is omitted. (See also the postdated and invalid options, below.) {errStatusCode-CANNOT-POSTDATE}.
KDSY sets tgsTkt's expiration time (tgsTkt.tkt-EncryptPart.tkt-ExpireTime) to the minimum of the following:
KDSY checks that the resulting lifetime of tgsTkt is greater than or equal to the cell-wide minimum ticket lifetime associated with the issuing authority KDSY (see also the renew and renewable options, below) {errStatusCode-NEVER-VALID}.
If ahTkt's renewable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable) is selected, and if either the renewable option (tgsReq.req-Body.req-Flags.req-Renewable) has been selected, or if the renewable-okay option (tgsReq.req-Body.req-Flags.req-RenewableOK) has been selected and ahTkt's expiration time is earlier than the requested expiration time, then tgsTkt's maximum expiration time (tgsTkt.tkt-EncryptPart.tkt-MaxExpireTime) is present (otherwise it is omitted) and is set to the minimum of:
(See also the renewable option, below, which may recalculate this maximum
expiration time.)
If ahTkt is itself a cross-cell referral ticket,
TktA,X,···,W,KDSWY
(which KDSY recognises by decrypting it and inspecting
its transit path),
then KDSY sets tgsTkt's transit path
(tgsTkt.tkt-EncryptPart.tkt-TransitPath) to the compression (see
tgsTkt's client address field (tgsTkt.tkt-EncryptPart.tkt-ClientAddrs) is set to ahTkt's client address field (ahTkt.tkt-EncryptPart.tkt-ClientAddrs), if present. Otherwise, it is omitted. (See also the forward and proxy options, below, which can change this client address field.)
tgsTkt's authorisation data field
(tgsTkt.tkt-EncryptPart.tkt-AuthzData) is set to
the concatenation (in this order)
of ahTkt's authorisation data
(ahTkt.tkt-EncryptPart.tkt-AuthzData) if present,
with the TGS Request's authorisation data
(tgsReq.req-Body.req-EncryptAuthzData, obtained by
decrypting tgsReq.req-Body.req-EncryptedAuthzData using the
conversation key authnr.authnr-ConversationKey
K^A,Y if present,
otherwise using the session key KA,B, both
of encryption type encType),
if present. If neither is present, this field is omitted.
Additional tickets (tgsReq.req-Body.req-AdditionalTkts) are processed as required according to the options (below) selected that require additional tickets.
If the forwardable option (tgsReq.req-Body.req-Flags.req-Forwardable) is requested, and if ahTkt's forwardable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwardable) is selected, then tgsTkt's forwardable option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwardable) is selected.
If the forward option (tgsReq.req-Body.req-Flags.req-Forward) is requested, and if ahTkt's forwardable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwardable) is selected, then tgsTkt's client addresses (tgsTkt.tkt-EncryptPart.tkt-ClientAddrs) are set to the requested client addresses (tgsReq.req-Body.req-ClientAddrs).
If the forward option (tgsReq.req-Body.req-Flags.req-Forward) is requested, or if ahTkt's forwarded option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwarded) is selected, then tgsTkt's forwarded option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwarded) is selected.
If the proxiable option (tgsReq.req-Body.req-Flags.req-Proxiable) is requested, and if ahTkt's proxiable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxiable) is selected, then tgsTkt's proxiable option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxiable) is selected.
If the proxy option (tgsReq.req-Body.req-Flags.req-Proxy) is requested, and if ahTkt's proxiable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxiable) is selected, then tgsTkt's client addresses (tgsTkt.tkt-EncryptPart.tkt-ClientAddrs) are set to the requested client addresses (tgsReq.req-Body.req-ClientAddrs).
If the proxy option (tgsReq.req-Body.req-Flags.req-Proxy) is requested, or if ahTkt's proxied option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxied) is selected, then tgsTkt's proxied option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxied) is selected.
If the postdatable option (tgsReq.req-Body.req-Flags.req-Postdatable) is requested, and if ahTkt's postdatable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdatable) is selected, then tgsTkt's postdatable option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdatable) is selected.
If tgsTkt's start time is present, and if ahTkt's postdatable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdatable) is selected, then tgsTkt's postdated option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdated) is selected.
If tgsTkt's postdated option is selected (above), then tgsTkt's invalid option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid) is selected.
If the validate option (tgsReq.req-Body.req-Flags.req-Validate) is requested, and if ahTkt's invalid option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid) is set, and if ahTkt's start time (ahTkt.tkt-EncryptPart.tkt-StartTime) is earlier than or equal to KDSY's system time (modulo maxClockSkew), then Tkt*A,···,B* is set equal to TktA,···,B, except that tgsTkt's invalid option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid) is deselected.
If the renew option (tgsReq.req-Body.req-Flags.req-Renew) is requested, and if ahTkt's renewable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable) is selected, and if ahTkt's maximum expiration time (ahTkt.tkt-EncryptPart.tkt-MaxExpireTime) is later than or equal to KDSY's system time (modulo maxClockSkew), then tgsTkt is set equal to ahTkt, except that tgsTkt's start time (tgsTkt.tkt-EncryptPart.tkt-StartTime) is set to KDSY's system time and tgsTkt's expiration time (tgsTkt.tkt-EncryptPart.tkt-ExpireTime) is set to the minimum of:
If the renewable-okay option (tgsReq.req-Body.req-Flags.req-RenewableOK) is requested, and if ahTkt's renewable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable) is selected, and if tgsTkt's expiration time (tgsTkt.tkt-EncryptPart.tkt-ExpireTime) is earlier than the requested expiration time (tgsReq.req-Body.req-ExpireTime), then the renewable option (tgsReq.req-Body.req-Flags.req-Renewable) is selected (so that the renewable step below is processed) and the requested maximum expiration time (tgsReq.req-Body.req-MaxExpireTime) is set equal to the minimum of:
If the renewable option (tgsReq.req-Body.req-Flags.req-Renewable) option is requested, and if ahTkt's renewable option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable) is selected, then tgsTkt's renewable option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable) is selected, and tgsTkt's maximum expiration time (tgsTkt.tkt-EncryptPart.tkt-MaxExpireTime) is (re)calculated as in the maximum expiration time step, above.
If the request's use-session-key option (tgsReq.req-Body.req-Flags.req-UseSessionKey) has not been requested, then KDSY knows that A wants tgsTkt to be protected with the long-term key of its targeted server (see encryption step, below). If the request's use-session-key has been requested, then KDSY knows that A wants tgsTkt to be protected with its targeted server's ticket-granting-ticket's session key (see encryption step, below), accordingly it verifies that the accompanying additional Tkt* (tgsReq.req-Body.req-AdditionalTkts) is present and is a (valid) ticket-granting-ticket targeted to B; if the use-session-key has been requested, but Tkt* is not present or if KDSY cannot decrypt it and verify it is a ticket-granting-ticket targeted to B, the KDSY rejects the request.
tgsTkt's initial option (tgsTkt.tkt-EncryptPart.tkt-Flags.tkt-Initial), is deselected. (This marks tgsTkt as a subsequent (that is, non-initial) ticket.)
If the use-session-key option
(tgsReq.req-Body.req-Flags.req-UseSessionKey) has not been
requested, then the long-term key KB* (of encryption
type encType*) of the server B* targeted by tgsTkt
(Tkt*A,···,B*) is used to
protect it; if the use-session-key option has been requested, then the
session key K* = KB,KDSWY
(of encryption type encType*) in the
accompanying ticket-granting-ticket Tkt* =
TktB,KDSWY is used to protect it (see
The protocol version number (tgsResp.resp-ProtoVersNum)
is set to protoVersNum-KRB5.
The protocol message type (tgsResp.resp-ProtoMsgType)
is set to protoMsgType-TGS-RESPONSE.
The authentication data (tgsResp.resp-AuthnData)
is omitted. (In particular, no reverse-authentication header is
transmitted back to the client.)
The client cell (tgsResp.resp-ClientCell)
is set to tgsTkt's client cell name
(tgsTkt.tkt-EncryptPart.tkt-ClientCell); that is,
A's cell name to X's cell name.
The client name (tgsResp.resp-ClientName)
is set to tgsTkt's client name
(tgsTkt.tkt-EncryptPart.tkt-ClientName);
that is, A's RS name.
The ticket (tgsResp.resp-Tkt) is set to
tgsTkt (Tkt*
A,···,B*).
The session key (tgsResp.resp-EncryptPart.resp-SessionKey) is set to tgsTkt's (Tkt*A,···,B*'s) session key, K*A,B* (tgsTkt.tkt-EncryptPart.tkt-SessionKey, of encryption type encType*).
The nonce (tgsResp.resp-EncryptPart.resp-Nonce) is set to the nonce that A sent (tgsReq.req-Body.req-Nonce).
The client address field (tgsResp.resp-EncryptPart.resp-ClientAddrs) is set to tgsTkt's client address field if tgsTkt has been newly forwarded or proxied on this TGS Request (that is, the forward option (tgsReq.req-Body.req-Flags.req-Forward) is selected, above). Otherwise, it is omitted.
The server cell (tgsResp.resp-EncryptPart.resp-ServerCell) is set to tgsTkt's server cell (tgsTkt.tkt-ServerCell).
The server name (tgsResp.resp-EncryptPart.resp-ServerName) is set to tgsTkt's server name (tgsTkt.tkt-ServerName).
The authentication time
(tgsResp.resp-EncryptPart.resp-AuthnTime)
is set to tgsTkt's authentication time
(tgsTkt.tkt-EncryptPart.tkt-AuthnTime).
The start time (tgsResp.resp-EncryptPart.resp-StartTime) is set to tgsTkt's start time (tgsTkt.tkt-EncryptPart.tkt-StartTime), if present. Otherwise, it is omitted.
The expiration time (tgsResp.resp-EncryptPart.resp-ExpireTime) is set to tgsTkt's expiration time (tgsTkt.tkt-EncryptPart.tkt-ExpireTime).
The maximum expiration time (tgsResp.resp-EncryptPart.resp-MaxExpireTime) is set to tgsTkt's maximum expiration time (tgsTkt.tkt-EncryptPart.tkt-MaxExpireTime), if present. Otherwise, it is omitted.
The key expiration date (tgsResp.resp-EncryptPart.resp-KeyExpireDate) is omitted.
The last requests field
(tgsResp.resp-EncryptPart.resp-LastRequests)
is set, if policy permits, to A's last requests information (see
The options (tgsResp.resp-EncryptPart.resp-Flags) are set to tgsTkt's options (tgsTkt.tkt-EncryptPart.tkt-Flags).
KDSY encrypts tgsResp.resp-EncryptPart using the encryption type encType and ahTkt's (TktA,···,B's) session key KA,B, unless A has requested that a conversation key K^A,B (authnr.authnr-ConversationKey) be used, in which case KDSY uses that key instead. This is the ciphertext portion of the TGS Response (tgsResp.resp-EncryptedPart.encData-CipherText). KDSY also sets the encryption type (tgsResp.resp-EncryptedPart.encData-EncType) to encType. The key version number (tgsResp.resp-EncryptedPart.encData-KeyVersNum) is omitted.
At this point, the KDS Response is well-formed, and the KDS returns it to the calling client.
[RFC 1510: 3.3.4, A.4, A.7]
Here, the notions of "success" or "failure" of this algorithm are taken to mean "conforming to A's request (tgsReq)", where the criteria of "conformance" are application-specific. Typically, but not necessarily, A will be satisfied only if KDSY formulates the TGS Response exactly as A requested. For example, A may have requested a very long maximum expiration time but KDSY issued only a somewhat shorter one -whether A views that as a success or failure is an application-specific determination.
The named client's cell (tgsResp.resp-ClientCell) is checked for conformance to what A requested in the authenticator to its TGS Request (authnr.authnr.ClientCell, where authnr is carried in tgsReq.req-AuthnData as described previously).
The client name (tgsResp.resp-ClientName) is checked for conformance to what A requested (tgsReq.req-Body.req-ClientName).
The authentication data (tgsResp.resp-AuthnData) is ignored.
tgsTkt (tgsResp.resp-Tkt) is not directly interpretable (in the sense of being decryptable) by A (unless A happens to also be the server targeted by tgsTkt), but the information in it is largely available elsewhere in tgsResp.
The encryption type, encType
(tgsResp.resp-EncryptedPart.encData-EncType), is checked
to be the same as the encryption type protecting the
ahTkt (TktA,···,B) A
had presented to KDSY in the authentication header of its
TGS Request (authnHdr.authnHdr-Tkt).
If it is acceptable,
then A attempts to decrypt the ciphertext portion of the TGS Response
(tgsResp.resp-EncryptedPart.encData-CipherText), using
the session key KA,B
from ahTkt,
unless A has requested that a conversation key
K^A,B (authnr.authnr-ConversationKey)
be used, in which case A uses that key instead.
(Note that this differs from the case of an AS Response, which is
protected with A's long-term key, not a session key.) A
successful decryption is recognised by the built-in
integrity afforded by the ciphertext itself.
In this way, A learns the information carried in
tgsResp.resp-EncryptPart.
The nonce (tgsResp.resp-EncryptPart.resp-Nonce)
is checked for equality with the requested nonce
(tgsReq.req-Body.req-Nonce). If it
is not equal, then this tgsResp does not correspond to
tgsReq, and a "replay attack" may be suspected, to which A
takes application-specific action.
The last requests
(tgsResp.resp-EncryptPart.resp-LastRequests)
are typically ignored (it may be inspected if present, but it is
typically not present-see
The key expiration date
(tgsResp.resp-EncryptPart.resp-KeyExpireDate)
is typically ignored (it may be inspected if present, but it is typically
not present-see
The server cell (tgsResp.resp-EncryptPart.resp-ServerCell) is checked for conformance to what A requested (tgsReq.req-Body.req-ServerCell). (See also next step.)
The server name (tgsResp.resp-EncryptPart.resp-ServerName) is checked for conformance to what A requested (tgsReq.req-Body.req-ServerName). (If the server cell (tgsResp.resp-EncryptPart.resp-ServerCell) and server name (tgsResp.resp-EncryptPart.resp-ServerName) do not identify the server that A requested, then A knows tgsTkt is a new cross-cell referral ticket, and A will normally send a TGS Request to the new cross-cell KDS server it names.)
The encryption type, encType* (tgsTkttkt-EncryptedPart.encData-Enctype), of the session key (which A trusts is secure), K*A,B* (tgsResp.resp-EncryptPart.resp-SessionKey), is checked for conformance to what A had requested (tgsReqreg-Body.reg-EncTypes), and K*A,B* is saved for later use (for example, in protecting communications with the server B*).
The authentication time (tgsResp.resp-EncryptPart.resp-AuthnTime) is checked for conformance to what A expects (namely, A's authentication time from ahTkt and from A's original initial ticket-granting-ticket on which tgsTkt is ultimately based).
The start time (tgsResp.resp-EncryptPart.resp-StartTime) is checked for conformance to what A requested. Namely, if A requested tgsTkt to be postdated, then the start time is checked to be present and checked for conformance to the start time A requested (tgsReq.req-Body.req-StartTime); otherwise, the start time should be absent.
The expiration time (tgsResp.resp-EncryptPart.resp-ExpireTime) is verified for conformance to what A requested (tgsReq.req-Body.req-ExpireTime).
The maximum expiration time (tgsResp.resp-EncryptPart.resp-MaxExpireTime) is checked for conformance to what A requested. It should only be present (at most) if A had selected the renewable option (tgsReq.req-Body.req-Flags.req-Renewable) and supplied a requested maximum expiration time (tgsReq.req-Body.req-MaxExpireTime), or if A had selected the renewable-okay option (tgsReq.req-Body.req-Flags.req-RenewableOK).
If A requested that tgsTkt contain client host addresses (as part of a forward or proxy request), then the client address field (tgsResp.resp-EncryptPart.resp-ClientAddrs) is verified to be present and checked for conformance to what A requested (tgsReq.req-Body.req-ClientAddrs). Otherwise, the client addresses are checked for conformance to the client addresses in the ticket-granting-ticket accompanying the TGS Request (ahTkt.tkt-EncryptPart.tkt-ClientAddrs), if present.
The options field (tgsResp.resp-EncryptPart.resp-Flags) is inspected for conformance to what A requested (tgsReq.req-Body.req-Flags).
This completes the specification of the TGS Request/Response exchange.
[RFC 1510: 3.1.6, A.20]
The protocol version number (kdsErr.err-ProtoVersNum) is set to protoVersNum-KRB5.
The protocol message type (kdsErr.err-ProtoMsgType) is set to protoMsgType-KDS-ERROR.
The client cell (kdsErr.err-ClientCell) is set to the request's client cell (authnr.authnr-ClientCell), if available. Otherwise, it is omitted.
The client name (kdsErr.err-ClientName) is set to the request's client name (authnr.authnr-ClientName), if available. Otherwise, it is omitted.
The server cell (kdsErr.err-ServerCell) is set to the request's server cell name (kdsReq.req-ServerCell), which is KDSY's cell name; that is, Y's cell name.
The server name (kdsErr.err-ServerName) is set to the request's server's RS name (kdsReq.req-ServerName), which is KDSY's RS name.
The client timestamp (kdsErr.err-ClientTime) is set to the request's client timestamp (authnr.authnr-ClientTime), if available. Otherwise, it is omitted.
The client microsecondstamp (kdsErr.err-ClientMicroSec) is set to the request's client microsecondstamp (authnr.authnr-ClientMicroSec), if available. Otherwise, it is omitted.
The server timestamp (kdsErr.err-ServerTime)
is set to KDSY's system time.
The server microsecondstamp (kdsErr.err-ServerMicroSec) is set to KDSY's microsecondstamp.
The status code (kdsErr.err-StatusCode) is set to the status code of the error being reported by this KDS Error message.
The status text (kdsErr.err-StatusText) is set to the status text associated with the status code being reported, if any. Otherwise it is omitted.
The status data (kdsErr.err-StatusData) is set to the status data associated with the status code being reported, if any. Otherwise it is omitted.
This completes the specification of the KDS Error message processing.
[RFC 1510: 1.1]
Consider a client A in cell X that wants to authenticate to an ultimate non-KDS end-server B in cell Y, with X != Y. A begins by obtaining an (initial or subsequent) ticket, TktA,KDSX, protected with KDSX's long-term key KKDSX.
A then sends a TGS Request to KDSX, presenting TktA,KDSX (in req-AuthnData) to KDSX, requesting a service-ticket targeted to B in Y. Note that A must know the principal name of B (comprising the cell name of Y and the RS name of B in Y), but A does not a priori know the intermediate cells in the trust chain between X and Y-that is, A knows the structure of the namespace, but only the network of KDS servers knows the structure of the trust graph (consisting of the cross-cell registrations of KDS servers with one another).
Since B's home cell is Y (!= X), KDSX does not know B's long-term key KB+3, and so it cannot construct the requested service-ticket targeted to B. Instead, KDSX chooses a cell Z which is cross-registered with X to be used as the next hop towards Y, and returns to A a TGS Response which contains (in resp-Tkt) a cross-cell referral ticket, TktA,X,KDSXZ. This TGS Response and TktA,X,KDSXZ contain a newly generated session key KA,KDSXZ between A and KDSX,Z, and TktA,X,KDSXZ is protected with the long-term key KKDSXZ shared between the two surrogate KDS principals KDSX,Z cross-registered in RSX and in RSZ.
When A receives this TGS Response from KDSX, it recognises that it has received (resp-Tkt) a cross-cell referral ticket instead of the service-ticket it had requested, because the TGS Response contains information (in resp-ServerCell and resp-ServerName) telling A that the target of resp-Tkt is not the server B that A had requested (and a cross-cell referral ticket is the only instance in which a KDS server ever issues a ticket targeted to a server other than that requested by the client). Accordingly, A now formulates a new TGS Request, to KDSZ (KDSX,Z) this time, again requesting a service-ticket targeted to B. The ticket A present (in req-AuthnData) in this TGS Request to KDSZ is the cross-cell referral ticket, TktA,X,KDSXZ, A just received from KDSX.
When KDSZ receives this TGS Request, it decrypts TktA,X,KDSXZ with the long-term key KKDSXZ, thereby learning its session key KA,KDSZ (this authenticates A to KDSZ and secures communications between them, and establishes the A -> KDSX -> KDSZ trust chain).
Now shift notation slightly (for purposes of an inductive argument) and write Z´ instead of Z. If Z´ = Y, then KDSZ´ = KDSY can satisfy A's TGS Request, and can return to A the TktA,X,Y,B A requested. Otherwise, the above procedure is iterated: KDSZ´ returns (if possible) to A another new cross-cell referral ticket, TktA,X,Z´,KDSZ´Z´´, to a next-hop cell Z´´ which is even closer to the desired cell Y. This process continues through a sequence of cross-cell referrals, Z´, Z´´, ···, Z´´´, until it eventually terminates (if no errors are encountered) when the desired cell Z´´´´ = Y is ultimately reached. For at that point, A's TGS Request to KDSY (KDSZ´´´Y) for a service-ticket targeted to B (protected in B's long-term key KB+3) will finally be satisfied, and is returned to A in the TGS Response from KDSY. A recognises that it has finally received a service-ticket targeted to its desired end-server B, so can then proceed to use this Tkt\dA,X,Z´,Z´´,···,Z´´´,Y,B to authenticate itself to, and protect its communications with, B.
Finally, it is to be noted that this chapter has not explained how
authorisation data or UUIDs make their appearance in the
protocol. That is the province of the Privilege Service, as specified in
Contents | Next section | Index |