Questions on gss_verify_mic_iov

[Natalie Li]

On 9/15/2015 6:10 PM, Greg Hudson wrote:
> 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.
Thanks for checking.

>
>> 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.
That's what I thought as well.

>> (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?
EType: aes256-cts-hmac-sha1-96 (18) as shown in frame 25. See (1) of the 
attached doc.

Size of the MIC token is 32 bytes as shown in frame 37. See (2) of the 
attache doc.

Here's the MIC token as seen on wire (See (3) of the attached doc):

<snippet>
      - GssApi:
       - Token: unused (0)
        - MsKerberosToken: unused (0)
           TokId: GSS_GetMIC (0x404)
         - Krb5GssV2GetMic:
          + Flags: 4 (0x4)
            Filler: Binary Large Object (5 Bytes)
            SndSeq: 1536586973 (0x5B9674DD)
            SgnCksum: Binary Large Object (16 Bytes)
<snippet>

Since wireshark cannot decode the relatively new MS-FSRVP protocol, I've 
been using Microsoft NetMon to analyze network traces.
Attached are the network trace and a document w/ snapshots of Microsoft 
NetMon.
NOTE: The frame # mentioned in this email is based on NetMon. The frame 
# in NetMon may be different from the frame # in wireshark.


>
>> 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.
Thanks for the info,

Natalie