[1562] in Kerberos
Re: V4 to V5 conversion
daemon@ATHENA.MIT.EDU (Jon A. Rochlis)
Fri Sep 20 11:37:06 1991
From: jon@MIT.EDU (Jon A. Rochlis)
To: gmachin@somnet.sandia.gov (Dec-Glenn NoI Machin)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Thu, 19 Sep 91 16:53:06 -0600.
Date: Fri, 20 Sep 91 10:45:56 BST
If this is true then our 200+ nodes and our central site servers must
convert to V5 at the same time.
Not really. You could run v4 servers in parallel with v5 servers
until you manage to update all the v4 clients. The V5 kdc code
which answers V4 requests is an attempt to make this feasible, since it
allows you to have only one key database.
The problem really comes when you have a mix of v4 and v5 servers for
one application. For example, we have a conferencing system in which
one client program may access a dozen or more servers controlled by
numerous different parties. If people convert some of those meeting
servers to V5, but not others, you need to have both v4 and v5 support
in the client.
There is also a real mess with the seeding the V5 string to key, if
you care about V4 passwords working with a shared V5/V4 KDC. (This was
done so that 2 passwords would not yield the same DES keys in
different realms, to protect you from administrators.) You can't do it
until you have no V4 callers of krb_get_in_tkt around. The good news
is (I belive) that V5 can deal with not seeding the string to key
algorthim to let you get past this.
MIT has not moved toward using V5 in production and thus has not
squarely faced any of these issues.
-- Jon
