Protected RPC

This chapter specifies how the security services specified in the preceding chapters are supported by the DCE RPC facility, thereby presenting a simplified programming model of security services to RPC programmers and securing applications against many passive and active network attacks.

This chapter depends strongly on the referenced Open Group DCE 1.1 RPC Specification. The reader of this chapter is assumed to have detailed familiarity with that specification (especially its Chapters 12 and 13 and Appendix P, including the notation established there), since this chapter does not review the information available there. Also, for the cyclic redundancy checksum CRC^§₃₂ used in this chapter, see CRC-32 .

The following list specifies all currently supported RPC protocols, authentication protocols and authorisation types; this whole chapter is therefore restricted to these only:

• RPC protocols

  • Connectionless (CL) RPC protocol.

  • Connection-oriented (CO) RPC protocol.

• Authentication protocols

  • None (dce_c_rpc_authn_protocol_none); that is, "unprotected RPC".

  • Kerberos (dce_c_rpc_authn_protocol_krb5); that is, "protected RPC", of various protection levels (see Protected RPC ).

• Authorisation types

  • Name-based (dce_c_authz_name).

  • PAC-based (dce_c_authz_dce).

What is Specified in this Chapter

Recall that all RPC PDUs, as specified in the referenced Open Group DCE 1.1 RPC Specification (for both the CL and CO protocols), can be regarded as bit-vectors (actually, byte-vectors-see below) having a common structure, which in this chapter will be denoted:

 

PDU = <H, B, V>

where:

• H is the PDU's header. It is metadata, describing the actual data carried by the PDU, and is never empty.

• B is the PDU's body bgcolor="#FFFFFF". It embodies the actual data carried by the PDU, and may be empty. It consists of IDL-defined NDR-marshalled data, generated by a client or server stub or by the RPC runtime itself -possibly encrypted, as specified in this chapter.

• V is the PDU's (authentication/security) verifier. It represents the security attributes of the PDU, and may be empty.

Each of H, B and V is actually a byte-sequence (that is, has bit-length a non-negative integral multiple of 8); they are henceforth always regarded as byte-sequences, not bit-sequences. In particular, the length of such a (byte-)vector M henceforth in this chapter, will always mean its length in bytes, and denoted as:

 

Lambda(M)

(as opposed to lambda(M), which denotes length in bits; that is, lambda(M) = 8·Lambda(M)).

The referenced Open Group DCE 1.1 RPC Specification also specifies alignment rules for PDUs, as part of its definitions of H, B and V (these rules are not repeated here).

The verifier V is said to be present in a given PDU if it has length > 0. The referenced Open Group DCE 1.1 RPC Specification specifies the conditions under which V is present and B (if present) is encrypted (that is, B is the ciphertext of a corresponding plaintext raw body bgcolor="#FFFFFF" R, which itself generally consists of IDL-defined NDR-marshalled data), namely:

• CL case

  V is present if and only if H.auth_proto != dce_c_rpc_authn_protocol_none; that is, if and only if (currently) H.auth_proto = dce_c_authn_level_protocol_krb5. In that case, V is represented by the data type auth_verifier_cl_t. Further, B is encrypted if and only if V.protection_level = dce_c_authn_level_privacy.

• CO case

  V is present if and only H.auth_length (= Lambda(V)) is > 0. In that case, V is represented by the data type auth_verifier_co_t, with V.auth_type != dce_c_rpc_authn_protocol_none; that is, with (currently) V.auth_type = dce_c_rpc_authn_protocol_krb5. Further, B is encrypted if and only if V.auth_level = dce_c_authn_level_privacy.

The conditions under which all PDU types are transmitted are completely specified in the referenced Open Group DCE 1.1 RPC Specification, and there is nothing further to say about that in this chapter. The formats and contents of all PDU types (that is, their headers, bodies and verifiers) are also completely specified in the referenced Open Group DCE 1.1 RPC Specification, except for certain security-related items-those were explicitly deferred to this specification, and it is the specification of them that forms the contents of this chapter.

Namely, the following is an exhaustive list of the RPC security-related material that was deferred from the referenced Open Group DCE 1.1 RPC Specification to this specification, and is to be specified in this chapter:

• Establishment of credentials

  As specified in the referenced Open Group DCE 1.1 RPC Specification, credentials (authentication and authorisation information) are established in different ways in the CL and CO cases. Thus, the following need to be specified, in both the dce_c_authz_name and dce_c_authz_dce cases:

  • CL case

    The in_data and out_data parameters of the conv_who_are_you_auth() conversation manager operation (these parameters are part of the bodies of the corresponding conv_who_are_you_auth() request and response PDUs) need to be specified.

  • CO case

    The verifier field V.auth_value needs to be specified for bind, bind_ack, alter_context and alter_context_response PDUs, provided that H.auth_length > 0.

  
  

• Integrity protection

  RPC integrity protection is implemented by cryptographic checksums of PDU headers and bodies, carried in PDU verifiers. Thus:

  • CL case

    The verifier field V.auth_value needs to be specified when V.protection_level is one of: dce_c_authn_level_pkt, dce_c_authn_level_integrity or dce_c_authn_level_privacy.

  • CO case

    The verifier field V.auth_value needs to be specified when V.auth_level is one of: dce_c_authn_level_pkt, dce_c_authn_level_integrity or dce_c_authn_level_privacy.

• Confidentiality (privacy) protection

  RPC confidentiality (privacy) protection is implemented by encrypting PDU bodies. Thus:

  • CL case

    The body bgcolor="#FFFFFF" B needs to be specified when V.protection_level = dce_c_authn_level_privacy.

  • CO case

    The body bgcolor="#FFFFFF" B needs to be specified when V.auth_level = dce_c_authn_level_privacy.

These will now be specified, first in the CL case (.cX sec8-2 ), then in the CO case Security in the CO RPC Protocol ).

Security in the CL RPC Protocol

This section specifies the security-related material listed in What is Specified in this Chapter for the CL protocol.

CL Establishment of Credentials (Conversation Manager)

See Section 13.3.3, Conversation Manager Encodings, of the referenced Open Group DCE 1.1 RPC Specification for an explanation of when the conversation manager protocol is invoked. In particular, recall that conv_who_are_you_auth() is used as an "(RPC) callback" that is triggered by an "original (application-level) RPC"; that is, the invoker of conv_who_are_you_auth() is actually an application-level server, and the invokee is an application-level client which is in the process of invoking an original application-level RPC request to an application-level server-that is what triggers the conv_who_are_you_auth() callback. (Thus, the words "client" and "server" as used in this section refer to these application-level entities, as opposed to the system-level invoker and invokee of the conv_who_are_you_auth() callback.)

Conversation Manager in_data

The conversation manager in_data parameter has as its value the following 12-byte vector:

 

<key_seq_num, challenge>

Its components have the following formats and semantics:

• Key version number

  The field in_data.key_seq_num is a 4-byte value, big/big-endian representing an encryption key version number (an integer), as specified in Encrypted Data . Its value must be in the range [0, 255], despite the fact that this field could potentially hold values in a larger range. (This is because it is stored elsewhere in the CL RPC protocol in an 8-bit field-see Section 13.3.4, Authentication Verifier Encodings, referenced Open Group DCE 1.1 RPC Specification.) Its semantics are that it indicates the key version number to be used to "respond to this challenge"; that is, to construct the out_data response-see Conversation Manager out_data .

• Challenge

  The field in_data.challenge is an 8-byte value representing a nonce value (see Nonces ). Its semantics are that it indicates a nonce to be used by the original RPC server to match this in_data request message with its corresponding out_data response message (see Conversation Manager out_data ).

Conversation Manager out_data

The conversation manager out_data parameter represents an authentication header (that is, a value of type AuthnHeader as specified in Authentication Headers ) or a privilege authentication header (that is, a value of data type PAuthnHeader as specified in Privilege Authentication Headers ), with the supplements indicated below. (Note that the client sends an AuthnHeader or PAuthnHeader in out_data according to its original RPC request specified authorisation type dce_c_authz_name or dce_c_authz_dce, respectively.) In particular, the field out_data.authnHdr-Tkt carries a ticket that authenticates the client to the server.

• Options

  The field out_data.authnHdr-Flags contains no selected options.
  

• Conversation key

  The field out_data.authnHdr-EncryptAuthnr.authnr-ConversationKey is omitted.

  Note:

  The key subfield of the checksum value field (out_data.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Value- see below) carries a conversation key. Historically, the CL RPC protocol was defined before the conversation key negotiation challenge/response capability was added to the Kerberos RFC 1510 protocol (by means of the conversation keys, "K^" and "K^^", of the Kerberos authentication header and reverse-authentication header; see Authenticators and Reverse-Authentication Headers ).

• Sequence number

  The field out_data.authnHdr-EncryptAuthnr.authnr-SeqNum is omitted.

• Authorisation data

  The field out_data.authnHdr-EncryptAuthnr.authnr-AuthzData is omitted.

• Checksum

  The field out_data.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Type has the value chksumType-CL-RPC (see Registered Checksum Types ), which is defined as follows. The field out_data.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Value, which will be denoted checksum here, has as its value the following 40-byte vector:

   
  
  <challenge, protection_level, key_seq_num, key_type,
      key_length, key>
  
  
  

  (Note that this usage of the authnr-Cksum field is quite different from the "normal" usage of checksums as discussed in Checksum Mechanisms and in Checksums . The present usage does meet the syntactic definition of the authnr-Cksum field, with a "similar though non-standard" semantic. This is discussed further at the end of this section.) The components of checksum have the following formats and semantics:

  • The field challenge is an 8-byte vector, equal to the in_data.challenge field of the corresponding request message. In this manner, challenge represents a nonce that the RPC server uses to (securely) match this out_data response message with the corresponding in_data request message.

  • The field protection_level is a 4-byte vector, big/big-endian representing an integer equal to the protection level of the original RPC PDU that this authentication header is authenticating (as specified in the referenced Open Group DCE 1.1 RPC Specification).

  • The field key_seq_num is a 4-byte vector, big/big-endian representing an integer equal to the encryption key version number (in the sense of Encrypted Data ) of key. It is equal to in_data.key_seq_num.

  • The field key_type is a 4-byte vector, big/big-endian representing an integer equal to the encryption key type (in the sense of Encryption Keys ) of key. The only value currently supported is 1.

  • The field key_length is a 4-byte vector, big/big-endian representing an integer equal to Lambda(key), depending on the value of key_type. For key_type = 1, key_length is 16.

  • The field key is a byte vector, representing an encryption key of type indicated by key_type. In the case key_type = 1, key is a 16-byte vector, consisting of two 8-byte subvectors, which are denoted:

     
    
    <des_key, des_iv>
    
    
    

    Here, des_key represents an encryption key of type encKeyType-DES (see Registered Encryption Key Types ), and des_iv represents a DES initialisation vector (see CBC Mode ). This key and initialisation vector are used to protect the ensuing session/conversation between the client and server (that is, for integrity and confidentiality protection of the PDU verifiers and bodies as specified in the remainder of this chapter). Consequently, all such keys must be distinct over all <RPC activity, key_seq_num> pairs. The activity UUID uniquely identifies a "shared state" (in the sense of "connection" or "association") between client and server. All requests with the same activity UUID must use the same protection level, and all responses must be sent at the same protection level (and with the same key) as the requests that induced them.

This Conversation Manager in_data/out_data mechanism thus represents yet another way to establish a conversation key between client and server. Extending the notations "K^" and "K^^" of Authenticators and Reverse-Authentication Headers (though those do not occur in the CL RPC protocol, as already noted), the key checksum.key.des_key may be denoted "K^^^". Like K^, K^^^ is chosen by the client (not the server).

The semantics of out_data are that it authenticates (in the sense specified in Client Sends Authentication Header and Client Sends Privilege Authentication Header ) the original RPC request message (the one triggering this invocation of the conv_who_are_you_auth() callback). Note that out_data is bound to the client's original RPC request because that request is protected with checksum.key. Finally, no explicit reverse (privilege) authentication header is generated corresponding to the (privilege) authentication header carried by out_data-nevertheless, the conversation between the client and server is indeed implicitly mutually authenticated, by virtue of the fact that the key K^^^ is used to protect the communications.

Note:

Concerning the above-mentioned non-standard usage of authnr-Cksum, note that the usual intention of the authnr-Cksum field in the Kerberos protocol is to cryptographically bind the authentication header to the client's message. In the present application of this idea to RPC, as will be detailed in the remainder of this chapter, this binding is done indirectly, in that authnr-Cksum is used to cryptographically bind the authentication header to the RPC session/conversation between client and server. The security of this approach relies on the fact that authnr-Cksum is protected for both integrity and privacy.

CL Integrity and Confidentiality (PDU Verifiers and Bodies)

Let <H, B, V> be a PDU protected for integrity and/or confidentiality. This section specifies the format and semantics of its body bgcolor="#FFFFFF" B and its (16-byte) verifier field V.auth_value.

Throughout, the following notation is used. Let authnHdr denote the authentication header associated with the given PDU-it has been transmitted from the client to the server as the out_data parameter of a conversation manager conv_who_are_you_auth() request (see above).

• R denotes raw (plaintext) body bgcolor="#FFFFFF" data (generally consisting of IDL-defined NDR-marshalled data generated by a client or server stub, or by RPC runtime itself), as specified in the referenced Open Group DCE 1.1 RPC Specification.

• K = authnHdr.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Value.key.des_key.

• IV = authnHdr.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Value.key.des_iv.

CL dce_c_authn_level_pkt

If V.protection_level = dce_c_authn_level_pkt, then the body bgcolor="#FFFFFF" B and verifier field V.auth_value are specified as follows.

In pseudocode:

B = <R, 0(-Lambda(R))(mod 8)>;
struct {unsigned32 _1_; unsigned32 _2_;} seq_frag =
    {is_client_pdu?H.seqnum:(H.seqnum^231), H.fragnum};
enc_seq_frag = DES-CBC(K, IV, seq_frag);
V.auth_value = <enc_seq_frag, 08>;

In words: The body bgcolor="#FFFFFF" B is set to the raw data R (which may be empty) appended with a 0-vector of length (-Lambda(R))(mod 8), so that B has length a multiple of 8. Next, define seq_frag to be the IDL-defined NDR-marshalled 8-byte quantity consisting of the 4-byte direction-bit-adjusted PDU sequence number H.seqnum (namely, if this is a server PDU; that is, is transmitted from server to client, then invert (complement) the most significant bit (that is, bitwise-XOR with 0x80000000 = 2³¹)), and the 4-byte PDU fragment number H.fragnum. (The lack of provision for overflow of H.seqnum is not considered to be a significant security exposure. Also, note that H.fragnum is in the range [0, 2¹⁶-1], which is a subset of [0, 2³²-1], so it can certainly (by "casting") be marshalled as an IDL unsigned32-and the size of this range is also not considered to be a significant security exposure.) Let enc_seq_frag be the indicated 8-byte DES-CBC encryption of seq_frag. Then the 16-byte V.auth_value is the concatenation of enc_seq_frag with an 8-byte 0-vector.

Security interpretation: The PDU's direction-bit-adjusted sequence number and fragment number (which are carried in the header H) are integrity-protected (and bound together) by the verifier V. The PDU's body bgcolor="#FFFFFF" B (R) is unprotected.

CL dce_c_authn_level_integrity

If V.protection_level = dce_c_authn_level_integrity, then the body bgcolor="#FFFFFF" B and verifier field V.auth_value are specified as follows.

In pseudocode:

B = <R, 0(-Lambda(R))(mod 8)>;
hdr_bdy = <H, B>;
cksum_hdr_bdy = MD5(hdr_bdy);
V.auth_value = DES-CBC(K, IV, cksum_hdr_bdy);

In words: The body bgcolor="#FFFFFF" B is set to the raw data R (it may be empty) appended with a 0-vector of length (-Lambda(R))(mod 8), so that B has length a multiple of 8. Next, define hdr_bdy to be the concatenation of the header H (recall that Lambda(H) = 80) and the body bgcolor="#FFFFFF" B. Let cksum_hdr_bdy be the 16-byte MD5 checksum of hdr_bdy. Then the 16-byte V.auth_value is the indicated DES-CBC encryption of cksum_hdr_bdy.

Security interpretation: The PDU's header H and body bgcolor="#FFFFFF" B (R) are integrity-protected (and bound together) by the verifier V.

CL dce_c_authn_level_privacy

If V.protection_level = dce_c_authn_level_privacy, then the body bgcolor="#FFFFFF" B and verifier field V.auth_value are specified as follows.

In pseudocode:

struct {byte _1_[4]; unsigned32 _2_;} conf_len =
    {RANDOM4(), Lambda(R)};
crc_conf_len = CRC§32(04, conf_len);
enc_conf_len = DES-CBC(K, IV, conf_len);
if (Lambda(R) == 0) {
    crc_conf_len_bdy = crc_conf_len;
    B = R; /*that is, B = empty*/
    cksum_conf_len_bdy = 08;
} else {
    R' = <R, 0(-Lambda(R))(mod 8)>;
    crc_conf_len_bdy = CRC§32(crc_conf_len, R');
    B = DES-CBC(K, enc_conf_len, R');
    cksum_conf_len_bdy = DES-CBC-CKSUM(K, enc_conf_len, R');
}
crc_conf_len_bdy_hdr = CRC§32(crc_conf_len_bdy, H);
cksum_conf_len_bdy_hdr = DES-CBC-CKSUM(K, cksum_conf_len_bdy, H);
struct {unsigned32 _1_; unsigned32 _2_;} seq_crc_conf_len_bdy_hdr =
    {H.seqnum, crc_conf_len_bdy_hdr};
enc_cksum_seq_crc_conf_len_bdy_hdr =
    DES-CBC(K, cksum_conf_len_bdy_hdr, seq_crc_conf_len_bdy_hdr);
V.auth_value = <enc_conf_len, enc_cksum_seq_crc_conf_len_bdy_hdr>;

In words: Set conf_len to the IDL-defined NDR-marshalled 8-byte quantity consisting of a 4-byte random vector, and the integer Lambda(R) (which is <= 65528, by Section 12.5.2.15, PDU Body Length, of the referenced Open Group DCE 1.1 RPC Specification). Let crc_conf_len be the 4-byte CRC of conf_len, with 4-byte 0-vector as seed. Let enc_conf_len be the indicated 8-byte DES-CBC encryption of conf_len. If Lambda(R) = 0: let crc_conf_len_bdy be the 4-byte crc_conf_len; let B be R (that is, empty); and let cksum_conf_len_bdy be the 8-byte 0-vector. If Lambda(R) > 0: let R´ be the raw data R appended with a 0-vector of length (-Lambda(R))(mod 8), so that R´ has length a positive multiple of 8; let crc_conf_len_bdy be the 4-byte CRC of R´ with seed crc_conf_len; let B be the indicated DES-CBC encryption of R´; and let cksum_conf_len_bdy be the indicated DES-CBC-CKSUM of R´. Let crc_conf_len_bdy_hdr be the CRC of the 80-byte header H with seed crc_conf_len_bdy. Let cksum_conf_len_bdy_hdr be the indicated DES-CBC-CKSUM of H. Let seq_crc_conf_len_bdy_hdr be the IDL-defined NDR-marshalled 8-byte quantity consisting of the 4-byte PDU sequence number H.seqnum (not direction-bit-adjusted, because the header H contains the CL packet type (ptype field), which itself serves as a "direction bit"), and the 4-byte crc_conf_len_hdr_bdy regarded as integer by the big/big-endian mapping. Let enc_cksum_seq_crc_conf_len_bdy_hdr be the indicated 8-byte DES-CBC encryption of seq_crc_conf_len_bdy_hdr. Finally, V.auth_value is the 16-byte concatenation of enc_conf_len and enc_cksum_seq_crc_conf_len_bdy_hdr.

Security interpretation: The PDU's body bgcolor="#FFFFFF" B (R) is confidentiality-protected. The PDU's header H and body bgcolor="#FFFFFF" B (R) are integrity-protected (and bound together) by the verifier V, and by the use of the DES-CBC-CKSUM as the initialisation vector for the DES-CBC encryption of the body bgcolor="#FFFFFF".

Security in the CO RPC Protocol

This section specifies the security-related material listed in What is Specified in this Chapter for the CO protocol.

Recall that the following quantities are associated with any PDU (see Section 13.2.1, Client Association State Machine, of the referenced Open Group DCE 1.1 RPC Specification for definitions and details). The formats used for them are specified here:

• crc_assoc_uuid

  The PDU's CRC of association UUID. As explained in Section 13.2.1, Client Association State Machine, of the referenced Open Group DCE 1.1 RPC Specification (see also CO Verifier auth_value.assoc_uuid_crc below), every PDU has an association UUID attached to it, assoc_uuid, which is a 16-byte NDR-marshalled value of the IDL uuid_t data type. However, this association UUID is known only by the client, not the server-all that is known by the server is crc_assoc_uuid (in the referenced Open Group DCE 1.1 RPC Specification, this was denoted assoc_uuid_cksum). It is defined as follows:

   
  
  crc_assoc_uuid = CRC§32(04, assoc_uuid);
  
  
  

  In words: crc_assoc_uuid is the indicated 4-byte CRC of assoc_uuid with 4-byte 0-vector as seed.

  Security interpretation: crc_assoc_uuid is a uniformly distributed 32-bit hash of the 128-bit assoc_uuid (that is, even though CRCs are not cryptographic hashes, the probability of crc_assoc_uuid colliding with another such hash is probablistically insignificant).

  It is viewed (and formatted) as a 4-byte little/big-endian integer (even though only its bit pattern is of significance, never its integral value-that is, the only operation ever performed on it is testing for equality, never arithmetic operations such as addition).

  Note also that (as seen by the remainder of this section) the uniqueness of crc_assoc_uuids is relied upon (though not in a trusted way) to distinguish between associations. This in turn relies upon the uniqueness of UUIDs, and in fact on the actual algorithm for generating UUIDs (see Section A.2, Algorithms for Creating a UUID, of the referenced Open Group DCE 1.1 RPC Specification). The secrecy of crc_assoc_uuids is never relied upon, and collisions of crc_assoc_uuids can at worst result in a denial of service. In particular, uuid_create() need not be considered part of the local TCB.

• dir_seq

  The PDU's direction-bit-adjusted sequence number; that is, its sequence number with the most significant bit inverted (complemented) in the case of a server(-to-client) PDU. This is specified in the referenced Open Group DCE 1.1 RPC Specification (note that it is separately maintained locally on the client and on the server, and is not directly transmitted in the PDU, though it is used in the cryptographic computations below). It is formatted as a 4-byte little/big-endian integer. (The lack of provision for overflow of the sequence number is not considered to be a significant security exposure.)

• sub_type

  The PDU's encryption/checksum subtype identifier. It is an integer value in the range [0, 2⁸-1], formatted into 1 byte via the big-endian mapping. It specifies a combined encryption/checksum mechanism depending on the value of sub_type, which is denoted:

  ENCCKSUM_{sub_type}(K, CRCUUID, DIRSEQ, M)

  where the 4 input items are: K is an 8-byte vector (in fact, for both of the registered sub_types listed below, K must actually be a DES key; that is, must be in odd-parity normal form); CRCUUID is a 4-byte vector; DIRSEQ is a 4-byte vector; and M is a byte-vector of length Lambda(M) > 0. The currently registered values for sub_type, and the definitions of their corresponding encryption/checksum mechanisms, are the following:

  • dce_c_cn_sub_type_des = 0

    This yields as output an 8-byte encryption/checksum value defined by the following pseudocode:

     
    
    crcuuid_dirseq = <CRCUUID, DIRSEQ>;
    M' = <M, 0(-Lambda(M))(mod 8)>;
    ENCCKSUMdce_c_cn_sub_type_des(K, CRCUUID, DIRSEQ, M) =
        DES-CBC(K, crcuuid_dirseq, M');
    
    
    

    In words: Set crcuuid_dirseq to the 8-byte concatenation of CRCUUID and DIRSEQ. Let M´ be M padded with a 0-vector of length (-Lambda(M))(mod 8), so that Lambda(M´) is a positive multiple of 8. Then ENCCKSUM_{dce_c_cn_sub_type_des}(K, CRCUUID, DIRSEQ, M) is set to the indicated 8-byte DES-CBC encryption of M´.

  • dce_c_cn_sub_type_md5 = 1

    This yields as output a 16-byte encryption/checksum value defined by the following pseudocode:

     
    
    crcuuid = <CRCUUID, 04>;
    enc_crcuuid = DES-CBC(K, 08, crcuuid);
    msg_enc_crcuuid_dirseq = <M, enc_crcuuid, DIRSEQ>;
    ENCCKSUMdce_c_cn_sub_type_md5(K, CRCUUID, DIRSEQ, M) =
        MD5(msg_enc_crcuuid_dirseq);
    
    
    

    In words: Set crcuuid to the 8-byte concatenation of the 4-byte CRCUUID and the 4-byte 0-vector. Let enc_crcuuid be the indicated 8-byte DES-CBC encryption of crcuuid. Next let msg_enc_crcuuid_dirseq be the concatenation of M (not padded), the 8-byte enc_crcuuid, and the 4-byte DIRSEQ. Then ENCCKSUM_{dce_c_cn_sub_type_md5}(K, CRCUUID, DIRSEQ, M) is set to the 16-byte MD5 checksum of msg_enc_crcuuid_dirseq.

  Security interpretation (in both of the above two cases): CRCUUID, DIRSEQ and M are integrity-protected (and bound together) by ENCCKSUM_{sub_type}(K, CRCUUID, DIRSEQ, M).

CO Establishment of Credentials (bind, bind_ack, alter_context, alter_context_response)

Let <H, B, V> be a PDU of one of the types bind, bind_ack, alter_context or alter_context_response such that H.auth_length > 0. This section specifies the verifier field V.auth_value in these cases.

CO Verifier auth_value.assoc_uuid_crc

This section specifies the verifier field V.auth_value.assoc_uuid_crc. It depends on the PDU type, as follows:

• The case of a bind or alter_context PDU.

  V.auth_value.assoc_uuid_crc is defined as follows:

   
  
  V.auth_value.assoc_uuid_crc = crc_assoc_uuid;
  
  
  

  In words: The client sets V.auth_value.assoc_uuid_crc to the 4-byte CRC of association UUID, crc_assoc_uuid, as defined in Security in the CO RPC Protocol . (This is how the server learns crc_assoc_uuid, but not the actual assoc_uuid itself.)

• The case of a bind_ack or alter_context_response PDU.

  V.auth_value.assoc_uuid_crc is defined as follows:

   
  
  V.auth_value.assoc_uuid_crc = `unspecified';
  
  
  

  In words: V.auth_value.assoc_uuid_crc is set to a 4-byte 0-vector by the server, and is ignored by the client.

CO Verifier auth_value.checksum

This section specifies the verifier field V.auth_value.checksum. It depends on the value of V.auth_level, as follows:

• The case V.auth_level = dce_c_authn_level_none- V.auth_value.checksum is defined by the following pseudocode:

   
  
  V.auth_value.checksum = `unspecified';
  
  
  

  In words: V.auth_value.checksum is set by the sender to an 8-byte or 16-byte 0-vector, according as V.auth_value.sub_type is dce_c_cn_sub_type_des or dce_c_cn_sub_type_md5 respectively; its value is ignored by the receiver.

  Security interpretation: The PDU is not protected by its verifier field V.auth_value.checksum.

• The case V.auth_level = dce_c_authn_level_connect, dce_c_authn_level_call or dce_c_authn_level_pkt.

  V.auth_value.checksum is defined by the following pseudocode:

   
  
  V.auth_value.checksum =
      ENCCKSUMV.auth_value.sub_type
  (K, crc_assoc_uuid, dir_seq, 08 or 16);
  
  
  

  In words: The field V.auth_value.checksum is set to the indicated (8-byte or 16-byte) ENCCKSUM of an 8-byte or 16-byte 0-vector, according as V.auth_value.sub_type is dce_c_cn_sub_type_des or dce_c_cn_sub_type_md5 respectively..

  Security interpretation: The PDU's CRC of association UUID and its direction-bit-adjusted sequence number are integrity-protected (and bound together) by the verifier field V.auth_value.checksum.

• The case V.auth_level = dce_c_authn_level_pkt_integrity or dce_c_authn_level_pkt_privacy.

  V.auth_value.checksum is defined by the following pseudocode:

   
  
  struct {unsigned32 _1_; unsigned8 _2_; unsigned8 _3_;
      unsigned16 _4_;} vrf =
          {V.auth_value.assoc_uuid_crc, V.auth_value.sub_type,
          V.auth_value.checksum_length, V.auth_value.cred_length};
  hdr_bdy_vrf = <H, B, vrf>;
  V.auth_value.checksum =
      ENCCKSUMV.auth_value.sub_type(K, crc_assoc_uuid, dir_seq,
          hdr_bdy_vrf);
  
  
  

  In words: Let vrf be the IDL-defined NDR-marshalled 8-byte data indicated (it is the first 8 bytes of the verifier's V.auth_value field; that is, it is V.auth_value excluding the V.auth_value.credentials and V.auth_value.checksum fields). Let hdr_bdy_vrf be the concatenation of the PDU header H, the PDU body bgcolor="#FFFFFF" B, and vrf. Then V.auth_value.checksum is set to the indicated (8-byte or 16-byte) ENCCKSUM of hdr_bdy_vrf.

  Security interpretation: The PDU's header H, body bgcolor="#FFFFFF" B (R), and the specified fields of the verifier V are integrity-protected (and bound together) by the verifier field V.auth_value.checksum.

CO Verifier auth_value.credentials

This section specifies the verifier field V.auth_value.credentials. Most of this specification has already been given in Section 13.2.6.3, Credentials Encoding, of the referenced Open Group DCE 1.1 RPC Specification, so this section just gives the specification of the components there were left unspecified there: namely, the components that were there called name, pac, request, response and error.

• name

  This is unsupported (it will be removed from future versions of the referenced Open Group DCE 1.1 RPC Specification and this specification).

• pac

  This is unsupported (it will be removed from future versions of the referenced Open Group DCE 1.1 RPC Specification and this specification).

• request

  This is (the NDR-marshalled IDL byte[] data type underlying) either an AuthnHeader or a PAuthnHeader data type, dependent on whether the dce_c_authz_name or dce_c_authz_dce authorisation service has been specified respectively (this is used to authenticate the client to the server, in the sense of (Reverse-)Authentication Header Processing ), with the following supplements:

  • Options

    The field V.auth_value.credentials.authnHdr-Flags contains no selected options.

  • Conversation key

    The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-ConversationKey is omitted.

  • Sequence number

    The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-SeqNum is omitted by the client, and is ignored by the server.

  • Authorisation data

    The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-AuthzData is omitted.

  • Checksum

    The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Type has the value chksumType-CO-RPC (see Registered Checksum Types ), which is defined as follows. The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Type has as its value the (unique) vector of length 0 (that is, there is no checksum data).

• response

  This is (the NDR-marshalled IDL byte[] data type underlying) either a RevAuthnHeader or a PRevAuthnHeader data type, dependent on whether the dce_c_authz_name or dce_c_authz_dce authorisation service has been specified respectively (this is used to reverse-authenticate the server to the client, in the sense of (Reverse-)Authentication Header Processing ), with the following supplements:
  

  • Conversation key

    The field V.auth_value.credentials.revAuthnHdr-EncryptPart.revAuthnHdr-ConversationKey is omitted.

  • Sequence number

    The field V.auth_value.credentials.revAuthnHdr-EncryptPart.revAuthnHdr-SeqNum is omitted by the server, and is ignored by the client.

• error

  This is (the NDR-marshalled IDL byte[] data type underlying) a KDSError data type.

CO Integrity and Confidentiality (PDU Verifiers and Bodies)

Let <H, B, V> be a PDU protected for integrity and/or confidentiality. This section specifies the format and semantics of its body bgcolor="#FFFFFF" B and its verifier field V.auth_value.

Throughout, the following notation is used. Let authnHdr denote the authentication header associated with the given PDU-it has been transmitted from the client to the server in a PDU's V.auth_value.credentials field (see above).

• R denotes raw (plaintext) body bgcolor="#FFFFFF" data (generally consisting of IDL-defined NDR-marshalled data generated by a client or server stub, or by the RPC runtime itself) as specified in the referenced Open Group DCE 1.1 RPC Specification.

• K = authnHdr.authnHdr-Tkt.tkt-EncryptPart.tkt-SessionKey.

• (No initialisation vector, IV, is used below.)

CO dce_c_authn_level_pkt

If V.auth_level = dce_c_authn_level_pkt, then the body bgcolor="#FFFFFF" B and verifier field V.auth_value.checksum are specified as follows.

In pseudocode:

 

B = R;
V.auth_value.checksum =
    ENCCKSUMV.auth_value.sub_type
(K, crc_assoc_uuid, dir_seq, 08 or 16);

In words: The body bgcolor="#FFFFFF" B is set to the raw data R (it may be empty). The field V.auth_value.checksum is set to the indicated (8-byte or 16-byte) ENCCKSUM of a 0-vector (of length 8 or 16 bytes, dependent on whether V.auth_value.sub_type is dce_c_cn_sub_type_des or dce_c_cn_sub_type_md5 respectively).

Security interpretation: The PDU's CRC of association UUID and its direction-bit-adjusted sequence number are integrity-protected (and bound together) by the verifier field V.auth_value.checksum. The body bgcolor="#FFFFFF" B (R) is unprotected.

CO dce_c_authn_level_pkt_integrity

If V.auth_level = dce_c_authn_level_pkt_integrity, then the body bgcolor="#FFFFFF" B and verifier field V.auth_value.checksum are specified as follows.

In pseudocode:

 

B = R;
hdr_bdy = <H, B>;
V.auth_value.checksum =
    ENCCKSUMV.auth_value.sub_type(K, crc_assoc_uuid,
dir_seq, hdr_bdy);

In words: The body bgcolor="#FFFFFF" B is set to the raw data R (it may be empty). Let hdr_bdy be the concatenation of the header H and body bgcolor="#FFFFFF" B. Then the field V.auth_value.checksum is set to the indicated (8-byte or 16-byte) ENCCKSUM of hdr_bdy.

Security interpretation: The PDU's CRC of association UUID, direction-bit-adjusted sequence number, header H and body bgcolor="#FFFFFF" B (R) are integrity-protected (and bound together) by the verifier field V.auth_value.checksum.

CO dce_c_authn_level_pkt_privacy

If V.auth_level = dce_c_authn_level_pkt_privacy, then the body bgcolor="#FFFFFF" B and verifier field V.auth_value.checksum are specified as follows.

If R is empty, in pseudocode:

 

B = R; /*that is, B = empty*/
V.auth_value.checksum =
    ENCCKSUMV.auth_value.sub_type(K, crc_assoc_uuid, dir_seq, H);

In words: This is identical to the dce_c_authn_level_pkt_integrity case (in the case R is empty), above.

If R is non-empty, in pseudocode:

 

enccksum_crc_assoc_uuid_dir_seq_hdr =
    ENCCKSUMV.auth_value.sub_type(K, crc_assoc_uuid, dir_seq, H);
if (V.auth_value.sub_type == dce_c_cn_sub_type_md5) {
    enccksum_crc_assoc_uuid_dir_seq_hdr =
        FOLD8(enccksum_crc_assoc_uuid_dir_seq_hdr);
}
R' = <R, 0(3-Lambda(R))(mod 8), (3-Lambda(R))(mod 8)>;
crc_bdy = CRC§32(04, R');
R" = <R', crc_bdy>;
B = DES-CBC(K, enccksum_crc_assoc_uuid_dir_seq_hdr, R");
V.auth_value.checksum = 08 or 16;

In words: Let enccksum_crc_assoc_uuid_dir_seq_hdr be the indicated (8-byte or 16-byte) ENCCKSUM of the header H. If V.auth_value.sub_type = dce_c_cn_sub_type_md5, then "fold the 16-byte enccksum_crc_assoc_uuid_dir_seq_hdr in half" (making it into an 8-byte vector), as defined by the following pseudocode for any 16-byte vector <C₀, C₁, ···, C₁₅>:

 

FOLD8(<C0, C1, 
···, C15>) = 
<C0^C8, 
C1^C9, 
···, 
C7^C15>;

Next, let R´ be the concatenation of the raw data R, a 0-vector of length (3-Lambda(R))(mod 8), and a 1-byte big-endian integer whose value is (3-Lambda(R))(mod 8); thus, Lambda(R´) equivalence 4 (mod 8). Let crc_bdy be the 4-byte CRC of R´, with 4-byte 0-vector as seed. Then let R´´ be the concatenation of R´ and crc_bdy, so that Lambda(R´´) is a multiple of 8. Then B is the indicated DES-CBC encryption of R´´. Finally, V.auth_value.checksum is set to an 8-byte or 16-byte 0-vector, dependent on whether V.auth_value.sub_type is dce_c_cn_sub_type_des or dce_c_cn_sub_type_md5 respectively.

Security interpretation: The PDU's CRC of association UUID, direction-bit-adjusted sequence number, header H and body bgcolor="#FFFFFF" B (R) are integrity-protected (and bound together), and the body bgcolor="#FFFFFF" B (R) is confidentiality-protected, all via the encrypted data B (not via the verifier field V.auth_value.checksum).