[37010] in Kerberos
Re: upgrade the inter-realm trust key to AES
daemon@ATHENA.MIT.EDU (Rick van Rein)
Wed May 27 10:02:45 2015
Message-ID: <5565CE67.1040307@openfortress.nl>
Date: Wed, 27 May 2015 16:02:15 +0200
From: Rick van Rein <rick@openfortress.nl>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <5527DE14.2000009@imperial.ac.uk>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
List,
> I would like to upgrade my inter-realm trust key from DES to AES.
I've always wondered...
Those descriptions that explain that we need a ticket krbtgt/A@B to
allow clients in realm B to access services in realm A (right?) seem to
forget about one thing, namely to avoid failures authenticating.
In any live setup, I would first setup the service-side KDCs,
krbtgt/A@B on the KDC for A
krbtgt/B@A on the KDC for B
and only after the dust on that has settled (replication and such) I
would trust myself to add the tickets to the client-side KDCs,
krbtgt/A@B on the KDC for B
krbtgt/B@A on the KDC for A
Likewise, to remove an older krbtgt, I'd want to first remove the
client-side KDC entry, see to it that all replicas are gone, and then
wait for one longest ticket time, and only then remove the service-side
KDC entry.
I didn't see that documented anywhere, though it seems to be the one
sane approach to avoid interruptions to the authentication services. Right?
(Not sure if this is on-topic, sorry... changing the keys available may
not be the same as setting up fresh crossover trust.)
Cheers,
-Rick
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
