Re: [kitten] Secdir last call review of draft-ietf-kitten-krb-spake-preauth-09

[Greg Hudson <[e-mail]>]

Thanks for the review.  I am working on an update to address this
feedback; here are answers where the feedback asked questions.

On 5/25/22 12:56, Barry Leiba via Datatracker wrote:>    Clients and
KDCs MUST implement the
>    edwards25519 group, but MAY choose not to offer or accept it by
>    default.
> 
> How can one tell, externally, whether edwards25519 is not implemented, or
> simply is being refused?

One cannot tell from the another endpoint.  The goal of this
mandatory-to-implement provision is to ensure that any two SPAKE preauth
implementations can be configured to interoperate.  This is similar to
analagous requirements in TLS (RFC 5246 section 9 and 8446 section 9.2),
although those document stop at mandating implementation.

>    Upon receipt of this AS-REQ, a KDC which
>    requires pre-authentication and supports SPAKE SHOULD reply with a
>    KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty
>    PA-SPAKE PA-DATA element
> 
> SHOULD?  Why might it not?  What happens if it doesn’t?  (So, why isn’t it
> MUST, and how can an implementor decide whether it’s OK not to?)

A principal might be configured to require specific pre-authentication
mechanisms.  Or a principal might have no associated long-term keys, in
which case only preauth mechanisms like PKINIT or FAST OTP (which do not
use long-term keys) can be offered.

> I do wonder, in Section 10.5, why “client implementations SHOULD provide a
> configuration option to disable encrypted timestamp on a per-realm basis”,
> rather than having encrypted timestamp disabled by default, and saying that
> they MAY provide an option to enable it on a per-realm basis.  Keep in mind
> that I’m not an expert here, so please just tell me if it’s obvious that that
> can’t work, or some such.

That feels ambitious for a SHOULD.  In an optimistic future it might
eventually make sense to disable encrypted timestamp by default, but I
don't think a client implementation could reasonably do so in the short
or medium term.