[1146] in Kerberos_V5_Development
Re: motivation for multiple keys per principal
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu May 9 11:41:21 1996
Date: Thu, 9 May 1996 11:41:02 -0400
From: Theodore Ts'o <tytso@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: sommerfeld@orchard.medford.ma.us, basch@lehman.com, krbdev@MIT.EDU
In-Reply-To: Barry Jaspan's message of Thu, 9 May 1996 11:28:46 -0400,
<9605091528.AA21504@starkiller.MIT.EDU>
Date: Thu, 9 May 1996 11:28:46 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
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).
Well, we already have a keytab "subclass" which actually accesses the
Kerberos DB instead of a raw file. So the only thing which is missing
is the utility program to generate a new TGT key while leaving the old
TGT key in the database.
You're right that for keys other than the TGT there's no good reason for
the Kerberos DB to keep both keys around (except maybe for backup in
case the original srvtab file is lost, but the window were you need both
keys in the srvtab is relatively small anyway).
ovsec_edit_keytab supports this kind of operation; does kdb5_edit not?
No; it was never implemented. It's good to know ovsec_edit_keytab has
the feature, though.
- Ted
