[krbdev.mit.edu #8655] Need per-realm client configuration to deny encrypted timestamp

[Greg Hudson via RT]

The SPAKE draft security considerations say "Client implementations 
SHOULD provide a configuration option to disable encrypted timestamp 
on a per-realm basis to mitigate this attack."  Without this option, 
an active attacker can simply pretend that the KDC only supports 
encrypted timestamp, and get a dictionary-attackable ciphertext from 
the client using the attacker's choice of enctype (within the 
enctypes allowed by the client) and salt.

This option should stick through realm referrals, or at least ones 
that aren't authenticated with FAST.  Otherwise an active attacker 
can offer a referral to a different realm and then pretend that realm 
only supports encrypted timestamp.

To be determined:

* What should this option be named?  It's motivated by SPAKE, but 
there's no intention to suppress FAST OTP or PKINIT.

* Should this option also suppress SAM-2?  I'm not sure there's a 
need, as SAM-2 requires a checksum in the client key to operate, but 
we should double-check that.

* Should this option also suppress encrypted challenge?  Encrypted 
challenge isn't dictionary-attackable if used properly, though there 
is the possibility that the armor key isn't strong, and it offers no 
forward secrecy.