Questions on gss_verify_mic_iov

[Natalie Li]

On 9/16/2015 1:51 PM, Greg Hudson wrote:
> 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.
I tried that before switching to use gss_verify_mic_iov(). At that time, 
I had thought that the reason why gss_verify_mic() failed w/ 
KRB5_BAD_MSIZE was because it's not the right API to use.

>    But by my reading of the
> code, you would still have to remove the padding.
Most likely because I got the same KRB5 error when padding was not removed.

>> 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.
Thanks.

>> 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.
MS-RPC layer on the receiving end has no knowledge as to which 
encryption type is used by the underlying authentication mechanism, nor 
can it tell how many bytes of padding has been added to the AuthToken 
(AKA MIC token) by decoding the various PDU segments of the incoming 
message. So, I'm hesitate to tamper w/ the AuthToken in the incoming 
message at the MS-RPC layer. It's questionable why the Windows client 
sometimes sends 28-byte MIC token in some requests and 32-byte MIC token 
(including the 4-byte padding) in some other requests when AES 
encryption key is used. I'll check w/ Microsoft before getting back to 
you on the next steps.

Thanks,

Natalie