Questions on gss_verify_mic_iov

[Greg Hudson]

On 09/15/2015 11:00 AM, Natalie Li wrote:
> 1) Is it intended for supporting GSS_VerifyMICEx() call [support 
> multiple input buffers] mentioned in MS-KILE document as shown below?
> 
> https://msdn.microsoft.com/en-us/library/cc233937.aspx

Not specifically, but it should serve a similar function, and it seems
like they should interoperate.

> 2) If yes to (1), then can you please confirm the usage of 
> gss_verify_mic_iov() in the following scenario described by MS-RPCE 
> document:
[...]

It seems right to me.

> a) Is GSS_C_BUFFER_TYPE_TRAILER intended for sec_trailer mentioned in 
> section 2.2.2.11 as shown below?
> https://msdn.microsoft.com/en-us/library/cc243931.aspx

No, it's used by gss_wrap_iov()/gss_unwrap_iov() for the RFC 3961
authentication trailer.  Microsoft's implementation rotates this into
the header; we do the same if no trailer buffer is given.
gss_verify_mic_iov() does not use this buffer type.

> One of the Solaris Kerberos team members suggested that 
> GSS_C_BUFFER_TYPE_TRAILER required due to:
> [...]

No; the logic is somewhat tortured due to the way code is shared between
unwrap and verify_iov, but checksum_iov_v3() doesn't require a trailer
in the verify_iov case because rrc is set to a synthetic value.

> (GSS major error): A token had an invalid Message Integrity Check (MIC)
> (GSS minor error): Message size is incompatible with encryption type

What is the encryption type of the session key, and what is the size of
the MIC token?

> b) GSS_C_BUFFER_TYPE_HEADER is not intended for the PDU header (MS-RPC 
> header) mentioned in (2), right? The MIT krb doc suggests that for 
> GSSAPI wrap token header.

Correct, the MS-RPC PDU header is at a higher protocol layer.

> c) Is GSS_C_BUFFER_TYPE_DATA used only for encryption, not for signing?

GSS_C_BUFFER_TYPE_DATA and GSS_IOV_BUFFER_TYPE_SIGN_ONLY are both used
for signing.  They have the same meaning to the MIC functions, but have
different meanings for gss_wrap_iov(), where DATA buffers are encrypted
and SIGN_ONLY buffers are not--but again, both types are included in the
calculation of the authentication tag.