From: Zhanna Tsitkov Date: Fri, 20 Jul 2012 20:58:28 +0000 (-0400) Subject: Remove outdated file migration.doc X-Git-Tag: krb5-1.11-alpha1~389 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c484dfd53da1b244b4a655f9c89bc115f0078e38;p=thirdparty%2Fkrb5.git Remove outdated file migration.doc --- diff --git a/src/kdc/migration.doc b/src/kdc/migration.doc deleted file mode 100644 index d3613ac0d1..0000000000 --- a/src/kdc/migration.doc +++ /dev/null @@ -1,59 +0,0 @@ -This document describes the protocols & procedures necessary to allow -a large krb4 site like MIT to migrate smoothly to krb5. - -The problem we have to solve is that v4 clients don't know about the v5 -string-to-key function, which incorporates the user's name, instance, and realm -into his private key, along with his password. -It happens that our solution also solves a related problem: the v5 str2key -function prevents a site from changing its realm-name, as when the company gets -bought by another. - -PROTOCOLS: - -The compatibilty kdc will mark v5-style entries with an attribute bit. - -the v5 get_in_tkt clients (kinit, login, etc) all will be able to perform -v4 str2key; this will allow users with v4 passwords to gain v5 tickets. -When a user's entry contains a v5-style password, and he uses v5 kinit, -the kinit protocol will have the kdc send a cleartext realm-unique string -(initially null) along with the (password+realm)-encrypted tgt. -When such a user runs v4 kinit, he loses. - -Mapping the realm-name to a realm-id string happens in a kdc-configuration file, -possibly in the first line of krb.conf . - -These things will not happen until we deploy a kpasswd that can replace -v4-style passwords with v5-style ones. -It would be nice to provide a "convert" flag, that allows you to upgrade -without having to change your password's text. - -PROCEDURES: - -Initially, administrators should deploy the v5 kdc (with its built-in -v4 compatibility), a v4 kadmin server, and a v5 kadmin server. -The v5 kadmin server will at this time continue to use the v4 str2key function, -so all of the passwords in the database will be v4 compatible. - -the compatibility versions of the get_in_tkt clients (kinit, login, etc) -should be deployed when most of the campus' software can handle v5. -When a v4 user runs v5 kinit, he gets v5 tickets unawares. -Vice-versa, the user loses. - -The users are then weaned from v4 in three (two?) steps: - first, we change kpasswd to convert v4-style passwords to v5-style, - once the site converts most of its various clients and daemons to v5 krb. - the kdc now needs to be able to send a non-null realm-id string to kinit. - - second, we turn off the v4 kadmin server (simultaneous with 1 or 3?). - - third, but optionally, we turn off the v4-compatibility glue in the kdc. - -Every user who runs the converting kpasswd becomes unable to run v4 clients -thereafter; we assume that a user who converts has continued access to -other v5 clients. the conversion code can warn him. - -We continue to run the v4 kadmin because users of v4 kpasswd may not yet have -ready access to v5 clients. - -Note that the database's conversion commences gradually with the deployment -of the converting kpasswd, so this deployment doesn't have to be instantaneous.