On Sun, Sep 08, 2002 at 08:46:59PM -0700, Jaime Fournier wrote:
> I have found on several idempotent calls, such as
> storedata in dfs, that the last 24 bytes of the packet
> are marked as kerberos. This makes sense since AUTH is
> set to 01.
It only makes sense if AUTH is set to 1 *AND* the first octet of the
authentication verifier is set to 6, i.e. dce_c_authn_level_pkt_privacy.
The stuff at
http://www.opengroup.org/onlinepubs/009629399/chap13.htm#tagcjh_18_03_04
says
Authentication Verifier Encodings
Connectionless PDUs contain an authentication verifier if the
PDU header field auth_proto is non-zero. Otherwise, the
authentication verifier is not present.
The encoding and length of the authentication verifier depends
on the authentication service, as identified by the PDU header
field auth_proto.
The authentication data encodings for the PDU authentication
verifier are specified in the following sections for
auth_proto=dce_c_rpc_authn_protocol_krb5.
Unless specified otherwise, the data types and values are
encoded in the NDR transfer syntax. Note that no padding
between elements within a data structure is assumed and that the
alignment requirements for the PDU header (see Alignment ) also
apply to the authentication verifier of the PDU trailer.
When the PDU header field
auth_proto=dce_c_rpc_authn_protocol_krb5, every PDU contains a
20 or 24-byte authentication verifier. The first three fields
of the verifier consist of a plaintext header followed by an
16-byte ciphertext authentication value, as follows:
typedef struct {
u_int8 protection_level;
u_int8 key_vers_num;
byte[pad_length] pad;
byte[16] auth_value;
} auth_trailer_cl_t;
protection_level
The protection level of the RPC. It indicates the level
of service as determined by the protection level values (see
The Generic RPC Security Model ).
key_vers_num
The version number of the key that indicates the key used
to encrypt or to calculate the checksum of any ciphertext in
the authentication value.
pad
A padding field whose value is all zeros. The length of
this array (pad_length) is 6 bytes for protection level
dce_c_authn_level_privacy, 2 bytes otherwise.
auth_value
The ciphertext of the authentication verifier. The format
of auth_value depends on the level of service. The
plaintext is encoded in the transfer syntax as specified in
the PDU header field drep.
so a 24-byte authentication verifier would only make sense for
auth_proto=dce_c_rpc_authn_protocol_krb5 and
protection_level=dce_c_authn_level_pkt_privacy, i.e. 6. Otherwise, the
verifier should be 20 bytes long, unless this is some difference between
DCE RPC 1.1 and some later version, which could perhaps be determined
from the key version number field.
I've checked in code to dissect that. It shows that the protection
level in the verifier in your packet is 4, namely dce_c_authn_level_pkt.
The key version number is 1, and the authentication verifier includes
some of the mysterious bytes you refer to:
> The problem I am seeing is actual payload
> at the end of the "kerberos" area. I am not that
> familiar with the lay out of the encrypted checksums,
> but I was curious if maybe there was a problem with
> identifying non kerberos data as part of the checksum.
The extra 4 bytes at the end appear to continue the sequence of letters
in the previous bytes; perhaps the packet's authentication verifier is
malformed?
