[OpenAFS] AES Support ?

[John Hascall]

> John Hascall <john@iastate.edu> writes:
> > Date:    Wed, 26 Sep 2007 13:45:12 CDT
> > To:      Marcus Watts <mdw@spam.ifs.umich.edu>
> > cc:      openafs-info@openafs.org
> > From:    John Hascall <john@iastate.edu>
> > Subject: Re: [OpenAFS] AES Support ? 
> > 
> > Marcus Watts sez:
> > > > Jeffrey Altman
> > > > > John Hascall wrote:
> > > > > >>        What makes your cell "rxk5" capable is if you have an
> > > > > >> "afs-k5@YOUR-REALM" service key.
> > > > > > That seems icky.  Why does it have to have a different name?
> > > > > So that the clients have a way of knowing whether or not the cell
> > > > > supports the rxk5 protocol.
> > 
> > > > Wouldn't the normal Kerberos enctype negotiation do that?
> > > > That is, if the client asks for {AES,DES} and if it gets
> > > > back AES it knows it can use rxk5?
> > 
> > > Equating enctype with protocol seems unwise anyways.
> > 
> > Well isn't that specified in the rx header's security field anyway?
> > 
> > John
> 
> Not really.  The rx header just has the security index.
> 0 = no enc type at all.
> 1 = vab.
> 2 = rxkad (des,fcrypt)
> 3 = rxkad (*but not really)
> 5 = rxk5 (multiple enctypes)
> (and these indexes are really up to the application, rx
> doesn't demand this mapping at all.)
> 
> inside the rx challenge is the "level" - 0 = clear (insecure),
> 1 = auth (integrity only), 2 = integrity & privacy.
> the level and its interpretation are security mechanism specific
> and orthogonal to the enctype chosen.
> 
> inside the rx response is the ticket, which for rxk5 includes the session
> ticket enctype & the service ticket enctype (which can be different).
 
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).

Sure, I can see how until you upgrade all the file servers in
your cell you can't change your afs principal's to include keys
with enctypes other than DES, and you can't remove the DES-enctype
key until all clients are upgraded, but other than that it seems
it should work.   What I am I missing which would make it fail
otherwise?

John