[OpenAFS] Re: More questions about the re-keying document

[Benjamin Kaduk]

On Fri, 26 Jul 2013, Andrew Deason wrote:

> 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
> clients first.

Well, or upgrade/patch the KDC.  Which might be preferable anyway -- 
giving the client control over the ticket enctype seems risky.

> 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).

This answers Stephen's follow-up question: "yes".

-Ben