[1140] in Kerberos_V5_Development
Re: motivation for multiple keys per principal
daemon@ATHENA.MIT.EDU (Richard Basch)
Wed May 8 14:18:30 1996
Date: Wed, 8 May 1996 14:16:13 -0400
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: <9605081801.AA18168@starkiller.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
On Wed, 8-May-1996, "Barry Jaspan" wrote to "basch@lehman.com, krbdev@MIT.EDU" saying:
> > What was the motivation for supporting multiple keys per principal?
> > Is there a reason other than a smooth migration from DES to 3-DES?
>
> Such as a V4 to V5 migration...
>
> V4 to V5 migration can be accomplished by populating the V5 database
> with no-salt principals, and having the "change password" function
> store the new pw with the V5 salt option of choice; once all
> principals have changed their passwords, the migrationg is complete.
That is fine for the principals, but if you have a mix of client
workstations that support V4 and V5, this is *NOT* an option. The kdb
format is only one part of a possibly heterogeneous environment with
many versions of the software.
> Also, sometimes it is necessary to
> support multiple enctypes for awhile, until all the clients are updated.
>
> Well, that was my question. What enctypes do we envision using this
> for, other an DES and 3-DES?
How about the next encryption algorithm that comes along? I doubt we
will use LOKI92, or SEAL, but there may be another one later. Also,
when public key is no longer subject to royalties, a migration to
include RSA in the kdb is quite likely. Integrating one-time challenge
systems (eg. SecurId or S/Key) is also another possibility. How about
AFS3 salttypes? I think this is enough of a list to demonstrate the
point...
--
Richard Basch
Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
