[cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
Stefan (metze) Metzmacher
metze at samba.org
Fri Aug 8 10:01:59 GMT 2008
Hongwei Sun schrieb:
> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080808/47d42eaf/signature.bin
More information about the cifs-protocol