[15920] in Kerberos-V5-bugs
[krbdev.mit.edu #8655] Need per-realm client configuration to deny
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Mon Mar 26 22:18:18 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8655@krbdev.mit.edu>
Message-ID: <rt-8655-48343.19.5970421564435@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8655'":;
Date: Mon, 26 Mar 2018 22:18:13 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
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.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
