[OpenAFS] AES Support ?

Marcus Watts mdw@spam.ifs.umich.edu
Wed, 26 Sep 2007 15:58:00 -0400


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, if you *only* cared about rxkad/rxk5, you could "get away" with
using the enctype to decide whether to use rxk5 with openafs.  You'd have
some odd restrictions and configuration logic interdependencies that
could be hard to explain.  Also you would absolutely have to replace the
KeyFile support on the server.  You're not going to have any easy way to
extend this to also support rxgk or other possible security mechanisms
in the future.

			-Marcus Watts