Re: [kitten] Murray Kucherawy's No Objection on draft-ietf-kitten-krb-spake-preauth-11: (with COMMENT)

[Nico Williams <[e-mail]>]

On Thu, Jan 18, 2024 at 01:15:08PM -0500, Greg Hudson wrote:
> > It would be nice to see clearer recommendations on achieving forward secrecy,
> > and on rotating the cookie.
> 
> SPAKE pre-authentication provides forward secrecy against post-compromise of
> the principal long-term key (typically a user password), but does not help
> against post-compromise of the KDC's own krbtgt keys.  I don't really
> anticipate KDC implementations trying to achieve forward secrecy against the
> latter threat.  Accordingly, I will remove the sentence talking about
> rotating the cookie encryption key.

This I-D is specifically targeted at using the existing password-
equivalent symmetric keys in the new pre-authentication mechanism.

Nothing in this I-D precludes the subsequent addition of a pre-
authentication mechanism that uses an augmented PAKE such that KDC
compromise does not immediately compromise user passwords.  Stolen
augmented PAKE password verifiers would then be subject to offline
dictionary attack, but sites would have time to make users change their
passwords.

Recovery from KDC compromise would further require changing all
services' long-term symmetric keys, and also would require changing the
realm's public keys for PKINIT.  It would be very useful if services'
long-term keys were all key agreement shared keys, with the realm's KDC
database storing both the shared keys and the services' public keys.
With such a service long-term symmetric key establishment scheme site
operators could change and publish the realm's key agreement public keys
and then all shared symmetric keys could get recomputed quickly
site-wide.  However such an extension is fully out of scope for this
I-D.  Further, I'm not sure that any implementor has the energy to
improve Kerberos in this way at this time.

Nico
--