[19263] in Kerberos_V5_Development
Re: Questions on gss_verify_mic_iov
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 16 01:17:35 2015
To: Natalie Li <natalie.li@oracle.com>, MIT Kerberos Dev List <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <55F8FB66.2060009@mit.edu>
Date: Wed, 16 Sep 2015 01:17:26 -0400
MIME-Version: 1.0
In-Reply-To: <55F8F044.5070909@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 09/16/2015 12:29 AM, Natalie Li wrote:
> EType: aes256-cts-hmac-sha1-96 (18) as shown in frame 25. See (1) of the
> attached doc.
>
> Size of the MIC token is 32 bytes as shown in frame 37. See (2) of the
> attache doc.
The AES enctypes use a checksum length of 12 bytes. There are an
additional 16 bytes of GSSAPI token header, for an expected total of 28
bytes. In checksum_iov_v3() we check for an exact match against this
expected length, so the 32-byte token yields an error.
Looking at the packet capture, the MIC token ends with twelve non-zero
checksum bytes followed by four zero bytes, which I assume are padding.
This padding appears to conform to [MS-RPCE] 2.2.3.5; I don't know if
there is any way to find out the true length of the token without the
padding. (Removing zero bytes is of course not safe; nothing prevents
the last byte of the checksum from being zero.)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
