Questions on gss_verify_mic_iov
natalie.li at oracle.com
Wed Sep 23 16:08:40 EDT 2015
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
2) MS version of gss_verify_mic_iov (AKA [MS-KILE] 18.104.22.168
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.]
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.
>>> Does the checksum_iov_v3() know which encryption type to use? If so,
>>> 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.
More information about the krbdev