[Guy Harris <gharris@xxxxxxxxx>]

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?