> Date: Wed, 26 Sep 2007 08:38:05 CDT > To: [EMAIL PROTECTED] > cc: Marcus Watts <[EMAIL PROTECTED]>, openafs-info@openafs.org > From: John Hascall <[EMAIL PROTECTED]> > Subject: Re: [OpenAFS] AES Support ? > > Jeffrey Altman > > John Hascall wrote: > > >> What makes your cell "rxk5" capable is if you have an > > >> "[EMAIL PROTECTED]" 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? > > John
Doesn't quite work. If the kdc knows the service supports {AES,RC4,DES} then when a v5 client says it only does {DES}, the kdc will make up a session key using DES, *and* then encrypts it using AES. The client is now happy, but the existing server side rxkad v5 support can't hack that; it errors out right away when it gets that. In fact, it can't easily do anything better either - hacking up the KeyFile logic to support AES would be ugly. Equating enctype with protocol seems unwise anyways. -Marcus Watts _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info