On Thu, 25 Jul 2013, [email protected] 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
