[33414] in Kerberos
Re: Changing the master key
daemon@ATHENA.MIT.EDU (John Devitofranceschi)
Sun May 22 09:21:05 2011
Date: Sun, 22 May 2011 09:19:37 -0400
From: John Devitofranceschi <jdvf@optonline.net>
In-reply-to: <1306030718.2034.286.camel@t410>
To: Greg Hudson <ghudson@mit.edu>
Message-id: <129310F8-D428-4289-9FE8-89EB6800D0A4@optonline.net>
MIME-version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: multipart/mixed; boundary="===============1033855725=="
Errors-To: kerberos-bounces@mit.edu
--===============1033855725==
Content-type: multipart/signed; boundary=Apple-Mail-11--801820261;
protocol="application/pkcs7-signature"; micalg=sha1
--Apple-Mail-11--801820261
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Thanks a lot for this. We'll try out the patch ASAP.
=46rom your description of the issue, it seems that if the old mkey is =
purged from the master db after conversion and the slaves are then =
re-initialized from scratch, this problem can be avoided.
Is that accurate?
jd
On May 21, 2011, at 10:18 PM, Greg Hudson wrote:
> On Sat, 2011-05-21 at 10:28 -0400, John Devitofranceschi wrote:
>> We've run into a situation with MIT Kerberos 1.8.2 where the master
>> key has been changed and yet the slave kdc's are still reporting that
>> the original master key is being used on new principals.
>>=20
>> Slave kdc updates are happening via iprop.
>=20
> I was able to reproduce and debug this problem. The per-principal
> master key version is stored in a tagged-data entry in the principal
> entry. There is a long-standing bug in the way iprop receives
> tagged-data updates, causing it to ignore all but the first entry. =
The
> master key version happens to appear second in the list when a =
principal
> is added, so it gets lost.
>=20
> I would guess that under 1.8.x this bug causes new principals to be
> inaccessible from the slave KDC, which is pretty bad. In 1.9.x the =
bug
> would be fairly harmless, as the KDC has stopped caring about the
> principal's master key version (it just tries all master keys). Some
> admin programs still care about the per-principal master key version,
> but you wouldn't typically run those on slaves.
>=20
> I've tested and committed a fix to the trunk code. There has been a
> little bit of code drift between 1.8 and trunk, so I'm attaching a =
patch
> against 1.8.x. I haven't tested the 1.8 change except to make sure it
> compiles, but I'm confident it will behave identically to the trunk
> change.
> <patch.txt>
--Apple-Mail-11--801820261--
--===============1033855725==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1033855725==--
