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
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:
(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).
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.
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:
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:
The in_data and out_data parameters of the
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.
RPC integrity protection is implemented by cryptographic checksums of PDU headers and bodies, carried in PDU verifiers. Thus:
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.
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.
RPC confidentiality (privacy) protection is implemented by encrypting PDU bodies. Thus:
The body bgcolor="#FFFFFF" B needs to be specified when V.protection_level = dce_c_authn_level_privacy.
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
Its components have the following formats and semantics:
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
The field in_data.challenge is an 8-byte value representing
a nonce value (see
The field out_data.authnHdr-Flags contains no selected options.
The field out_data.authnHdr-EncryptAuthnr.authnr-ConversationKey is
omitted.
The field out_data.authnHdr-EncryptAuthnr.authnr-SeqNum is omitted.
The field out_data.authnHdr-EncryptAuthnr.authnr-AuthzData is omitted.
The field out_data.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Type
has the value chksumType-CL-RPC (see
-
-
<des_key, des_iv>
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
The semantics of out_data are that it authenticates (in the sense
specified in
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
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.
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.
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".
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:
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
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).
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.)
The PDU's encryption/checksum subtype identifier. It is an integer value in the range [0, 28-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:
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:
This yields as output an 8-byte encryption/checksum value defined by the
following pseudocode:
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 ENCCKSUMdce_c_cn_sub_type_des(K, CRCUUID, DIRSEQ, M) is set to the indicated 8-byte DES-CBC encryption of M´.
This yields as output a 16-byte encryption/checksum value defined
by the following pseudocode:
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 ENCCKSUMdce_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 ENCCKSUMsub_type(K, CRCUUID, DIRSEQ, M).
V.auth_value.assoc_uuid_crc is defined as follows:
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
V.auth_value.assoc_uuid_crc is defined as follows:
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.
-
-
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.
V.auth_value.checksum is defined by the following pseudocode:
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.
V.auth_value.checksum is defined by the following pseudocode:
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.
This is unsupported (it will be removed from future versions of the referenced Open Group DCE 1.1 RPC Specification and this specification).
This is unsupported (it will be removed from future versions of the referenced Open Group DCE 1.1 RPC Specification and this specification).
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
The field V.auth_value.credentials.authnHdr-Flags contains no selected options.
The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-ConversationKey is omitted.
The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-SeqNum is omitted by the client, and is ignored by the server.
The field V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-AuthzData is omitted.
The field
V.auth_value.credentials.authnHdr-EncryptAuthnr.authnr-Cksum.cksum-Type
has the value chksumType-CO-RPC (see
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
The field V.auth_value.credentials.revAuthnHdr-EncryptPart.revAuthnHdr-ConversationKey is omitted.
The field V.auth_value.credentials.revAuthnHdr-EncryptPart.revAuthnHdr-SeqNum is omitted by the server, and is ignored by the client.
This is (the NDR-marshalled IDL byte[] data type underlying) a KDSError data type.
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).
In pseudocode:
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.
In pseudocode:
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.
If R is empty, in pseudocode:
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:
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>:
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).
Contents | Next section | Index |