Subject: | Need per-realm client configuration to deny encrypted timestamp |
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.
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.