Revisiting weak enctypes off by default

[ghudson@MIT.EDU]

I've been asked to take responsibility for this issue.

Sam wrote:
> It's my recollection that we were going to revisit the question of
> whether to turn weak enctypes off by default for the beta.  Tom
> expressed a desire to do so, I expressed support if the appropriate
> documentation happened, and I'm not sure what other opinions were
> expressed.

There were a bunch of other opinions expressed, including concerns
that sites using AFS or old Java applications might have difficulty
with such a default.

After reviewing the situation, I am not sure that changing the
allow_weak_crypto default has a lot of value.  Three reasonably modern
versions of Kerberos (client, server, and KDC) will not use DES with
the current defaults unless the client or server principal only
contains DES keys.  A 1.7 kadmind will not generate DES keys for a new
principal by default (as of r21851).  The risks we might want to
mitigate are:

1. Historical DB entries containing DES keys are subject to
   brute-force attack as long as the KDC will issue tickets for those
   keys.  Turning off allow_weak_crypto on the KDC eliminates that
   risk, but I am not sure that most KDC operators would be happy with
   us unnecessarily surprising them with such a default (since it
   would break any legacy clients or applications which can only use
   DES).

2. Appeasing concerns that a client, server, or KDC might be
   manipulated into using DES via some kind of man-in-the-middle
   attack or bug.  (Even if there is no specific attack or bug which
   would do this, the simple fact that the code exists and is
   available for use is a legitimate concern.)  Turning off
   allow_weak_crypto eliminates most of that risk, but again, I am not
   sure that the use case justifies the default given the possibility
   of breaking legacy applications.

Independent of the 1.7 timeframe, several people in the January
conversation asked for a more granular approach to phasing out DES.  I
think if you want a more granular approach, you can get that by
removing single DES keys from user or service principals as desired.
Unfortunately, I don't see a current kadmin interface for removing
keys without a password or key change, but it would probably be easier
to write code to do that than it would be to add a new set of
profile options.

I did notice that our documentation had out-of-date lists of supported
enctypes (both for protocol communication and for kadmind), which I
have fixed and marked for 1.7 pullup.  I also noticed that
allow_weak_crypto isn't documented, which I will try to fix and mark
for pullup before the end of the week.