Questions on gss_verify_mic_iov

[Natalie Li]

Thanks Greg. I just did the proof-of-concept testing by removing the 
4-byte padding from the MIC token iov and confirmed that 
gss_verify_mic_iov() returns successfully.

3104/145 at 145:                 -> 
libgssapi_krb5:krb5_gss_verify_mic_iov(0x7ff7ff202c08, 0xe78889d10, 
0x7ff7ff202c0c, 0x7ff7ff202c10, 0x4, 0x7ff807c53090)
3104/145 at 145:                 <- 
libgssapi_krb5:krb5_gss_verify_mic_iov() = 0
3104/145 at 145:               <- 
libgssapi_krb5:spnego_gss_verify_mic_iov() = 0
3104/145 at 145:             <- libgssapi_krb5:gss_verify_mic_iov() = 0  
<----- SUCCESS!

Can you please tell me what's the expected length of the MIC token if 
encryption type of the session key is AES128 or ARCFOUR-HMAC?
Does the checksum_iov_v3() know which encryption type to use? If so, can 
it truncate the provided MIC token to the expected length before 
verifying the checksum?

I've looked at various network traces and have found that the Windows 
2012 R2 client sets AuthLen to 32 (most of the time) and 28 
(occasionally). I'll check with Microsoft on how best we can detect the 
paddings that is included in the AuthToken (i.e. the MIC token + 
paddings (if any)) given at the MS-RPC layer I cannot detect such 
paddings via decoding the header or sec_trailer section of the message.

Thanks,

Natalie

On 9/15/2015 10:17 PM, Greg Hudson wrote:
> On 09/16/2015 12:29 AM, Natalie Li wrote:
>> 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.
> The AES enctypes use a checksum length of 12 bytes.  There are an
> additional 16 bytes of GSSAPI token header, for an expected total of 28
> bytes.  In checksum_iov_v3() we check for an exact match against this
> expected length, so the 32-byte token yields an error.
>
> Looking at the packet capture, the MIC token ends with twelve non-zero
> checksum bytes followed by four zero bytes, which I assume are padding.
>   This padding appears to conform to [MS-RPCE] 2.2.3.5; I don't know if
> there is any way to find out the true length of the token without the
> padding.  (Removing zero bytes is of course not safe; nothing prevents
> the last byte of the checksum from being zero.)