Previous section.

DCE 1.1: Authentication and Security Services
Copyright © 1997 The Open Group

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§32 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:

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:

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:

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:

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:

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.

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

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 = 231)), 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, 216-1], which is a subset of [0, 232-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:

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:

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:

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.

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

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 <C0, C1, ···, C15>:

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

Please note that the html version of this specification may contain formatting aberrations. The definitive version is available as an electronic publication on CD-ROM from The Open Group.

Contents Next section Index