[OpenAFS] AES Support ?

[Marcus Watts]

John Hascall <john@iastate.edu> writes:
>    By "not yet completed" I meant started.  If I'm understanding
>    the process as it was outlined many messages ago it was:
> 
>        1) create afs-k5 or (or is it k5-afs?) key
>        2) upgrade all your servers
>        3) upgrade all your clients
>        4) remove the old afs key

I think I must have received this out of order.  Nevertheless, the
steps are:

/0/ ahead of time, set up test cell.
	Make sure test cell works correctly.
	If desired, experiment with rxkad/rxk5 switchover.
	Take all your supported client configurations.
	Make sure those work.
	Obviously, if you were doing this today, you'd want
	to be particularly careful testing since you'd be a pioneer.
	This is why we value pioneers.

/1/ upgrade server software.  This can happen one by one.
	You can either replace server software in-place
	or you can do data migration.
	You can take as long as you like doing this.
	Data migration won't cause any visible change,
	server software upgrades may cause brief localized delays.
	During this point, everything uses rxkad, but the rxk5 code
	is getting installed server-side, as slowly as you like.

/2/ install afs-k5 keytab
	make an afs-k5 principal & keytab.
	At this point, any new clients will start breaking...
	So you'll want to do this during a maintenance window...
	So,
	install that afs-k5 principal & keytab on all servers.
	restart DB servers first.
	restart fileservers.

	After you complete /2/, all your ubik internal connections
	will be rxk5 only.  Users will still be able to use rxkad
	for all purposes - including administrative access, which
	means your real increase in security is not that great.
	This also means your risk isn't that great.  Your production
	world after /2/ should behave just like your test environment
	from /0/.

In parallel with /1/ and /2/ you can
/3/ upgrade clients
	You can take as long as you like doing this.
	upgraded clients done BEFORE /2/ happens will just use rxkad.
	During /2/ upgraded clients may see more weirdness.
	After /2/ ugpraded clients will work the new way
	Non-upgraded clients will also see some weirdness during /2/.
	After /2/ non-upgraded clients will continue to work the old way.

/4/ Remove the old afs key.
	You can do this anytime after you don't see usage of the
	afs key in your kdc logs with no visible impact.
	If you still see afs key usage you have not completed /3/
	or your users are using somebody else's clients...
	In any case the choice to do /4/ is completely a question
	of when you want to finish upgrading your security.

So here are some of the possible problems or risks I can think
of doing this:
/1/ server issues:
	software build problems.
	misconfiguration.
	other administrative mistakes.

/2/ client issues:
	software build problems.
	misconfiguration.
	generic client upgrade issues.
	authentication problems.

				-Marcus