Key Distribution (Authentication) Services

This chapter specifies the key distribution, or authentication, services supported by DCE, together with the protocols associated with them. Currently, only one such service is supported, namely the Kerberos Key Distribution Service (KDS), so this whole chapter is devoted to that. The KDS is comprised of two specialised (sub-)services, the Authentication (Sub-)Service (AS) (not to be confused with the generic terminology "authentication service") and the Ticket-granting (Sub-)Service (TGS)- and for that reason the KDS is sometimes also referred to as the AS/TGS.

For an overview of this chapter, see Kerberos Key Distribution (Authentication) Service (KDS) through Cells-Cross-cell Authentication and Authorisation -which are considered a prerequisite for this whole chapter.

Notes:

1. This chapter is based on, and (unless stated otherwise) is technically aligned with, (a subset of) RFC 1510. However, for editorial reasons, this chapter stands independently, and no familiarity with RFC 1510 is required. (Thus, the part of this chapter that duplicates information in RFC 1510 is intended to be technically equivalent to that document, rewritten for the expository purposes of this document, and any technical discrepancies between the two are inadvertent and to be reconciled.) Differences between the two documents are minor and are readily justified, but the reader should note in particular the following changes:

   1. What is called "cell" in DCE is called "realm" in RFC 1510.

   2. The service called Key Distribution Service (KDS) here is called Key Distribution Center (KDC) there (the difference in terminology merely indicating their preferred communications medium, RPC or raw UDP).

   3. The data type identifiers in the two documents are conservatively different, in an attempt to improve clarity and consistency (instead of, for example, using a mixture of ASN.1, C and other identifiers, such as "AP-REQ", "KRB_AP_REQ" and "authentication header" all referring to the same object in RFC 1510, Section 5.5.1), without affecting interoperability or placing conformance requirements on implementations.

   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.

2. Extensive use is made in this chapter of natural-language algorithmic descriptions. In them, it is the mainline "success" (non-error) case that is emphasised-in particular, this document permits different implementations to encounter errors (exceptions) in different orders, and so report different errors under the same external conditions. This is indicated by marking error conditions in algorithms by "{errStatusCode-NAME-OF-ERROR}" (perhaps with some explanatory material), leaving to implementations the decision at what point to abort a failed algorithm, and which error to report.

3. [RFC 1510: 5.1]

   This chapter employs the "ASN.1/BER/DER" standards for data description/representation (IDL is used only in The krb5rpc RPC Interface ), which are defined in three CCITT (now ITU-T) Recommendations. The data description language used is Abstract Syntax Notation One (ASN.1), which is defined in CCITT X.208. The data representation (encoding) used for data described by ASN.1 is the Basic Encoding Rules (BER), which are defined in CCITT X.209. Familiarity with those documents, including the data types defined in them, is required for this chapter.

   Additionally, the following Distinguished Encoding Restrictions (DER) to BER, as specified in CCITT X.509, Section 8.7- (only) the ones actually used in this chapter are repeated here, in order that this chapter can stand independently of CCITT X.509- are in effect:

   1. The definite form of length encoding shall be used, encoded in the minimum number of octets.

   2. For string types, the constructed form of encoding shall not be used.

   3. Each unused bit in the final octet of the encoding of a BIT STRING value, if there are any, shall be reset (to 0).

   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.)

   Finally, when ASN.1 descriptions are referenced during the course of pseudocode expositions, ASN.1 is augmented with the familiar (but non-ASN.1-standard) pseudocode dot notation for field elements. For SEQUENCEs, this takes the form illustrated by the example: if seq is a value of type SeqType ::= SEQUENCE {int [0] INTEGER, oct [1] OCTET}, then the values of the fields of seq are denoted seq.int and seq.oct, respectively. For BIT STRINGs, it takes a similar form: for example, if bits is a value of type Bits ::= BIT STRING {bit0 (0), bit1 (1), bit2 (2)}, then the values of the bits of bits are denoted bits.bit0, bits.bit1 and bits.bit2, respectively. If the value in question (for example, seq or bits) is implicitly understood from context, it (and the dot immediately following it) may even be omitted if no confusion will result. For SEQUENCE OFs, ASN.1 is further augmented with the familiar pseudocode bracket notation for arrays: if seqof is a value of type, say, SeqOfType ::= SEQUENCE OF {SeqType}, having 2 entries, then its entries are denoted seqof[0] and seqof[1].

Fundamental Concepts

[RFC 1510: 1]

This chapter deals with the authentication of (RPC) clients and servers, in the context of cells. The following general notational conventions will be used for these concepts. Recall that the home cell of a principal is the cell whose RS datastore holds the security information for the principal. (More precisely, "a" home cell of a principal should be spoken of, since some principals may be registered in multiple cells-though this is not to be recommended in general. DCE specifies just one, very specific, kind of multiply registered principal, namely cross-cell surrogate KDS server principals (see below), and in that case care should be taken to indicate which cell is being considered its home cell in a given situation. For non-KDS principals, continue to speak of "the" home cell, leaving to the reader the (easy) translation to the case of multiple-registration.)

• X, Y, Z, W, X´, ···, are reserved for cells.

• A, A´, ···, are reserved for clients, with home cells X, X´, ···, respectively.

• B, B´, ···, are reserved for servers, with home cells Y, Y´, ···, respectively.

• C, C´, ···, denote clients or servers, in arbitrary cells.

These (especially cells) often appear as subscripts (for example, KDS_Z, KDS_X,Y), but in order to improve legibility of embedded subscripts they will upgraded when they themselves appear in subscripts (for example, K_KDSZ, K_KDSXY instead of K_KDSZ, K_KDS\dX,Y^).

The KDS is a distributed, partitioned RPC service, instantiated by a (conceptually unitary, but potentially replicated) RPC server in each cell Z, denoted KDS_Z. If the name of cell Z is, say, /.../cellZ, then the RPC service name of KDS_Z (used for RPC binding purposes) is determined from /.../cellZ/cell-profile via the krb5rpc interface UUID and version number (specified in The krb5rpc RPC Interface ) -typically, the name associated with this profile element will be /.../cellZ/sec, which will be an RPC server group pointing to the individual (replicated) KDS_Z server(s). (See RPC Binding Models for more details on binding models.) (The principal names of KDS servers (used for security purposes)- as opposed to their RPC server names (used for communications purposes) -are introduced in RS Names and Principal Names .)

The krb5rpc RPC Interface

 

[uuid(8f73de50-768c-11ca-bffc-08001e039431), version(1.0)]
interface krb5rpc
{ /* begin running listing of krb5rpc interface */
    [idempotent] void
    kds_request (
        [in] handle_t                       rpc_handle,
        [in] unsigned32                     request_count,
        [in, size_is(request_count)] byte   request[],
        [in] unsigned32                     response_count_max,
        [out] unsigned32                    *response_count,
        [out, size_is(response_count_max), length_is(*response_count)]
            byte                            response[],
        [out] error_status_t                *status );
} /* end running listing of krb5rpc interface */

• Issuing cell TCBs, or what amounts to the same thing, issuing KDS server(s), say KDSZ´^{, ···, KDS}Z´´

  The KDS server(s) (which are trusted third parties) that (cooperatively) issued this ticket, also said to be the issuing authorities for the ticket.

• Named client, say A (in cell X)

  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.

• Targeted server, say B (in cell Y)

  The server that this ticket authenticates to the named client (called A in previous item).

A -> TCB_X -> TCBZ´ ^{-> ··· -> TCB}Z´´ ^{-> TCB_Y -> B}

A -> KDSX,X ^{-> KDS}X,Z´ ^{-> ··· -> KDS}Z´´,Y ^{-> KDS}Y,Y ^{-> B}

TktA,X,Z´,···,Z´´,Y,B ^{or Tkt}A,Z´,···,Z´´,B

 

TktA,···,B or TktA,B

TktA,X,B ^{(instead of Tkt}A,X,X,B⁾

• Long-term (or initial) key of a principal C, denoted K_C

  It is stored in the RS_Z 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 TCB_Z (or other TCB components; for example, on the local host). Long-term keys are primarily used to protect internal protocol meta-data (tickets).

• Short-term (subsequent, session, conversation, "true session"; see Introduction to Security Services , especially the description of the TGS Response message in Kerberos Key Distribution (Authentication) Service (KDS) ) key shared by a client A and server B, denoted KA,B

  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: TCB_X, TCBZ´^{, ···, TCB}Z´´^{, TCB_Y (or other TCB components). Short-term keys are primarily used to protect application-level data (though they are also used in internal protocols).}

In order for the definition of ticket to make sense, KDS servers must in fact "be principals", in the sense of being registered in the RS datastores in their cells, and this is always assumed to be the case. The principal corresponding to the KDS server in cell X is denoted by the same notation, KDS_X, if no confusion will result, or by the expanded notation KDSX,X ^{if emphasis is needed. (Strictly speaking, the notation KDS_X should be reserved for the KDS server "as for TCB component (communicating entity)", and KDS}X,X ^{should be reserved to denote the KDS server "as for principal".)}

More generally, it is possible for a KDS server, KDS_X, to issue a ticket targeted to a KDS server, KDS_Y, other than itself. In order for this to happen, KDS_Y must know the key of a principal registered in RS_X- that principal is denoted by KDSX,Y^{. This arrangement is called a cross-cell registration of KDS servers; KDS}X,Y ^{is called a surrogate (principal) of KDS_Y in cell X, and its long-term key stored in RS_X, K}KDSXY^{, is called a cross-cell key. At the same time, this same principal KDS}X,Y ^{is also registered in RS_Y, with a different principal stringname (because it's in a different cell) but with the same cross-cell key, K}KDSXY^{-and principal (in RS_Y) is also called a surrogate (principal) of KDS_Y. Thus, in this terminology, "surrogate" refers to the principal KDS}X,Y ^{registered in both RS_X and in RS_Y (with the same key K}KDSXY^{), the only distinction between the two being their principal names (which reflects the cells they are being considered in; that is, which RS datastore their principal information is held in)-and for that reason, the combined terminology cross-cell surrogate (double principal) is sometimes used; and this principal is also said to mediate the X -> Y trust link. Finally, cross-cell registration also always entails the symmetrically defined surrogate registration of KDS_X in RS_Y: thus, KDS}Y,X ^{is the surrogate of KDS_X in cell Y (and in cell X), both with the same long-term key K}KDSYX^{, mediating the Y -> X trust link. (See Cells-Cross-cell Authentication and Authorisation for more discussion.)}

Some Basic Data Types

 

ProtocolVersionNumber ::= INTEGER

 

ProtocolMessageType ::= INTEGER

 

TimeStamp ::= GeneralizedTime -- X.208 32.3b

Its semantics are that it indicates the generating system clock's UTC time (see the referenced Open Group DCE 1.1 Time Services Specification), in the syntax of CCITT X.208, Section 32.3b, measured to the granularity of seconds. This syntax is a string of 15 characters, the first 14 of which are the first 14 decimal digits of a DTS string format timestamp, and the 15th of which is the character "Z". Thus, if this syntax is denoted by "CCYYMMDDhhmmssZ", then CCYY indicates the (century and) year, MM the month, DD the day, hh the hour, mm the minute, and ss the second. For example, the TimeStamp "19950825163947Z" indicates the UTC time: "AD August 25, 1995, at 4:39:47 PM".

Note:

The appearance of the character "Z" is historical. It is a reference to the "Z" (usually verbalised as "Zulu") time zone. See the referenced Open Group DCE 1.1 Time Services Specification for more information.

 

endOfTimeStamp TimeStamp ::= "197001010000Z"

 

MicroSecond ::= INTEGER -- 0..999999

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, T0 ^{and T}1^{, are "equal" means that 1T}0 ^{- T}1^{| <= maxClockSkew (where maxClockSkew is the maximum allowable clock skew appropriate to the interpreting clock). Similarly, the "lifetime" of a ticket (introduced below), which is nominally the (closed) time interval [tkt-StartTime, tkt-ExpireTime], is in actuality to be interpreted as [tkt-StartTime - maxClockSkew, tkt-ExpireTime + maxClockSkew] (where maxClockSkew is the one appropriate to the interpreting clock).}

Note:

In accordance with the actual semantic of the MicroSecond data type as a nonce instead of its nominal semantic as a microsecond, maxClockSkew is applied only to timestamps T, not to pairs <T, M> of timestamps and microsecondstamps. See the discussion of server "replay caches" (which is the only place that the semantics MicroSeconds are actually used), in Authenticators .

 

CellName ::= GeneralString -- X.208 31.2; ISO 2022, 2375

 

TransitPathType ::= INTEGER
TransitPathValue ::= OCTET STRING

TransitPath ::= SEQUENCE {
        transitPath-Type  [0] TransitPathType,
        transitPath-Value [1] TransitPathValue
}

 

RSNameType ::= INTEGER
RSNameValue ::= SEQUENCE OF GeneralString

RSName ::= SEQUENCE {
        rsName-Type  [0] RSNameType,
        rsName-Value [1] RSNameValue
}

• krbtgt/cellX

  The RS name of KDSX,X^{, which is the principal of the KDS server, KDS_X, for cell X. It is held as a datastore item in RS_X's datastore.}

• krbtgt/cellY

  The RS name of KDSX,Y^{, which is the surrogate principal of KDS_Y in cell X (held in RS_X's datastore); it is the same principal as the surrogate KDS}X,Y ^{in cell Y (held in RS_Y's datastore), in the sense that these two principals have the same long-term key, K}KDSXY^.

 

CellAndRSName ::= SEQUENCE {
        cellName [0] CellName,
        rsName   [1] RSName
}

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, <rsName0^{, ···, rsName}r-1^{>, then the corresponding string form of cellAndRSName is:}

/.../cellX/rsName0^/···/ rsNamer-1

 

HostAddressType ::= INTEGER
HostAddressValue ::= OCTET STRING

HostAddresses ::= SEQUENCE OF SEQUENCE {
        hostAddr-Type  [0] HostAddressType,
        hostAddr-Value [1] HostAddressValue
}

 

SequenceNumber ::= INTEGER

 

LastRequestType ::= INTEGER
LastRequestValue ::= TimeStamp

LastRequests ::= SEQUENCE OF SEQUENCE {
        lastReq-Type  [0] LastRequestType,
        lastReq-Value [1] LastRequestValue
}

 

ErrorStatusCode ::= INTEGER
ErrorStatusText ::= GeneralString
ErrorStatusData ::= OCTET STRING

 

Nonce ::= INTEGER

 

Random ::= OCTET STRING

 

EncryptionKeyType ::= INTEGER
EncryptionKeyValue ::= Random

EncryptionKey ::= SEQUENCE {
        encKey-Type  [0] EncryptionKeyType,
        encKey-Value [1] EncryptionKeyValue
}

• encKeyType-TRIVIAL = 0

  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.

• encKeyType-DES = 1

  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 Encryption/Decryption Mechanisms ). It is furthermore required (compare Keys to be Avoided ) that implementations must avoid DES keys K that are weak or semi-weak, or for which the variant key K ^ Kf0 ^{is weak or semi-weak; and they should avoid generating keys for which K or K ^ K}f0 ^{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 Registered Checksum Types .) Here, K}f0 denotes the 64-bit vector (of even parity):

   
  
  <0xf0,0xf0,0xf0,0xf0,0xf0,0xf0,0xf0,0xf0>
  
  
  

 

CheckSumType ::= INTEGER
CheckSumValue ::= OCTET STRING

CheckSum ::= SEQUENCE {
        cksum-Type  [0] CheckSumType,
        cksum-Value [1] CheckSumValue
}

• cksumType-MD4-DES = 3

  Let K be an encryption key of type encKeyType-DES, and let P be a plaintext bit-message. Then the corresponding cksum-Value, denoted:

   
  
  MD4-DES(K, P)
  
  

  
  

  is defined by the following pseudocode algorithm:

   
  
  R64 = RANDOM64();
  P' = <R64, P>;
  C128 = MD4(P');
  P" = <R64, C128>;
  K' = K ^ Kf0;
  MD4-DES(K, P) = DES-CBC(K', P");
  
  
  

  In words: First generate a random 64-bit vector, R64 ^{(called a confounder when used in this context-see CBC Mode ). Let P´ denote P prepended with R}64^{, and let C}128 ^{denote the 128-bit checksum MD4(P´). Let P´´ denote the concatenation of R}64 ^{and C}128^{, and let K´ denote the variant key K ^ K}f0 ^{(see Registered Encryption Key Types ). Then the checksum MD4-DES(K, P) is equal to DES-CBC(K´, P´´) (which is 192 bits long).}

• cksumType-MD5-DES = 8

  Let K be an encryption key of type encKeyType-DES, and let P be a plaintext bit-message. Then the corresponding cksum-Value, denoted:

   
  
  MD5-DES(K, P)
  
  

  
  

  is defined by the following pseudocode algorithm:

   
  
  R64 = RANDOM64();
  P' = <R64, P>;
  C128 = MD5(P');
  P" = <R64, C128>;
  K' = K ^ Kf0;
  MD5-DES(K, P) = DES-CBC(K', P");
  
  
  

  In words: First generate a random 64-bit vector, R64 ^{(called a confounder when used in this context-see CBC Mode ). Let P´ denote P prepended with R}64^{, and let C}128 ^{denote the 128-bit checksum MD5(P´). Let P´´ denote the concatenation of R}64 ^{and C}128^{, and let K´ denote the variant key K ^ K}f0 ^{(see Registered Encryption Key Types ). Then the checksum MD5-DES(K, P) is equal to DES-CBC(K´, P´´) (which is 192 bits long).}

• cksumType-CL-RPC = -32767

  Checksum used in the CL-RPC Conversation Manager protocol-see Conversation Manager out_data for details.

  Note:

  This checksum type is, strictly speaking, "unregistered" according to the convention stated in Checksums concerning negative values of CheckSumType. Note also that the value -32767 may be represented as the hexadecimal value 0x8001 in a 16-bit two's complement signed data type (for example, C short on typical implementations).

• cksumType-CO-RPC = -32766

  Checksum used in the CO-RPC protocol-see CO Verifier auth_value.credentials for details.

  Note:

  This checksum type is, strictly speaking, "unregistered" according to the convention stated in Checksums concerning negative values of CheckSumType. Note also that the value -32766 may be represented as the hexadecimal value 0x8002 in a 16-bit two's complement signed data type (for example, C short on typical implementations).

 

EncryptionType ::= INTEGER
EncKeyVersionNumber ::= INTEGER
CipherText ::= OCTET STRING

EncryptedData ::= SEQUENCE {
        encData-EncType    [0] EncryptionType,
        encData-KeyVersNum [1] EncKeyVersionNumber OPTIONAL,
        encData-CipherText [2] CipherText
}

• encData-EncType

  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):

  • Present, in the context of long-term keys K_A associated with principals A. (These are the keys stored in RS datastores.)

  • Absent, in the context of short-term session keys KA,B shared between principals A and B. (These are the keys transmitted in tickets; they are generated by KDS and PS servers.)

  • Optionally present (application-specific choice), in the context of short-term conversation keys K^A,B ^{and Kx^^'1xu'}A,B shared between principals A and B. (These are the negotiated "conversation keys" transmitted in authentication headers and reverse-authentication headers; they are generated by A and B, respectively.)

  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).

• encData-KeyVersNum

  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).

• encData-CipherText

  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.

• encType-TRIVIAL = 0

  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.

• encType-DES-CBC-CRC = 1

  Let K be an encryption key of type encKeyType-DES, and let P be a plaintext bit-message. Then the corresponding encData-CipherText, denoted:

   
  
  DES-CBC-CRC(K, P)
  
  

  is defined by the following pseudocode algorithm:

   
  
  R64 = RANDOM64();
  P' = <R64, 032, P>;
  C32 = CRC\z§32(032, P');
  P" = <R64, C32, P>;
  DES-CBC-CRC(K, P) = DES-CBC(K, P");
  
  
  

  In words: First generate a random 64-bit vector, R₆₄ (called a confounder when used in this context-see CBC Mode ). Let P´ denote P prepended with R₆₄ and with a 32-bit 0-vector (0₃₂), and let C₃₂ denote the 32-bit (twisted) checksum CRC^§₃₂(0, P´) with seed 0 (for padding, see Cyclic Redundancy Checksums ). Let P´´ denote P prepended with R₆₄ and C₃₂. Then the ciphertext DES-CBC-CRC(K, P) is equal to DES-CBC(K, P´´) (for initialisation vector and padding, see CBC Mode ).

• encType-DES-CBC-MD4 = 2

  Let K be an encryption key of type encKeyType-DES, and let P be a plaintext bit-message. Then the corresponding encData-CipherText, denoted:

   
  
  DES-CBC-MD4(K, P)
  
  

  is defined by the following pseudocode algorithm:

   
  
  R64 = RANDOM64();
  P' = <R64, 0128, P>;
  C128 = MD4(P');
  P" = <R64, C128, P>;
  DES-CBC-MD4(K, P) = DES-CBC(K, P");
  
  
  

  In words: First generate a random 64-bit vector, R₆₄ (called a confounder when used in this context-see CBC Mode ). Let P´ denote P prepended with R₆₄ and with a 128-bit 0-vector (0₁₂₈), and let C₁₂₈ denote the 128-bit checksum MD4(P´) (no padding is used here). Let P´´ denote P prepended with R₆₄ and C₁₂₈. Then the ciphertext DES-CBC-MD4(K, P) is equal to DES-CBC(K, P´´) (for initialisation vector and padding, see CBC Mode ).

• encType-DES-CBC-MD5 = 3

  Let K be an encryption key of type encKeyType-DES, and let P be a plaintext bit-message. Then the corresponding encData-CipherText, denoted:

   
  
  DES-CBC-MD5(K, P)
  
  

  is defined by the following pseudocode algorithm:

   
  
  R64 = RANDOM64();
  P' = <R64, 0128, P>;
  C128 = MD5(P');
  P" = <R64, C128, P>;
  DES-CBC-MD5(K, P) = DES-CBC(K, P");
  
  
  

  In words: First generate a random 64-bit vector, R₆₄ (called a confounder when used in this context-see CBC Mode ). Let P´ denote P prepended with R₆₄ and with a 128-bit 0-vector (0₁₂₈), and let C₁₂₈ denote the 128-bit checksum MD5(P´) (no padding is used here). Let P´´ denote P prepended with R₆₄ and C₁₂₈. Then the ciphertext DES-CBC-MD5(K, P) is equal to DES-CBC(K, P´´) (for initialisation vector and padding, see CBC Mode ).

• passWord

  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 sec_login_validate_identity() or sec_login_valid_and_cert_ident(). The mapping of character string to byte string by those routines is specified as follows (see Minimum Implementation Requirements ): they take as input PCS character strings, and map them to byte strings by mapping each character to a byte value according to the US ASCII mapping (or equivalently, for PCS characters, ISO 8859-1). (In particular, of course, upper-case letters are considered to be distinct from lower-case letters.)

• salt

  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:

  • cellName

    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.

  • rsName

    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 rsName₀, ···, rsName_r-1.

• CN

• RSN, with components RSN₀, ···, RSN_r-1

DEFAULTSALT = <CN, RSN₀, ···, RSN_r-1>

• encKeyType-TRIVIAL

  All passWords, cellNames and rsNames map to the unique (trivial) key of type encKeyType-TRIVIAL.

• encKeyType-DES

  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:

   
  
  PWS = <passWord, salt, 0, ···, 0>
  
  

  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:

   
  
  PWS = <PWS[0], ···, PWS[p-1]>
  
  

  where each PWS[j] has length 64 bits. The key K is then defined by the following pseudocode:

   
  
  K = <0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00>;
  for (j = 0; j <= p-1; j += 1) {
          if (j is even) {
                  K ^= PWS[j];
          } else {
                  K ^= REVERSE(PWS[j]);
          }
  }
  
  FIX-PARITY(K);
  K' = DES-CBC-CKSUM(K, PWS);
  FIX-PARITY(K');
  
  if (K' is weak or semi-weak) {
          K' ^= <0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xf0>;
          FIX-PARITY(K');
  }
  
  
  

  In words: First, initialise a 64-bit vector K by "fan-folding" PWS, as specified in the pseudocode above, where REVERSE() is the transformation that maps any bit-vector <b₀, ···, b_k-1> to its reversal, <b_k-1, ···, b₀>. This K may not be a DES key, because it may not have odd parity, so next adjust the parity bits of K so that it has odd parity (that's the definition of FIX-PARITY()). Then, apply the indicated DES-CBC checksum to K and PWS (thereby "uniformly distributing the password and salt over DES key space"), calling the result K´. Again, adjust the parity of K´. Finally, if K´ is a weak or semi-weak DES key, XOR it with the indicated constant (and adjust the parity again). The final output of this algorithm (the desired result of the password-to-key mapping), is the resulting K´.

  Note:

  Since this is a "public algorithm", it is not permissible to modify it to avoid the possibly-weak DES keys mentioned in Possibly Weak Keys , or other DES keys that may in the future be discovered to hold weaknesses. However, at a higher level, implementations are permitted (even encouraged) to reject passwords that would result in all DES keys that are weak in all known senses.

 

AuthnDataType ::= INTEGER
AuthnDataValue ::= OCTET STRING

AuthnData ::= SEQUENCE {
        authnData-Type  [1] AuthnDataType,
        authnData-Value [2] AuthnDataValue
}

 

AuthzDataType ::= INTEGER
AuthzDataValue ::= OCTET STRING

AuthzData ::= SEQUENCE OF SEQUENCE {
        authzData-Type  [0] AuthzDataType,
        authzData-Value [1] AuthzDataValue
}

 

Ticket ::= [APPLICATION 1] SEQUENCE {
        tkt-ProtoVersNum  [0] ProtocolVersionNumber,
        tkt-ServerCell    [1] CellName,
        tkt-ServerName    [2] RSName,
        tkt-EncryptedPart [3] EncryptedData
}

Its semantics have been described in Tickets, Keys, and Cross-Registration , where the notation Tkt_A,B for a ticket with named client A in cell X and targeted server B in cell Y are introduced (eliding, here, any issuing authority(ies), KDS_Z´, ···, KDS_Z´´ from the notation). In terms of this notation, its fields are the following:

• tkt-ProtoVersNum

  The protocol version number of the Ticket data type. Its value is protoVersNum-KRB5.

• tkt-ServerCell

  B's home cell, Y.

• tkt-ServerName

  B's RS name in RS_Y.

• tkt-EncryptedPart

  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 . The "pre-encrypted" plaintext of this field (which is a value of the data type TicketEncryptPart) is denoted by tkt-EncryptPart.

 

TicketEncryptPart ::= [APPLICATION 3] SEQUENCE {
        tkt-Flags         [ 0] TicketFlags,
        tkt-SessionKey    [ 1] EncryptionKey,
        tkt-ClientCell    [ 2] CellName,
        tkt-ClientName    [ 3] RSName,
        tkt-TransitPath   [ 4] TransitPath,
        tkt-AuthnTime     [ 5] TimeStamp,
        tkt-StartTime     [ 6] TimeStamp OPTIONAL,
        tkt-ExpireTime    [ 7] TimeStamp,
        tkt-MaxExpireTime [ 8] TimeStamp OPTIONAL,
        tkt-ClientAddrs   [ 9] HostAddresses OPTIONAL,
        tkt-AuthzData     [10] AuthzData OPTIONAL
}

• tkt-Flags

  Options (represented by flag bits) selected by this ticket. The TicketFlags data type is defined in detail in Ticket Flags . (In KDS Server Receives AS Request and Sends AS Response and KDS Server Receives TGS Request and Sends TGS Response , when a KDS server creates a ticket its options are considered to be deselected by default unless they are explicitly selected.)

• tkt-SessionKey

  The session key, K_A,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.

• tkt-ClientCell

  A's home cell, X.

• tkt-ClientName

  A's RS name in RS_X.

• tkt-TransitPath

  The transit path of this ticket.

• tkt-AuthnTime

  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, KDS_X, issued the original initial ticket-granting-ticket, Tkt_A,KDSX, on which Tkt_A,B is ultimately based, by a sequence of TGS Requests).

• tkt-StartTime

  The start time of this ticket; that is, the time before which Tkt_A,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 Tkt_A,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).

• tkt-ExpireTime

  The (relative) expiration time of this ticket; that is, the time after which Tkt_A,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).

  Note:

  Individual servers may decline to honour certain tickets which have not yet expired, depending on local policy.

• tkt-MaxExpireTime

  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 Tkt_A,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 Tkt_A,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).
  

• tkt-ClientAddrs

  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:

  • A server B must never deny service to a client A presenting a Tkt_A,B on the basis of A's "location" (that is, the transport address of the host from which A is communicating, as reported to B by its local host's operating system's implementation of the transport provider), provided that A's location is among the addresses indicated by Tkt_A,B's tkt-ClientAddrs (and, if applicable, Tkt_A,B has been properly proxied or forwarded-see Ticket Flags ).

  • On the other hand, if A's location is not among the addresses indicated by Tkt_A,B's tkt-ClientAddrs, then B may deny service, depending on B's policy.

  Thus, in the RFC 1510 environment, the decision by the target server B to honour such address restrictions is an optional server policy decision; that is, B may, depending on policy, choose to enforce or ignore the tkt-ClientAddrs field (possibly even on a per-client per-call basis). In the current DCE environment (that is, in environments conformant to DCE), this optionality has been removed, and the policy decision has been taken that the tkt-ClientAddrs field is never used to deny service: all servers B (including all system servers such as KDS and PS, and all application servers conforming to DCE) must always honour tickets Tkt_A,B having arbitrary host address fields tkt-ClientAddrs (provided they are otherwise acceptable), regardless of the location of the client A-with the sole exception that the KDS's AS service always requires clients to supply at least one host address in every AS Request (see the Note in Host Addresses ). (This policy decision could conceivably change in future revisions of DCE, though there is no current intent to do so. Therefore, in order to support an orderly transition to such a possible future environment, clients are encouraged to use the tkt-ClientAddrs field as specified herein with this in mind.)

  In particular, the HostAddressType field(s) of the HostAddresses data type (see Host Addresses ) are always ignored in the DCE environment. (This is the reason that references need not be supplied in DCE for the registered host address types listed in Registered Host Address Types .)

• tkt-AuthzData

  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).

The options that may be selected by a ticket, Tkt_A,B (that is, requested by the named client A, specified by issuing authority(ies), or interpreted by the targeted server B), are represented by the TicketFlags data type, which is defined as follows:

 

TicketFlags ::= BIT STRING {
        tkt-Forwardable (1),
        tkt-Forwarded   (2),
        tkt-Proxiable   (3),
        tkt-Proxied     (4),
        tkt-Postdatable (5),
        tkt-Postdated   (6),
        tkt-Invalid     (7),
        tkt-Renewable   (8),
        tkt-Initial     (9)
}

• tkt-Forwardable

  This Tkt_A,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 Tkt_A,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 Tkt_A,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.)

• tkt-Forwarded

  This Tkt_A,B has either itself been forwarded (see just above), or has been issued based on a ticket that had previously been forwarded.

• tkt-Proxiable

  This Tkt_A,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 Tkt_A,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 Tkt_A,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.)

• tkt-Proxied

  This Tkt_A,B has either itself been proxied (see just above), or has been issued based on a ticket that had previously been proxied.

• tkt-Postdatable

  This Tkt_A,B is postdatable; that is, this flag grants KDS servers the right to issue a postdated Tkt*_A,B based on Tkt_A,B. By a postdated Tkt*_A,B is meant a ticket that has substantially the same information in it as Tkt_A,B but with a new start time (tkt-StartTime).
  

• tkt-Postdated

  This Tkt_A,B has been postdated.

• tkt-Invalid

  This Tkt_A,B is invalid; that is, this flag grants KDS servers the right to issue a valid Tkt*_A,B based on Tkt_A,B. By a valid (or validated) Tkt*_A,B is meant a ticket that has substantially the same information in it as Tkt_A,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.

  Note:

  This flag is supported for security purposes-it does not introduce any new functionality that is not otherwise available. In order to be used effectively, it needs to be used with a "revocation" (or "hotlist") mechanism, which is not specified in this revision of DCE. Namely, use of this flag forces the KDS to be "visited" in order for a postdated ticket (which is always originally issued in an invalid state) to be rendered valid, thereby giving the KDS a timely opportunity to revoke tickets by checking them against the hotlist.

• tkt-Renewable

  This Tkt_A,B is renewable; that is, this flag grants KDS servers the right to issue a renewed Tkt*_A,B based on Tkt_A,B. By a renewed Tkt*_A,B is meant a ticket that has substantially the same information in it as Tkt_A,B but with a new (later) expiration time (tkt-ExpireTime).

  Note:

  This flag is supported for security purposes-it does not introduce any new functionality that is not otherwise available. In order to be used effectively, it needs to be used with a "revocation" (or "hotlist") mechanism, which is not specified in this revision of DCE. Namely, use of this flag forces the KDS to be "visited" before the absolute expiration time of tickets, thereby giving the KDS a timely opportunity to revoke tickets by checking them against the hotlist.

• tkt-Initial

  This Tkt_A,B is an initial ticket; that is, it was issued in response to an AS Request to A's home KDS_X. 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.

 

Authenticator ::= [APPLICATION 2] SEQUENCE  {
        authnr-ProtoVersNum    [0] ProtocolVersionNumber,
        authnr-ClientCell      [1] CellName,
        authnr-ClientName      [2] RSName,
        authnr-Cksum           [3] CheckSum OPTIONAL,
        authnr-ClientMicroSec  [4] MicroSecond,
        authnr-ClientTime      [5] TimeStamp,
        authnr-ConversationKey [6] EncryptionKey OPTIONAL,
        authnr-SeqNum          [7] SequenceNumber OPTIONAL,
        authnr-AuthzData       [8] AuthzData OPTIONAL
}

Its semantics are that it accompanies Tkt_A,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:

• authnr-ProtoVersNum

  The protocol version number of the Authenticator data type. Its value is protoVersNum-KRB5.

• authnr-ClientCell

  A's home cell.

• authnr-ClientName

  A's RS name in its cell.

• authnr-Cksum

  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.)

• authnr-ClientMicroSec

  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, CO Verifier auth_value.credentials ). It is the client's responsibility to store the timestamp and microsecond pairs <T, M> of all outstanding requests for which it remains interested in replies. It is also used by servers as a nonce to ensure they do not accept duplicate authenticators from the same client, because to do so risks a faked authentication due to "replay attacks" (which, incidentally, threaten authenticity only, not integrity or confidentiality, because they do not involve the compromise of a key). It is the server's responsibility to maintain a replay cache for this purpose, storing the timestamp and microsecondstamp pairs <T, M> from all authenticators it receives from all clients over the time interval 1T - S| <= maxClockSkew, where S is the server's system timestamp.

  Note:

  This timestamp-based technique for replay detection is not the only possible technique; for example, random-number-based "challenge/response" techniques for environments that do not want to rely on a time service. Such techniques are supported elsewhere in DCE.

• authnr-ClientTime

  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'."

• authnr-ConversationKey

  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 K_A,B in Tkt_A,B (tkt-SessionKey) is to be used as the conversation key. This is part of conversation key negotiation between A and B.

• authnr-SeqNum

  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).

• authnr-AuthzData

  Additional authorisation data included by A. This is authorisation data additional to that specified in the accompanying Tkt_A,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:

   
  
  if ((this application does not require tkt-AuthzData)
  1|  (tkt-AuthzData is present and grants access)) {
          if ((this application does not require authnr-AuthzData)
          1|  (authnr-AuthzData is present and grants access)) {
                  GRANT access;
          }
  } else {
          DENY access;
  }
  
  
  

 

AuthnHeader ::= [APPLICATION 14] SEQUENCE {
        authnHdr-ProtoVersNum    [0] ProtocolVersionNumber,
        authnHdr-ProtoMsgType    [1] ProtocolMessageType,
        authnHdr-Flags           [2] AuthnHeaderFlags,
        authnHdr-Tkt             [3] Ticket,
        authnHdr-EncryptedAuthnr [4] EncryptedData
}

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, Tkt_A,B (naming A and targeted to B), associated with one another. Its fields are the following:

• authnHdr-ProtoVersNum

  The protocol version number of the AuthnHeader data type. Its value is protoVersNum-KRB5.

• authnHdr-ProtoMsgType

  The kind of protocol message this AuthnHeader represents. Its value is protoMsgType-AUTHN-HEADER.

• authnHdr-Flags

  Selected authentication header options. The AuthnHeaderFlags data type is defined in Authentication Header Flags . In Client Sends Authentication Header , when a client creates an authentication header its options are considered to be deselected by default unless they are explicitly selected.

• authnHdr-Tkt

  The ticket, Tkt_A,B, associated with the client-server session that this authentication header is authenticating.

• authnHdr-EncryptedAuthnr

  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.

The options that may be selected by an authentication header (that is, specified by the client A named by Tkt_A,B (authnHdr-Tkt), or interpreted by the targeted server B) are represented by the AuthnHeaderFlags data type, which is defined as follows:

 

AuthnHeaderFlags ::= BIT STRING {
        authnHdr-UseSessionKey  (1),
        authnHdr-MutualRequired (2)
}

• authnHdr-UseSessionKey

  Usually (that is, if this option is deselected), Tkt_A,B is protected with B's long-term key, K_B. But if this option is selected, then the Tkt_A,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 The use-session-key Option (however, the explanation there is slight, since the use-session-key option is not used in the internal KDS protocol).

• authnHdr-MutualRequired

  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 Reverse-Authentication Headers ).

Recall (see Kerberos Key Distribution (Authentication) Service (KDS) ) that the basic Kerberos protocol for a client A to authenticate to a server B begins by having the client A obtain a session key K_A,KDS and a ticket, Tkt_A,KDS, from the AS, and then proceeds with the following series of exchanges (retaining here only those terms that are critical to the discussion at hand):

• A -> TGS: B, Tkt_A,KDS

• A <&#173; TGS: {B, K_A,B} Kx^[^^]'1xu'_A,KDS, Tkt_A,B

• A -> B: Tkt_A,B

• ··· and so on, ···

where Tkt_A,B = {A, K_A,B}K_B. The main point to focus on for the purposes of this discussion is that Tkt_A,B is protected with the long-term key K_B of B. This requires, in order for B to be able to decrypt Tkt_A,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 Tkt_A,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^* = K_B,KDS, as follows. Suppose that A has obtained a copy of B's (ticket-granting-)ticket, Tkt_B,KDS, (= {B, K_B,KDS}K_KDS); 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 Tkt_B,KDS to A, or B might have "published" its Tkt_B,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 -> TGS: B, Tkt_A,KDS, Tkt_B,KDS

• A <&#173; TGS: {K_A,B} Kx^[^^]'1xu'_A,KDS, Tkt^*_A,B

• A -> B: Tkt^*_A,B

• ··· and so on, ···

where Tkt_B,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 K_B,KDS (also denoted "K^*", without subscripts, in this context) that is used to protect Tkt^*_A,B; that is, Tkt^*_A,B = {A, K_A,B}K^*.

As presented in this brief discussion, the advantage of using Tkt^*_A,B instead of Tkt_A,B is by no means apparent. But it becomes a powerful tool when embedded in an overall architecture of so-called secret-key certificates (as opposed to public-key certificates), here implemented as tickets used in new ways, because it permits many of the advantages of public-key protocols to be implemented using secret-key encryption. The deeper exploration of this is, however, beyond the scope of this specification.

Reverse-Authentication Headers

 

RevAuthnHeader ::= [APPLICATION 15] SEQUENCE {
        revAuthnHdr-ProtoVersNum  [0] ProtocolVersionNumber,
        revAuthnHdr-ProtoMsgType  [1] ProtocolMessageType,
        revAuthnHdr-EncryptedPart [2] EncryptedData
}

 

RevAuthnHeaderEncryptPart ::= [APPLICATION 27] SEQUENCE {
        revAuthnHdr-ClientTime      [0] TimeStamp,
        revAuthnHdr-ClientMicroSec  [1] MicroSecond,
        revAuthnHdr-ConversationKey [2] EncryptionKey OPTIONAL,
        revAuthnHdr-SeqNum          [3] SequenceNumber OPTIONAL
}

• revAuthnHdr-ClientTime

  The corresponding authentication header's client timestamp (authnr-ClientTime).

• revAuthnHdr-ClientMicroSec

  The corresponding authentication header's client microsecondstamp (authnr-ClientMicroSec).
  

• revAuthnHdr-ConversationKey

  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 K_A,B in the corresponding authentication header's Tkt_A,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.

• revAuthnHdr-SeqNum

  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).

 

ASRequest ::= [APPLICATION 10] KDSRequest
TGSRequest ::= [APPLICATION 12] KDSRequest

KDSRequest ::= SEQUENCE {
        req-ProtoVersNum [1] ProtocolVersionNumber,
        req-ProtoMsgType [2] ProtocolMessageType,
        req-AuthnData    [3] SEQUENCE OF AuthnData OPTIONAL,
        req-Body         [4] KDSRequestBody
}

Its semantics are to indicate a calling client A's request to a KDS server KDS_Z to return a Tkt_A,B targeted to a server B (where B may be another KDS server, KDS_Z´). KDS servers (such as KDS_Z) support requests for the following two distinct kinds of services:

• Request for a "(manipulated) old" Tkt

  (Re-)issue a ticket that has substantially previously existed, by manipulating a presented ticket (in req-AuthnData). (A rigorous definition is given in Client Sends TGS Request .) The old ticket may be of almost any type (the exception being that ticket-granting-tickets cannot be proxied), and the manipulation may be any one of the following:

  • Validation

    Validate an (invalid) ticket.

  • Renewal

    Renew a (renewable) ticket.

  • Forwarding

    Forward a (forwardable) (ticket-granting- or service-)ticket.

  • Proxying

    Proxy a (proxiable) (non-ticket-granting-)service-ticket.

  Note:

  Some implementations may support the simultaneous combination of proxying and fowarding, because these do not really conflict with one another, but other combinations are more problematic (validation conflicts with forwarding/proxying, renewal conflicts with validation/fowarding/proxying), so an implementation that supported those combinations would have to specify their semantics (in an implementation-specific manner).

• Request for a "new" ticket

  Issue a ticket that hasn't substantially previously existed. (A rigorous definition is given in Client Sends TGS Request .) The new ticket may of any type (initial or subsequent, ticket-granting-ticket or service-ticket).

 

KDSRequestBody ::= SEQUENCE {
        req-Flags              [ 0] KDSRequestFlags,
        req-ClientName         [ 1] RSName OPTIONAL,
        req-ServerCell         [ 2] CellName,
        req-ServerName         [ 3] RSName,
        req-StartTime          [ 4] TimeStamp OPTIONAL,
        req-ExpireTime         [ 5] TimeStamp,
        req-MaxExpireTime      [ 6] TimeStamp OPTIONAL,
        req-Nonce              [ 7] Nonce,
        req-EncTypes           [ 8] SEQUENCE OF EncryptionType,
        req-ClientAddrs        [ 9] HostAddresses OPTIONAL,
        req-EncryptedAuthzData [10] EncryptedData OPTIONAL,
        req-AdditionalTkts     [11] SEQUENCE OF Ticket OPTIONAL
}

• req-Flags

  KDS options selected by this KDS Request (requested by the calling client A, or interpreted by the KDS server KDS_Z). The KDSRequestFlags data type is defined in KDS Request Flags . (In Client Sends AS Request to KDS and Client Sends TGS Request , when a client creates a KDS request its options are considered to be deselected by default unless they are explicitly selected.)

• req-ClientName

  A's RS name in its cell.

  Note:

  There is no field in KDSRequestBody for A's cell name -it is unnecessary according to the AS and TGS Request/Response protocols.)

• req-ServerCell

  B's cell.

• req-ServerName

  B's RS name in its cell.

• req-StartTime

  A's desired start time for a new postdated ticket.

• req-ExpireTime

  A's desired expiration time for a new ticket. The particular value endOfTimeStamp (see Timestamps, Microseconds, and Clock Skew ) is interpreted specially by the KDS server, namely as a request for a ticket with the largest expiration time it will issue, according to its policy.

  Note:

  This interpretation of endOfTimeStamp is not in RFC 1510.)

• req-MaxExpireTime

  A's desired absolute expiration time for a new renewable ticket.

  Note:

  For this field, endOfTimeStamp does not have a special interpretation.)

• req-Nonce

  Nonce generated by A (to be returned in KDS Response, defined in KDS (AS and TGS) Responses ).

• req-EncTypes

  A list of A's preferences of encryption types to be used to protect a new ticket.

• req-ClientAddrs

  A's desired client host addresses for a new (potentially proxiable and/or forwardable) ticket.

• req-EncryptedAuthzData

  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 Client Sends TGS Request and Client Sends PTGS Request for its use with the PS.) The "pre-encrypted" plaintext of this field (a value of the data type AuthzData) is denoted by req-EncryptAuthzData.

• req-AdditionalTkts

  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 Authentication Header Flags ). (Additional tickets are not used in the internal KDS protocol.)

 

KDSRequestFlags ::= BIT STRING {
        req-Forwardable   ( 1),
        req-Forward       ( 2),
        req-Proxiable     ( 3),
        req-Proxy         ( 4),
        req-Postdatable   ( 5),
        req-Postdate      ( 6),
        req-Renewable     ( 8),
        req-RenewableOK   (27),
        req-UseSessionKey (28),
        req-Renew         (30),
        req-Validate      (31)
}

 

ASResponse ::= [APPLICATION 11] KDSResponse
TGSResponse ::= [APPLICATION 13] KDSResponse

KDSResponse ::= SEQUENCE {
        resp-ProtoVersNum  [0] ProtocolVersionNumber,
        resp-ProtoMsgType  [1] ProtocolMessageType,
        resp-AuthnData     [2] AuthnData OPTIONAL,
        resp-ClientCell    [3] CellName,
        resp-ClientName    [4] RSName,
        resp-Tkt           [5] Ticket,
        resp-EncryptedPart [6] EncryptedData
}

 

ASResponseEncryptPart ::= [APPLICATION 25] KDSResponseEncryptPart
TGSResponseEncryptPart ::= [APPLICATION 26] KDSResponseEncryptPart

KDSResponseEncryptPart ::= SEQUENCE {
        resp-SessionKey    [ 0] EncryptionKey,
        resp-LastRequests  [ 1] LastRequests,
        resp-Nonce         [ 2] Nonce,
        resp-KeyExpireDate [ 3] TimeStamp OPTIONAL,
        resp-Flags         [ 4] TicketFlags,
        resp-AuthnTime     [ 5] TimeStamp,
        resp-StartTime     [ 6] TimeStamp OPTIONAL,
        resp-ExpireTime    [ 7] TimeStamp,
        resp-MaxExpireTime [ 8] TimeStamp OPTIONAL,
        resp-ServerCell    [ 9] CellName,
        resp-ServerName    [10] RSName,
        resp-ClientAddrs   [11] HostAddresses OPTIONAL
}

Its fields are the following. Note that most of this duplicates information that is present in the enclosed Tkt_A,B (resp-Tkt), so that A can check its conformance to what it had requested in the corresponding KDS Request (A cannot actually decrypt Tkt_A,B itself, unless A happens to know the long-term key of the targeted server B). (The only information in Tkt_A,B that is not repeated in KDSResponseEncryptPart are its transit path and authorisation data.)

• resp-SessionKey

  Duplicate of resp-Tkt's session key (tkt-SessionKey).

• resp-LastRequests

  Last request information that KDS_X (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.

• resp-Nonce

  Copy of the corresponding KDS Request's nonce (req-Nonce).
  

• resp-KeyExpireDate

  The time at which A's long-term key K_A (of the selected encryption type, held in RS_X) is scheduled to expire; that is, later than which (modulo maxClockSkew) KDS_X (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.
  

• resp-Flags

  Duplicate of resp-Tkt's ticket flags (tkt-Flags).

• resp-AuthnTime

  Duplicate of resp-Tkt's authentication time (tkt-AuthnTime).

• resp-StartTime

  Duplicate of resp-Tkt's start time, if present (tkt-StartTime).

• resp-ExpireTime

  Duplicate of resp-Tkt's expiration time (tkt-ExpireTime).

• resp-MaxExpireTime

  Duplicate of resp-Tkt's absolute expiration time, if present (tkt-MaxExpireTime).

• resp-ServerCell

  B's cell.

• resp-ServerName

  B's RS name in its cell.

• resp-ClientAddrs

  Duplicate of resp-Tkt's client host addresses, if present (tkt-ClientAddrs).

 

KDSError ::= [APPLICATION 30] SEQUENCE {
        err-ProtoVersNum   [ 0] ProtocolVersionNumber,
        err-ProtoMsgType   [ 1] ProtocolMessageType,
        err-ClientTime     [ 2] TimeStamp OPTIONAL,
        err-ClientMicroSec [ 3] MicroSecond OPTIONAL,
        err-ServerTime     [ 4] TimeStamp,
        err-ServerMicroSec [ 5] MicroSecond,
        err-StatusCode     [ 6] ErrorStatusCode,
        err-ClientCell     [ 7] CellName OPTIONAL,
        err-ClientName     [ 8] RSName OPTIONAL,
        err-ServerCell     [ 9] CellName,
        err-ServerName     [10] RSName,
        err-StatusText     [11] ErrorStatusText OPTIONAL,
        err-StatusData     [12] ErrorStatusData OPTIONAL
}

• Cell name

  This cell's name.

• KDS server's RS name

  RS name of the KDS server in this cell. If the cell name of this cell Z is, say, cellZ, then the RS_Z name of KDS_Z is krbtgt/cellZ.

• Supported protocol version numbers

  The protocol version numbers supported by KDS_Z {errStatusCode-BAD-PROTO-VERS-NUM}.

• Supported authentication methods

  The authentication methods supported by KDS_Z {errStatusCode-BAD-AUTHN-METHOD}.

• Supported authentication data types

  The authentication data types supported by KDS_Z {errStatusCode-AUTHN-DATA-TYPE-NOT-SUPPORTED}.

• Supported transit path types

  The transit path types supported by KDS_Z {errStatusCode-TRANSIT-PATH-TYPE-NOT-SUPPORTED}.

• Supported encryption key types

  The encryption key types supported by KDS_Z.

• Supported encryption types

  The encryption types supported by KDS_Z.

• Supported checksum types

  The checksum types supported by KDS_Z {errStatusCode-CHECKSUM-TYPE-NOT-SUPPORTED, errStatusCode-BAD-CHECKSUM-TYPE}.

• Per-end-principal RS names

  Entries for end-principals (that is, non-KDS-principals) stored in RS_Z's datastore.

• Per-foreign-KDS RS names

  Entries for KDS principals KDS_Z,Z´ from foreign cells Z´ cross-registered with cell Z. If the cell name of foreign cell Z´ is, say, cellZ´, then the RS_Z name of KDS_Z,Z´ is krbtgt/cellZ´ {errStatusCode-NOT-US}.

• Per-principal long-term key(s), with version numbers

  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 K_C {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}.

• Per-principal "salt"

  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 Registered Password-to-Key Mappings ).

• Conversation key negotiation

  Boolean indicating whether KDS_Z will accept client-supplied (in authentication headers, authnHdr-EncryptAuthnr.authnr-ConversationKey) conversation keys be used to protect client-KDS sessions, or KDS_Z will insist on supplying them itself (in reverse-authentication headers, revAuthnHdr-ConversationKey).

• Maximum clock skew

  Value(s) (certainly a cell-value one, though potentially also per-principal values) of maxClockSkew (see Timestamps, Microseconds, and Clock Skew ), such that the authentication protocols specified herein fail if the KDS (or PS) encounter a timestamp from a principal whose clock skew compared to the KDS's (or PS's) clock exceeds maxClockSkew {errStatusCode-CLOCK-SKEW}.

• Per-principal long-term key(s) expiration dates(s)

  The time later than which (modulo maxClockSkew) KDS_Z 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).

• Postdatability permitted

  Boolean indicating whether or not KDS_Z will issue new postdatable or postdated tickets {errStatusCode-CANNOT-POSTDATE}.

• Renewability permitted

  Boolean indicating whether or not KDS_Z will issue new renewable tickets.

• Proxiability permitted

  Boolean indicating whether or not KDS_Z will issue new proxiable tickets.

• Forwardability permitted

  Boolean indicating whether or not KDS_Z will issue new forwardable tickets.

• Cell-wide minimum ticket lifetime

  Minimum lifetime for which KDS_Z 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}.

• Cell-wide default ticket-granting-ticket lifetime

  Default lifetime for which KDS_Z will issue a new ticket-granting-ticket.

• Cell-wide maximum ticket lifetime

  Maximum lifetime for which KDS_Z will issue a new ticket.

• Per-principal maximum ticket lifetime

  Maximum lifetime for which KDS_Z will issue a new ticket naming or targeting a principal C.

• Cell-wide postdate maximum

  Furthest date in the future for which KDS_Z will issue a postdatable ticket naming or targeting a principal C.
  

• Per-principal postdate maximum

  Furthest date in the future for which KDS_Z will issue a postdatable ticket.

• Cell-wide maximum renewable ticket lifetime

  Maximum lifetime for which KDS_Z will issue a new renewable ticket (if it issues new renewable tickets at all).

• Per-principal maximum renewable ticket lifetime

  Maximum lifetime for which KDS_Z will issue a new renewable ticket naming or targeting a principal C (if it issues new renewable tickets at all).

• Client addresses

  Boolean indicating whether KDS_Z requires client addresses (tkt-ClientAddrs) to be present in all tickets.

• Per-principal last request(s)

  Last request(s) information maintained for C, per local policy.

• Replay cache

  Replay cache used by KDS_Z (see Authenticators ) {errStatusCode-REPLAY}.

• Hot list (revocation) information

  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 RS_Z's hot list. For example, whenever a hot-listed (revoked) ticket is presented to KDS_Z in (the req-AuthnData field of) a TGS Request, KDS_Z will refuse to honour it. (Note that when a ticket's maximum expiration time has passed, KDS_Z 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}.

• Next hops

  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 RS_Z. 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.

  A common next hop strategy is the following up-over-down algorithm. If the server requested by a client is not registered in Z, then the next hop is:

  1. the server's cell, if Z holds a direct cross-registration to the server's cell, otherwise

  2. the first ancestor cell (in the namespace sense) of the server's cell which is cross-registered with Z, if Z holds such a cross-registration, otherwise

  3. the parent cell of Z, if Z holds a cross-registration with it.

Consider a client A that wants to obtain an initial ticket, Tkt_A,B, from KDS_X, where X is A's home cell. (Usually, though not necessarily, an initial ticket is a ticket-granting-ticket; that is, the target server B will usually be KDS_X itself. In any case, B must be in cell X, or the AS Request will fail.) Then A prepares an AS Request, asReq (a value of the data type ASRequest), and "sends it" (that is, calls kds_request()) to KDS_X, according to the following algorithm. Note that it is A's responsibility to know (or to securely determine) all the information necessary to correctly formulate the AS Request message-especially, KDS_X's cell name and RS name (that's why "well-known principal names" (involving the component krbtgt) are used for KDS servers), as well as the RS names of A itself and of B. Since the AS Request is unauthenticated, KDS_X cannot know with certainty the principal identity of this calling client, A-in particular, A may request (or its request may be modified in transit) that the initial ticket in question be issued "in the name of" (that is, name) a client A´ other than A itself (though in that case the resulting Tkt_A´,KDSX will be unusable by A, unless A knows A´'s long-term key-except perhaps for cryptanalysis; for example, for an "offline dictionary attack").

• Protocol version number

  The protocol version number (asReq.req-ProtoVersNum) is set to protoVersNum-KRB5.

• Protocol message type

  The protocol message type (asReq.req-ProtoMsgType) is set to protoMsgType-AS-REQUEST.

• Client name

  The client name (asReq.req-Body.req-ClientName) is set to A's RS name in RS_X.

• Server cell

  The server cell (asReq.req-Body.req-ServerCell) is set to KDS_X'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.

• Server name

  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 = KDS_X, this RS name will be krbtgt/cellX, assuming that the cell name is cellX).
  

• Options

  • Forwardable

    If A desires that Tkt_A,B be forwardable, the forwardable option (asReq.req-Body.req-Flags.req-Forwardable) is selected.

  • Proxiable

    If A desires that Tkt_A,B be proxiable, the proxiable option (asReq.req-Body.req-Flags.req-Proxiable) is selected.

  • Postdatable

    If A desires that Tkt_A,B be postdatable, the postdatable option (asReq.req-Body.req-Flags.req-Postdatable) is selected.

  • Postdate

    If A desires that Tkt_A,B be postdated, the postdate option (asReq.req-Body.req-Flags.req-Postdate) is selected.

  • Renewable

    If A desires that Tkt_A,B be renewable, the renewable option (asReq.req-Body.req-Flags.req-Renewable) is selected.

  • Renewable-okay

    If A does not desire that Tkt_A,B be renewable, but A will nevertheless accept a renewable Tkt_A,B with a shorter lifetime than desired in lieu of no Tkt_A,B at all, then the renewable-okay option (asReq.req-Body.req-Flags.req-RenewableOK) is selected.

  • Other; use-session-key, validate, renew, proxy, forward

    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.

• Start time

  If the postdate option for Tkt_A,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.

• Expiration time

  The expiration time (asReq.req-Body.req-ExpireTime) is set to the desired expiration time for Tkt_A,B.

• Maximum expiration time

  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 Tkt_A,B. Otherwise, the maximum expiration time is omitted.

• Additional tickets

  The additional tickets field (asReq.req-Body.req-AdditionalTkts) is omitted.
  

• Nonce

  The nonce field (asReq.req-Body.req-Nonce) is set to a nonce value.

• Encryption types

  The encryption types field (asReq.req-Body.req-EncTypes) is set to the list of encryption types acceptable to A for protecting Tkt_A,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.)
  

• Client addresses

  If A desires that Tkt_A,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.

• Authorisation data

  The authorisation data field (asReq.req-Body.req-EncryptedAuthzData) is omitted.

• Authentication data

  The (pre-)authentication data (asReq.req-AuthnData) is (currently) omitted.

Consider an AS Request, asReq, received by KDS_X. That is, asReq is a value of type ASRequest, with protocol version number (asReq.req-ProtoVersNum) protoVersNum-KRB5 and protocol message type (asReq.req-ProtoMsgType) protoMsgType-AS-REQUEST. Denote by A the client requested (asReq.req-Body.req-ClientName) to be named in the to-be-issued initial Tkt_A,B. Then KDS_X executes the algorithm below. If the algorithm executes successfully, KDS_X prepares an AS Response (asResp, of type ASResponse) containing the newly issued initial Tkt_A,B (asResp.resp-Tkt) and "returns" it (that is, returns from the kds_request() invocation) to the calling client (which may be different from the requested client, A). If unsuccessful, KDS_X prepares a KDS Error (kdsErr, of type KDSError) and returns it to the calling client.

The following algorithm first discusses how KDS_X constructs Tkt_A,B-also denoted asTkt when the emphasis is on the details of AS Request processing-and then how it constructs the rest of the AS Response, asResp.

• Authentication data processing

  The (pre-)authentication data (asReq.req-AuthnData) is processed according to local policy (typically, it is absent).

• Protocol version number

  The new initial ticket's protocol version number (asTkt.tkt-ProtoVersNum) is set to protoVersNum-KRB5.

• Server cell

  The requested server cell name (asReq.req-Body.req-ServerCell) is checked to be X's cell name. (This is because KDS_X 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.)
  

• Server name

  The requested server name (asReq.req-Body.req-ServerName) is checked to be KDS_X's RS name. KDS_X copies this into the new initial ticket's server name (asTkt.tkt-ServerName). KDS_X also checks that it itself has a datastore entry in RS_X {errStatusCode-SERVER-UNKNOWN}.

• Client cell

  The client cell (asTkt.tkt-EncryptPart.tkt-ClientCell) is set to X's cell name (which must be A's cell name, too).

• Client name

  The requested client name (asReq.req-Body.req-ClientName) (that is, A's RS name) is checked to have a datastore entry in RS_X {errStatusCode-CLIENT-UNKNOWN}. KDS_X 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.

• Encryption types

  KDS_X 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}.

• Long-term key retrieval

  KDS_X retrieves A's most recent long-term key K_A (and its key version number, for the selected encryption type encType) from RS_X.

• Session key generation

  KDS_X generates a new (random) session key (of the selected encryption type, encType), K_A,KDSX, and copies it into Tkt_A,B's session key field (asTkt.tkt-EncryptPart.tkt-SessionKey).

• Authentication time

  Tkt_A,B's authentication time (asTkt.tkt-EncryptPart.tkt-AuthnTime) is set to KDS_X's system time.

• Start time

  If the requested start time (asReq.req-Body.req-StartTime) is absent, or if it indicates a time earlier than Tkt_A,B's authentication time (asTkt.tkt-EncryptPart.tkt-AuthnTime), then Tkt_A,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 Tkt_A,B's start time is set to the requested start time; if the postdate option is deselected, Tkt_A,B's start time is omitted (indicating a default to the authentication time) or is set to KDS_X's system time (see also the postdated and invalid options, below) {errStatusCode-POLICY}.

• Expiration time

  KDS_X sets Tkt_A,B's expiration time (asTkt.tkt-EncryptPart.tkt-ExpireTime) to the earliest of the following:

  • The requested expiration time (asReq.req-Body.req-ExpireTime).

  • Tkt_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.

  • Tkt_A,B's start time (or authentication time, if the start time is absent) plus the maximum ticket lifetime associated with the target server KDS_X.

  • Tkt_A,B's start time (or authentication time, if the start time is absent) plus the cell-wide maximum ticket lifetime associated with the issuing authority KDS_X.

  KDS_X checks that the resulting lifetime of Tkt_A,B is greater than or equal to the cell-wide minimum ticket lifetime associated with the issuing authority KDS_X {errStatusCode-NEVER-VALID}.

• Maximum expiration time

  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 Tkt_A,B's expiration time is earlier than the requested expiration time, then Tkt_A,B's maximum expiration time (asTkt.tkt-EncryptPart.tkt-MaxExpireTime) is present (otherwise it is omitted) and is set to the earliest of:

  • The requested maximum expiration time (asReq.req-Body.req-MaxExpireTime), if present; otherwise, the requested expiration time (asReq.req-Body.req-ExpireTime).

  • Tkt_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.

  • Tkt_A,B's start time (or authentication time, if the start time is absent) plus the maximum renewable ticket lifetime associated with the target server KDS_X.

  • Tkt_A,B's start time (or authentication time, if the start time is absent) plus the cell-wide maximum renewable ticket lifetime associated with the issuing authority KDS_X.

• Transit path

  Tkt_A,B's transit path (asTkt.tkt-EncryptPart.tkt-TransitPath) is omitted.

• Client addresses

  Tkt_A,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.

• Authorisation data

  KDS_X checks that the requested authorisation data asReq.req-Body.req-EncryptedAuthzData) is omitted. (Since the AS Request is unauthenticated, KDS_X cannot vouch for such authorisation data.) Tkt_A,B's authorisation data field (asTkt.tkt-EncryptPart.tkt-AuthzData) is omitted.

• Additional tickets

  KDS_X checks that no additional tickets (asReq.req-Body.req-AdditionalTkts) are present.

• Options

  • Forwardable

    If the forwardable option (asReq.req-Body.req-Flags.req-Forwardable) has been requested and if forwardability is permitted by KDS_X, then Tkt_A,B's forwardable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Forwardable) is selected.

  • Proxiable

    If the Proxiable option (asReq.req-Body.req-Flags.req-Proxiable) has been requested and if proxiability is permitted by KDS_X, and if B != KDS_X, then Tkt_A,B's proxiable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Proxiable) is selected. (If B = KDS_X, then this AS request is denied, because ticket-granting-tickets are not proxiable.)

  • Postdatable

    If the postdatable option (asReq.req-Body.req-Flags.req-Postdatable) has been requested and if postdatability is permitted by KDS_X, then Tkt_A,B's postdatable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdatable) is selected.

  • Postdated

    If Tkt_A,B's start time is present, then Tkt_A,B's postdated option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Postdated) is selected.

  • Invalid

    If Tkt_A,B's postdated option is selected (above), then Tkt_A,B's invalid option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid) is selected.

  • Renewable, renewable-okay

    If Tkt_A,B's maximum expiration time is present and if renewability is permitted by KDS_X, then Tkt_A,B's renewable option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Renewable) is selected.

  • Other; use-session-key, validate, renew, proxy, forward

    KDS_X 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}.

  • Initial

    Tkt_A,B's initial option (asTkt.tkt-EncryptPart.tkt-Flags.tkt-Initial) is selected. (This marks Tkt_A,B as an initial ticket.)

  • Other; proxied, forwarded

    All of Tkt_A,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.

• Encryption

  KDS_X encrypts asTkt.tkt-EncryptPart using KDS_X's long-term key K_KDSX (of the chosen encryption type encType, and key version number). This is the ciphertext portion of Tkt_A,B (asTkt.tkt-EncryptedPart.encData-CipherText). KDS_X also sets the encryption type (asTkt.tkt-EncryptedPart.encData-EncType) to encType and the key version number (asTkt.tkt-EncryptedPart.encData-KeyVersNum) to K_KDSX's version number.

At this point, Tkt_A,B is well-formed, and KDS_X turns its attention to completing the construction of the AS Response message, asResp.

• Protocol version number

  The protocol version number (asResp.resp-ProtoVersNum) is set to protoVersNum-KRB5.

• Protocol message type

  The protocol message type (asResp.resp-ProtoMsgType) is set to protoMsgType-AS-RESPONSE.

• Authentication data

  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 Registered Password-to-Key Mappings ).

• Client cell

  The client cell (asResp.resp-ClientCell) is set to Tkt_A,B's client cell (asTkt.tkt-EncryptPart.tkt-ClientCell).

• Client name

  The client name (asResp.resp-ClientName) is set to Tkt_A,B's client name (asTkt.tkt-EncryptPart.tkt-ClientName).

• Ticket

  The ticket (asResp.resp-Tkt) is set to the newly created Tkt_A,B (asTkt).

• Session key

  The session key (asResp.resp-EncryptPart.resp-SessionKey) is set to Tkt_A,B's session key, K_A,KDSX (asTkt.tkt-EncryptPart.tkt-SessionKey).

• Nonce

  The nonce (asResp.resp-EncryptPart.resp-Nonce) is set to the nonce that the calling client sent (asReq.req-Body.req-Nonce).

• Client addresses

  The client address field (asResp.resp-EncryptPart.resp-ClientAddrs) is set to Tkt_A,B's client address field (asTkt.tkt-EncryptPart.tkt-ClientAddrs), if present. Otherwise, it is omitted.

• Server cell

  The server cell (asResp.resp-EncryptPart.resp-ServerCell) is set to Tkt_A,B's server cell (asTkt.tkt-ServerCell).

• Server name

  The server name (asResp.resp-EncryptPart.resp-ServerName) is set to Tkt_A,B's server name (asTkt.tkt-ServerName).

• Authentication time

  The authentication time (asResp.resp-EncryptPart.resp-AuthnTime) is set to Tkt_A,B's authentication time (asTkt.tkt-EncryptPart.tkt-AuthnTime).

• Start time

  The start time (asResp.resp-EncryptPart.resp-StartTime) is set to Tkt_A,B's start time (asTkt.tkt-EncryptPart.tkt-StartTime), if present. Otherwise, it is omitted.

• Expiration time

  The expiration time (asResp.resp-EncryptPart.resp-ExpireTime) is set to Tkt_A,B's expiration time (asTkt.tkt-EncryptPart.tkt-ExpireTime).
  

• Maximum expiration time

  The maximum expiration time (asResp.resp-EncryptPart.resp-MaxExpireTime) is set to Tkt_A,B's maximum expiration time (asTkt.tkt-EncryptPart.tkt-MaxExpireTime), if present. Otherwise, it is omitted.

• Key expiration date

  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), K_A.

• Last requests

  The last requests field (asResp.resp-EncryptPart.resp-LastRequests) is set to A's last requests information.

• Options

  The options (asResp.resp-EncryptPart.resp-Flags) are set to Tkt_A,B's options (asTkt.tkt-EncryptPart.tkt-Flags).

• Encryption

  KDS_X encrypts asResp.resp-EncryptPart using A's long-term key K_A (using the chosen encryption type encType). This is the ciphertext portion of the AS Response (asResp.resp-EncryptedPart.encData-CipherText). KDS_X 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.

Consider a client A that receives an AS Response, asResp (that is, asResp is a value of type ASResponse, with protocol version number (asResp.resp-ProtoVersNum) protoVersNum-KRB5 and protocol message type (asResp.resp-ProtoMsgType) protoMsgType-AS-RESPONSE), in response to an AS Request, asReq (as the result of calling kds_request()) to KDS_X. Then A processes asResp according to the following algorithm. In the case this algorithm completes successfully, A is justified in believing that the returned Tkt_A,B (or asTkt; that is, asResp.resp-Tkt) is correctly and securely targeted to KDS_X, and that it contains the values returned elsewhere in asResp (in particular, that A is the client named by Tkt_A,B), and using it (especially, its session key, K_A,KDSX) in subsequent TGS Requests and Authentication Headers it sends to KDS_X. In the case the algorithm fails, A takes (application-specific) recovery action.

Here, the notions of "success" or "failure" of this algorithm are taken to mean "conforming to A's request (asReq)", where the criteria of "conformance" are application-specific. Typically, but not necessarily, A will be satisfied only if KDS_X formulates Tkt_A,B exactly as A requested. For example, A may have requested a very long maximum expiration time but KDS_X issued only a somewhat shorter one-whether A views that as a success or failure is an application-specific determination. (Note that A cannot inspect Tkt_A,B directly, because A cannot decrypt it -A has to rely on the other, unencrypted, fields of the AS Response message.)

• Client cell

  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 KDS_X).

• Client name

  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.

• Authentication data

  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, K_A, from its password and the included salt (asResp.resp-AuthnData[i].authnData-Value) (see Registered Password-to-Key Mappings ). If the authentication data is absent, then the client derives its long-term key from its password and the default salt (see Registered Password-to-Key Mappings ).

• Ticket

  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.

• Decryption

  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 K_A (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 KDS_X (since A trusts its long-term key K_A to be secure), and that it is not being spoofed by a counterfeit KDS_X). 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, K_A,KDSX (asResp.resp-EncryptPart.resp-SessionKey)).

  Note:

  This assumes (as stated) that A trusts its long-term key K_A. In the terminology of the Login Facility (see Login Facility and Security Client Daemon (SCD) ), the successful decryption of asResp.resp-EncryptedPart.encData-CipherText amounts to "validation of Tkt_A,B". In order for arbitrary other parties (other than A) to become convinced of the genuineness of Tkt_A,B, the subtler protocols involved in "certification of Tkt_A,B" (see Further Discussion of Certification ) must be employed.

• Nonce

  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.

• Last requests

  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.

• Key expiration date

  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 RS Editor RPC Interfaces ). Typically, this will involve A's "changing its password"-a comparatively "cheap" undertaking. Failure to do so risks A's long-term key K_A, and hence its password, actually expiring, which would require A to re-register itself with RS_X (for encryption type encType) -a comparatively "expensive" undertaking in itself, in addition to the lost opportunities for service access while the long-term key is expired.

• Server cell

  The server cell (asResp.resp-EncryptPart.resp-ServerCell) is checked for conformance to what A requested (asReq.req-Body.req-ServerCell); that is, to KDS_X's cell name, or to X's cell name.

• Server 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 KDS_X's RS name.

• Session key

  The session key (which A trusts is secure), K_A,KDSX (asResp.resp-EncryptPart.resp-SessionKey), is saved for later use in protecting communications with KDS_X; that is, subsequent TGS Requests.

• Authentication time

  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)).

• Start time

  The start time (asResp.resp-EncryptPart.resp-StartTime) is checked for conformance to what A requested. Namely, if A requested Tkt_A,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.

• Expiration time

  The expiration time (asResp.resp-EncryptPart.resp-ExpireTime) is checked for conformance to what A requested (asReq.req-Body.req-ExpireTime).

• Maximum expiration time

  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).
  

• Client addresses

  If A requested that Tkt_A,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.

• Options

  The options field (asResp.resp-EncryptPart.resp-Flags) is inspected for conformance to what A requested (asReq.req-Body.req-Flags).

Notes:

1. It should be noted that the descriptions here are "typical" of authentication/reverse-authentication header processing. But since the interpreters (A and B) of the authentication/reverse-authentication headers are in general application-specific, this whole discussion should be understood to implicitly accommodate some such wording as "··· or other such processing as the application requires or allows ···". For example, an especially cautious server may refuse to accept proxied tickets, or an especially lenient one may provide a "grace period" during which it will accept tickets that expire during a session. Another example is that a password-changing program might demand an initial ticket, to guard against the possibility of a miscreant's hijacking a user session by simply sitting down at an unattended seat. See also TGS Request/Response Processing , which is the only place authentication/reverse-authentication headers are used internally in the KDS protocol "application".

2. The presentation of Client Sends Authentication Header through Client Receives Reverse-Authentication Header is cast in terms of: "client A using Tkt_A,B (with session key K_A,B) to authenticate to server B". It will be observed, though, that a third principal A´ could be injected into the discussion, and the whole presentation recast as: "client A using Tkt_A´,B (with session key K_A´,B) to authenticate to server B, provided that A knows the session key K_A´,B". This notation becomes burdensome to the exposition, so it won't be employed here. Far from being a minor consequence of the authentication architecture, systematic use of this idea is central to the privilege architecture (with A´ = PS, the Privilege Server-see Introduction to Security Services and Privilege (Authorisation) Services ).

Consider a client A in cell X which has successfully executed a KDS Request (.Fn kds_request ), that is, whose KDS Response it accepts (in the sense of Client Receives AS Response and/or Client Receives TGS Response ). Thus, A is in possession of a Tkt_A,B received from KDS_Y, kdsTkt, whose contents it knows, especially its session key K_A,B (and its encryption type encType), and now A wants to use Tkt_A,B to "authenticate to" (that is, engage in protected communications with) server B in cell Y. The following algorithm specifies how A prepares an authentication header, authnHdr (a value of the AuthnHeader data type) containing Tkt_A,B (authnHdr.authnHdr-Tkt), and a newly generated authenticator authnr (authnHdr.authnHdr-EncryptAuthnr, of type Authenticator), and sends it to B for this purpose.

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.

• Protocol version number

  The protocol version number (authnr.authnr-ProtoVersNum) is set to protoVersNum-KRB5.

• Client cell

  The client cell (authnr.authnr-ClientCell) is set to A's cell name; that is, to X's cell name.

• Client name

  The client name (authnr.authnr-ClientName) is set to A's RS name.

• Client timestamp

  The client timestamp (authnr.authnr-ClientTime) is set to A's system time.

• Client microsecondstamp

  The client microsecond stamp (authnr.authnr-ClientMicroSec) is set to A's system microsecond time.

• Conversation key

  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 KDS_Y-generated session key K_A,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 K_A,B, K^_A,B and Kx^^`1xu`_A,B all have the same encryption type, encType.)

• Checksum

  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 Protected RPC .)
  

• Sequence number

  The sequence number (authnr.authnr-SeqNum) is processed in an application-specific manner (perhaps omitting it).

• Authorisation data

  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.

• Encryption

  A encrypts authnr, using the encryption type encType and the session key K_A,B (not the conversation key K^_A,B, even if present) in the accompanying Tkt_A,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).

• Protocol version number

  The protocol version number (authnHdr.authnHdr-ProtoVersNum) is set to protoVersNum-KRB5.

• Protocol message type

  The protocol message type (authnHdr.authnHdr-ProtoMsgType) is set to protoMsgType-AUTHN-HEADER.

• Ticket

  The ticket (authnHdr.authnHdr-Tkt) is set to Tkt_A,B (kdsTkt).

• Authenticator

  The encrypted authenticator (authnHdr.authnHdr-EncryptedAuthnr) is set to the encryption of authnr as constructed above.

• Options

  • Use-session-key

    If the accompanying Tkt_A,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 K_B, then the use-session-key option (authnHdr.authnHdr-Flags.authnHdr-UseSessionKey) is selected (see The use-session-key Option ).

  • Mutual authentication

    If A desires that B return a reverse-authentication header with its response, the mutual authentication option (authnHdr.authnHdr-Flags.authnHdr-MutualRequired) is selected.

  • Other

    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.

Consider an authentication header, authnHdr, received by a server, B in cell Y, containing a Tkt_A,B (ahTkt, authnHdr.authnHdr-Tkt) and an authenticator, authnr (authnHdr.authnHdr-EncryptAuthnr). (For example, KDS servers receive such an authentication header in the first authentication data field of a TGS Request (tgsReq.req-AuthnData[0].authnData-Value, with tgsReq.req-AuthnData[0].authnData-Type = authnDataType-TGS-REQ)-see KDS Server Receives TGS Request and Sends TGS Response .) Thus, authnHdr is a value of type AuthnHeader, with protocol version number (authnHdr.authnHdr-ProtoVersNum) protoVersNum-KRB5 and protocol message type (authnHdr.authnHdr-ProtoMsgType) protoMsgType-AUTHN-HEADER. Then B executes the algorithm below. If the algorithm executes successfully, B is justified in believing that it can at this time engage in secure communications with the client A named in Tkt_A,B, protecting their communications with the session key K_A,B carried in Tkt_A,B, or with the conversation key K^_A,B carried in the authentication header itself (authnHdr.authnHdr-EncryptAuthnr.authnr-ConversationKey) (or with another conversation key, Kx^^'1xu'_A,B, of B's own choosing-see below). That is, the authentication header "authenticates the client A to the server B".

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.

• Authentication header options:

  • Use-session-key

    If the use-session-key option (authnHdr.authnHdr-Flags.authnHdr-UseSessionKey) is deselected, B knows that ahTkt is protected with its long-term key K_B. If it is selected, B knows that ahTkt is protected with a session key, K^* (see The use-session-key Option ).

  • Mutual authentication

    If the mutual authentication option (authnHdr.authnHdr-Flags.authnHdr-MutualRequired) is selected, B knows A expects a reverse-authentication header to be returned.

• Ticket protocol version number

  The protocol version number (ahTkt.tkt-ProtoVersNum) is checked to be protoVersNum-KRB5.

• Ticket server cell

  The server cell (ahTkt.tkt-ServerCell) is checked to be the name of B's cell; that is, Y's cell name.

• Ticket server name

  The server name (ahTkt.tkt-ServerName) is checked to be B's RS name.

• Ticket decryption

  The encryption type protecting Tkt_A,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 K_B to attempt to decrypt Tkt_A,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 Tkt_A,B, in particular its session key K_A,B (ahTkt.tkt-EncryptPart.tkt-SessionKey).

• Authenticator decryption

  The encryption type protecting the authenticator (authnHdr.authnHdr-EncryptedAuthnr.encData-EncType) is checked to be the same as that protecting Tkt_A,B, namely encType. B decrypts the authenticator's ciphertext (authnHdr.authnHdr-EncryptedAuthnr.encData-CipherText) using the session key K_A,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 K_A,B; that is, this is what actually "authenticates" A to B. In this way, B learns the information carried in authnr (authnHdr.authnHdr-EncryptAuthnr).

• Authenticator protocol version number

  The authenticator's protocol version number (authnr.authnr-ProtoVersNum) is checked to be protoVersNum-KRB5.

• Client cell

  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).

• Client 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).

• Client addresses

  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.

• Client timestamp

  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.

• Client microsecondstamp

  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.

• Authentication time

  The authentication time (ahTkt.tkt-EncryptPart.tkt-AuthnTime) is typically ignored by application-level servers (see TGS Request/Response Processing for the case of KDS servers).

• Start time

  The start time (ahTkt.tkt-EncryptPart.tkt-StartTime) is checked to be earlier than or equal to B's system time (modulo maxClockSkew).
  

• Expiration time

  The expiration time (ahTkt.tkt-EncryptPart.tkt-ExpireTime) is checked to be later than or equal to B's system time (modulo maxClockSkew).

• Maximum expiration time`

  The maximum expiration time (ahTkt.tkt-EncryptPart.tkt-MaxExpireTime) is typically ignored by application-level servers (see TGS Request/Response Processing for the case of KDS servers).

• Sequence number

  The sequence number (authnr.authnr-SeqNum) is processed in an application-specific manner.

• Conversation key

  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 K_A,B or will generate its own conversation key Kx^^'1xu'_A,B for this purpose (informing A of it in the accompanying revAuthnHdr).

• Transit path

  The transit path (ahTkt.tkt-EncryptPart.tkt-TransitPath) is typically ignored by application-level servers (see TGS Request/Response Processing for the case of KDS servers, and PTGS Request/Response Processing for the case of PS servers).

• Checksum

  If a checksum (authnr.authnr-Cksum) is present, it is processed in an application-specific way.

• Ticket options:

  • Invalid

    The invalid option (ahTkt.tkt-EncryptPart.tkt-Flags.tkt-Invalid) is typically checked by application-level servers to be deselected (see TGS Request/Response Processing for the case of KDS servers).

  • Forwardable, forwarded, proxiable, proxied, postdatable, postdated, renewable, initial

    All other options are ignored by application-level servers (see TGS Request/Response Processing for the case of KDS servers). 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).

• Ticket authorisation data

  If ticket authorisation data (ahTkt.tkt-EncryptPart.tkt-AuthzData) is present, B uses it (in an application-specific way) to make authorisation decisions.

• Authenticator authorisation data

  If additional authenticator authorisation data (authnr.authnr-AuthzData) is present, B uses it (in an application-specific way) to make authorisation decisions.