[17521] in Kerberos_V5_Development
Re: Kerberos 1.7 and later does not interoperate with AD Read-only DCs
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Feb 21 13:10:07 2012
Message-ID: <4F43DDFA.1020608@mit.edu>
Date: Tue, 21 Feb 2012 13:10:02 -0500
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: abernstein@beyondtrust.com
In-Reply-To: <4F43077F.5000607@beyondtrust.com>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 02/20/2012 09:54 PM, Adam Bernstein wrote:
> Interestingly, this problem does not reproduce using Kerberos 1.6.
In krb5 1.6 we encode by casting the kvno value (an unsigned int) to
int, then encode it as a signed value. There is a comment saying
"krb5_kvno should be int". We decode this field as a signed long and
then cast the result to an unsigned int. (That means we reject
RFC4120-conformant kvno values >= 0x80000000 on platforms where long is
32-bit.)
In krb5 1.7-1.10, as you noted, the encoder treats the field as an
unsigned 32-bit integer, which conforms better to RFC 4120 but generates
TGS requests which don't interoperate with RODCs using RodcIDs >=
0x8000. The decoder behavior hasn't changed.
In the trunk, we encode and decode the kvno value as unsigned 32-bit
numbers, which means we would probably reject the AS reply from an RODC
with RodcID >= 0x8000.
I think the most practical solution is to restore the 1.6 behavior,
treating kvno as a signed 32-bit value when encoding and decoding.
Although this conflicts with RFC 4120, I think RODCs are the only case
where kvno values that large are likely to appear in the wild. If
you're in a position to test patches, I will run them by you.
(As an aside, Heimdal appears to treat the EncryptedData kvno field as
unsigned 32-bit, conformant to RFC 4120. It probably also doesn't
interoperate with RODCs with RodcID >= 0x8000.)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
