[OpenAFS] Re: More questions about the re-keying document
Fri, 26 Jul 2013 09:45:13 -0500
On Thu, 25 Jul 2013 19:12:54 -0400 (EDT)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> > In going over the re-keying document, a few more questions popped
> > into my mind that weren't clear from my reading of the document.
> > In the "Basic" procedure for MIT, it mentions ensuring that DES
> > should not be one of the encryption types in the rxkad.keytab file.
> > I assume this isn't a technical reason, but that having it there
> > would allow its continued use (so no gain in rekeying).
To summarize: in MIT you do not want any DES keys in rxkad.keytab or in
the KDC's db. In Heimdal you do not want any DES keys in rxkad.keytab,
but you must have a DES key in the KDC's db due to how it selects
session keys. (This is for all versions of Heimdal; there are no version
exceptions that I know of, besides a patch that Sergio is developing.)
The reason we don't want them in the keytab is so we don't use them for
server-to-server communication, and I think it's good to do so we don't
accidentally accept a connection using the DES key. (Normally the latter
is not a concern, since clients are not supposed to have influence over
what service ticket enctype is used.)
> Some versions of Heimdal have a KDC bug wherein the ticket enctype is
> always the same as the session key enctype; in these cases the DES key
> is needed in the rxkad.keytab (and the KeyFile).
No, this is not what I'm recommending, since it doesn't solve the
security issue at hand. The proposed changes to the document say that if
you're running a Heimdal KDC with this bug, you just need to upgrade all
If you have a DES key in the KDB for such a KDC, a client can make the
KDC issue a DES service ticket, and so an attacker can crack that
ticket, and use the cracked key against the servers (since they contain
the relevant key in the KeyFile).
The way I was recommending, if you upgrade all clients, they won't ever
get a DES session key or service ticket (since they'll all request
something stronger). If you access with a non-upgraded client,
authenticated access will fail. I was considering saying to remove the
DES key for KDCs with this bug, but I thought that may be a bit
confusing, and doesn't help the situation much...