[OpenAFS] AES Support ?

[Marcus Watts]

John Hascall <john@iastate.edu> writes:
...
> Yes, but it's still not clear to me why the different principal
> name (afs-k5) is needed -- why a client can't just request an
> afs/foo@bar ticket (with whatever enctypes come back) and
> then construct an rx challenge with (rx_header.security = 5)
> which I am presuming that old servers will return an error message
> for, in which case it can fall back to (rx_header.security = 2).

Because the code path for that would be:
	get a ticket
	make an rxk5 security object
	retain the ticket.
	make an rx connection client object.
	make the initial RPC call.
	if the RPC call fails with the right error...
		tear down the rx connection client object.
		discard the rxk5 security object.
		make an rxkad object with the retained ticket.
		make a new rx connection client object.
		redo the RPC call with the new connection
	discard the retained ticket.
which is going to look even uglier in the source for ubik calls.

And, um, well, old servers *won't* return an error message.
They won't return anything at all.  So "the right error" above
means "after an obnoxious long delay".

				-Marcus