[OpenAFS] AES Support ?

[Marcus Watts]

> Date:    Thu, 27 Sep 2007 15:05:01 CDT
> To:      Derrick J Brashear <shadow@dementia.org>
> cc:      openafs-info@openafs.org
> From:    John Hascall <john@iastate.edu>
> Subject: Re: [OpenAFS] AES Support ? 
> 
> 
> > On Thu, 27 Sep 2007, John Hascall wrote:
> > >   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
> 
> > actually, i think i'd upgrade the servers, then add the key, then upgrade 
> > the clients, then remove the old keyS
> 
>    Well, if that's doable, it would be a big win.  Thanks.
> 
> > for experimental deployment i'd use a 3rd key that clients needed to know 
> > about to use.
> 
>    I can see how doing the servers first, then the key,
>    basically switches the whole cell to the method at once.
> 
>    So, I'm not sure I'm following exactly, but I think you are
>    suggesting this as a way to test before then (which would
>    be a good thing).  You seem to imply that a clients can
>    somehow be manually instructed to use an arbitrary keyname
>    (say afs-k5-test) -- is this correct?   Then you could create
>    this key that other clients would not know about, and then
>    I am assuming you could also configure a test server in your
>    cell with this key name too?
> 
> Thanks,
> John

"The server" knows very little about the service name.  Whatever principals
are in /etc/openafs/server/keytab.afs are accepted without further qualification.

the 2 places where afs-k5 are known are:
/1/ klog/aklog
/2/ "-localauth" processing. (which includes ubik).

For /1/ if you wanted to specify a non-standard service principal you'd
have to hack various bits of logic.  This includes the calls to
get_afs_krb5_svc_princ and a bit of funny logic in aklog that only
gets DES if the service principal name is 3 characters long.

For /2/ you'd have to hack get_afs_krb5_localauth_svc_princ.  This
is ickier in that there are more commands that implement -localauth
and there are non-command interfaces (ubik) that do this as well.
It might be simplier to modify this logic to simply use the first
principal in the keytab as the "-localauth" principal.  Some of
the logic to do this is already there.

Having said that, I don't know why you would want to do this.
What would you learn with "a test server" in your production environment
that you could not better learn in a separate test cell?
What would you run on your test server anyways?  vlserver?  volserver?
How are you going to deal with all the interconnections of pt, vl,
vol, etc?  I'm sorry, but for some of things things (esp. ubik) I don't
see how you can avoid having a "flag" day inside your server environment,
and I don't see why you would want to avoid this either.

				-Marcus Watts