[19265] in Kerberos_V5_Development
Re: Questions on gss_verify_mic_iov
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 16 16:51:15 2015
To: Natalie Li <natalie.li@oracle.com>, MIT Kerberos Dev List <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <55F9D638.2020406@mit.edu>
Date: Wed, 16 Sep 2015 16:51:04 -0400
MIME-Version: 1.0
In-Reply-To: <55F9B968.6060408@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
