Questions on gss_verify_mic_iov

[Greg Hudson]

On 09/16/2015 02:48 PM, Natalie Li wrote:
> 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.

It occurs to me that you could also concatenate the three buffers and
use gss_verify_mic(), with the same result.  But by my reading of the
code, you would still have to remove the padding.

> 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?

28 for aes128, 32 for rc4-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?

That would be possible; however, I don't think we have any precedent for
allowing trailing garbage at the end of GSSAPI krb5 tokens.  I think it
would be better to remove the padding at the MS-RPCE layer if it is
possible to do so, but I'm not sure whether it is.