Questions on gss_verify_mic_iov

[Natalie Li]

Hi Greg,

One of the Microsoft engineers confirmed the following:

1) MS-RPC layer on the server should treat the Authentication Token 
(i.e. MIC token + trailing zeros) in the incoming MS-RPC request as 
opaque structure.

2) MS version of gss_verify_mic_iov (AKA  [MS-KILE] 3.4.5.7 
GSS_VerifyMICEx()) successfully verify the MIC token even when the MIC 
token w/ the trailing zeros is passed as function argument.

Can the checksum_iov_v3() be updated as we previously discussed?

[I'll forward you the email exchanges that I had w/ Microsoft separately.]

Thanks,

Natalie

On 9/16/2015 2:12 PM, Natalie Li wrote:
> 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.
>> <snip>
>>> 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