[cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES

[Stefan (metze) Metzmacher]

Hongwei Sun schrieb:
> Andrew,
> 
> 
> 
>    The  encryption function in Kerberos is described in details in 5.3 [RFC3961] (http://www.ietf.org/rfc/rfc3961.txt), which is referenced by [MS-KILE].
> 
> 
> 
>     I can summarize  as follows
> 
> 
> 
> *         "conf" is actually a random confounder prefix  of length c ,such as 16.
> 
> *         "pad" is for shortest padding to bring confounder and plaintext to a length that is the multiple of message block size m, which is octet(8) for AES encryption, as specified in  section 6 [RFC 3962] (http://www.ietf.org/rfc/rfc3962.txt)
> 
> *          Ke is an encryption key and Ki is a checksum key.
> 
> *         Plain text is the input confidential data before encryption.
> 
> *         The GSSWrapEX()  is exactly the same as the GSSWrap except that it supports ordered list of input buffers.  Input buffers for which conf_req_flag == TRUE are encrypted and returned. Buffers which sign == TRUE are included in the signature.
> 
> *         We use the Kerberos standard's encryption and signatures.    It is very important to  concatenate  the correct buffers to make it  work.

I found the problem, windows doesn't fill in the RRC field correctly.

Windows rotates by EC+RRC, e.g. EC=16 and RRC=28.

Samba sends EC=0 and RRC=28 and windows was happy with it
and samba would have been happy if windows would send EC=16 RRC=44.

It seems to only matter for DCERPC where EC is !=0,
as LDAP works fine as windows sends EC=0.

I have tested what happens when samba uses EC=16 for LDAP too,
and windows is also only happy if we rotate by EC+RRC.

So the windows behavior doesn't match RFC4121...

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080808/47d42eaf/signature.bin