[cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
abartlet at samba.org
Mon Jul 28 05:52:35 GMT 2008
I've been spending most of today staring at MS-KILE 188.8.131.52.1 and
Heimdal's implementation of GSSAPI CFX.
What has me stumped is exactly what this means:
> If the session key encryption type is AES128-CTS-HMAC-SHA1-96 or AES256-CTS-HMAC-SHA1-96,
> as specified in [RFC3961], the base line is [RFC4121] and the encrypted data per [RFC3961] (which
> [RFC4121] is based on) is:
> C1 | H1[1..h]
> (C1, newIV) = E(Ke, conf | plaintext | pad, oldstate.ivec)
> H1 = HMAC(Ki, conf | plaintext+encrypted-data | pad)
> where the "plaintext+encrypted-data" is all the input data buffers supplied to GSS_WrapEx()
> concatenated in the order provided in the ordered list, input_message.
I see that C1 is the output of the encryption function E, and presume
that Ke is the encryption key, but what is 'conf', and is 'plaintext'
the confidential data in plaintext, or the data over which only a
signature is computed (presumably the confidential data in plaintex, but
then what is conf)?
I presume again that Ki is the signing key.
Likewise, a description of how the pad fits into the HMAC function here
would be very helpful.
In short, because this is a deviation from the GSSAPI spec (as the spec
does not allow data to be signed, but not sealed), I really need much
more detail, and all the inputs and outputs clearly labelled,
particularly as this seems to require a major rework of Heimdal to
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080728/b01f9be0/attachment.bin
More information about the cifs-protocol