[OpenAFS] More questions about the re-keying document

[Benjamin Kaduk]

On Thu, 25 Jul 2013, stephen@physics.unc.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).

This is actually a little subtle.  DES keys in the rxkad.keytab will not 
be used to decrypt incoming tokens (the codepath for tokens whose krb5 
tickets are encrypted with a DES enctype looks in the KeyFile, since we 
kept that codepath largely unchaged).  For *outgoing* connections, all 
keys in the rxkad.keytab are fair game; the key is selected by 
krb5_kt_get_entry(..., /*kvno*/ 0, /*enctype*/ 0, ...), so the library 
picks a default entry.  For MIT krb5, this should end up being the 
strongest key (so, aes256); with Heimdal, this is not always the case. 
I've seen at least one report of Heimdal's krb5_kt_get_entry() picking a 
DES key, which of course wasn't in the KeyFile on the receiving end and 
connections failed.

There's another MIT-specific reason to not include a DES key in the 
rxkad.keytab, namely that the MIT KDC does not set requires_preauth on new 
principals by default.  This means that if there's a DES key in the KDB, 
an unauthenticated attacker can make an AS_REQ with the afs principal as 
the "client principal", and claim to only support des-cbc-crc.  Since 
preauthentication is not required, the KDC will create an AS_REP and use 
the DES key from the KDB to encrypt the reply.  Now the attacker has a 
plaintext/ciphertext pair with which to mount an offline brute force 
attack.  The MIT KDC will always (*) assume that any principal supports a 
single-DES enctype (which is mandatory to implement), so even though the 
afs service principal does not have a DES key in the KDB, single-DES 
session keys will still be issued, allowing unpatched clients to work 
against the patched server.

(*) With the MIT krb5 1.11 release, there are ways to disable this "always 
assume DES is supported" behavior, though the default behavior has not 
changed.

> However in the "Basic" procedure for Heimdal, it does not mention any such 
> caution. My site's KDC is Heimdal and does include DES by default. I assume I 
> should similarly ensure DES isn't in the keytab (similar to the advice in the 
> MIT section)?

Heimdal's behavior about session key selection has varied quite a bit over 
time (there is a pending update to the rekeying document which attempts to 
cover this in more detail), and in some cases it is necessary to have a 
DES key in the KDB for the afs service principal in order for a DES 
session key to be generated (that is, for unpatched clients to continue to 
work).  Heimdal also (I am told) requires preauthentication by default, so 
the unauthenticated attacker cannot just ask the KDC for a ticket to 
attack.

> What the best practice for having enctypes availble on a principal on the KDC 
> vs. in the keytab. Obviously the keytab enctypes must be the same as, or a 
> subset of, the principal's enctypes. Does it hurt if DES (or other undesired 
> salts) exist for the afs/cell@REALM principal as long as they're not in the 
> rxkad.keytab file?

This does end up depending on the KDC, and the KDC configuration.
In some cases it is necessary to have the DES key in the KDB (in order to 
allow DES session keys), but if preauthentication is required, it is not 
harmful to do so.  If a DES key is in the rxkad.keytab, it must also be in 
the KeyFile.

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).  In all other cases, you 
should not have the DES key in the rxkad.keytab or KeyFile.  You can check 
whether your Heimdal KDC has this bug by using a DES-only client (with 
default_tgs_enctypes in krb5.conf, if needed) to request a service ticket 
(say, with kgetcred) for a service that has a non-DES key in the KDB.  If 
'klist -v' shows the Ticket etype as being des (as well as the sesion 
etype), then the KDC is buggy.

-Ben