Questions on gss_verify_mic_iov

[Natalie Li]

Thanks for the pointer, Luke. Yes, gss_get_mic_iov_length() is what I need.

Natalie

On 9/23/2015 7:32 PM, Luke Howard wrote:
> Have a look at the code on dcerpc.org in gssauthcn.c for an example (it does not need the IOV API for integrity only as the buffer is contiguous). You should be able to use get_mic_iov_length to determine how many significant bytes in the trailer.
>
> Sent from my iPad
>
>> On 17 Sep 2015, at 6:51 AM, Greg Hudson <ghudson at mit.edu> 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.  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.
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev