Questions on gss_verify_mic_iov

[Natalie Li]

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

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:

<snippet - MS-RPCE>
If the client and server Supports Header Signing Flag is TRUE, the party 
that sends the PDU asks the security provider to apply the following 
protection to the different PDU segments.

Authentication level 		| PDU header	| PDU body	|sec_trailer
-------------------------------------------------------------------------------
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY |Integrity	|Integrity	| Integrity

:
:
     The PDU header, PDU body, and sec_trailer MUST be passed in the
     input message, in this order, to GSS_WrapEx, GSS_UnwrapEx,
     GSS_GetMICEx, and GSS_VerifyMICEx. For integrity protection the sign
     flag for that PDU segment MUST be set to TRUE, else it MUST be set
     to FALSE.

<snippet>

where the sign flag is:

<snippet - MS-KILE>

message ORDERED LIST of:

  *

    signed BOOLEAN <-----------------------------

  *

    data OCTET STRING

<snippet>

Based on the MS documentation above where "signed" flag should be set 
for the various PDU segments, should the iov array be populated as follows:

gss_iov_buffer_desc     iov[4];

/* PDU header */
iov[0].type = GSS_IOV_BUFFER_TYPE_SIGN_ONLY;
iov[0].buffer.value = <PDU header of the incoming message>
iov[0].buffer.length = <PDU header length>

/* PDU body */
iov[1].type = GSS_IOV_BUFFER_TYPE_SIGN_ONLY;
iov[1].buffer.value = <PDU body of the incoming message>
iov[1].buffer.length = <PDU body length>

/* sec_trailer */
iov[2].type = GSS_IOV_BUFFER_TYPE_SIGN_ONLY;
iov[2].buffer.value = <sec_trailer of the incoming message>
iov[2].buffer.length = <sec_trailer length>

/* MIC token */
iov[3].type = GSS_IOV_BUFFER_TYPE_MIC_TOKEN;
iov[3].buffer.value = <MIC token in the incoming message to be verified>
iov[3].buffer.length = <MIC token length>

major = gss_verify_mic_iov(&minor, gss_ctx, &qop_state, iov, 4);

3) I've looked at the MIT krb documentation but still not clear on the 
various GSS_C_BUFFER_TYPE_XXX macros.

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

One of the Solaris Kerberos team members suggested that 
GSS_C_BUFFER_TYPE_TRAILER required due to:
   -> libgssapi_krb5:kg_verify_checksum_iov_v3(0xd0dee6210, 0x10, 0x10, 
0xd0dfe5610, 0x19, 0x7ffe0a607bf0)
      -> libgssapi_krb5:checksum_iov_v3(0xd0dee6210, 0x10, 0x10, 
0xd0dfe5610, 0x19, 0x7ffe0a607bf0)
           -> libgssapi_krb5:kg_locate_header_iov(0x7ffe0a607bf0, 0x4, 
0x101, 0x6, 0x19, 0x7ffe0a607bf0)
           <- libgssapi_krb5:kg_locate_header_iov() = 0x7ffe0a607c38
           -> libgssapi_krb5:kg_locate_iov(0x7ffe0a607bf0, 0x4, 0x7, 
0x7ffe0a607bd8, 0x19, 0x7ffe0a607bf0)
          <- libgssapi_krb5:kg_locate_iov() = 0 
<--GSS_C_BUFFER_TYPE_TRAILER(0x7) not found
     <- libgssapi_krb5:checksum_iov_v3() = 0x96c73abe
   <- libgssapi_krb5:kg_verify_checksum_iov_v3() = 0x96c73abe
<- libgssapi_krb5:gss_krb5int_unseal_v3_iov() = 0x60000

However, added another iov[4] of type TRAILER and the 
gss_verify_mic_iov() still fail in other place.

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.
c) Is GSS_C_BUFFER_TYPE_DATA used only for encryption, not for signing?

Thanks,

Natalie