[1145] in Kerberos_V5_Development
Re: motivation for multiple keys per principal
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Thu May 9 11:29:08 1996
Date: Thu, 9 May 1996 11:28:46 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: sommerfeld@orchard.medford.ma.us, basch@lehman.com, krbdev@MIT.EDU
In-Reply-To: <9605091518.AA08973@dcl.MIT.EDU> (message from Theodore Ts'o on Thu, 9 May 1996 11:18:43 -0400)
The goal's actually generalizable --- smooth migration of a service key
from one version number to the next.
It seems to me this is already supported---you just change the key in
the KDC and add the new key to the keytab without removing the old
key. All new requests get the new key, outstanding requests have the
old key, and the keytab has both. The only reason this doesn't work
for the TGT is because the TGT is read from the database, not a keytab
(which, incidentally, is how I would have proposed solving the
TGT-migration problem, instead of supporting multiple keys).
ovsec_edit_keytab supports this kind of operation; does kdb5_edit not?
Barry
