[19268] in Kerberos_V5_Development
Re: Questions on gss_verify_mic_iov
daemon@ATHENA.MIT.EDU (Natalie Li)
Wed Sep 23 16:34:03 2015
Message-ID: <560306C8.8090402@oracle.com>
Date: Wed, 23 Sep 2015 13:08:40 -0700
From: Natalie Li <natalie.li@oracle.com>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <55F9DB2A.7090008@oracle.com>
Cc: MIT Kerberos Dev List <krbdev@mit.edu>,
Satish Pudi <satish.pudi@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
