First, I don't think I said this before, but to whomever wrote the rekeying
document and the instructions for 1.4 and 1.6, thanks! It's great that
these were available immediately, at the same time as the security
vulnerability.
I also think that eliminating DES is worth the pain of re-keying a cell and
upgrading clients, so a BIG thank you to Derrick Brashear, Alexander
Chernyakhovsky, Andrew Deason, Chaskiel M Grundman and Benjamin Kaduk for
developing the patches.
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).
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)?
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?
Cheers, Stephen
--
Stephen Joyce
Systems Specialist
College of Arts and Sciences
University of North Carolina at Chapel Hill
voice: 919.962.7214
fax: 919.962.0480
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
