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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-kitten-krb-spake-preauth-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** On a process note, I observe that:
-- the IETF LC on this document occurred 3.5 years ago (May 2020).  Is there
confidence on the consensus? -- the Shepherd Report from January 2019 is wrong
about IPR: there was an IPR claim filed in Jun 2020. -- the Shepherd Report
comments about referencing draft-irtf-cfrg-spake2-06.  That was published as
RFC9382 in September 2023.

** Section 2
   This
   mechanism uses a derivation similar to the second algorithm (SPAKE2)
   with differences in detail.

What does “differences in detail” mean?

** Section 2.  [SPAKE] needs to be a normative reference.  Likewise, as John
Scudder mentioned, please improve the current reference text with a DOI pointer.

** Section 4.1.
Per the SECDIR review discussion:

==[ snip ]==
>    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.

==[ snip ]==

Consider adding some version of this explanation to the text.  I also initially
have the same question.

** Section 12.1.1

   Reference:  URI or otherwise unique identifier for where the details
      of this algorithm can be found.  It should be as specific as
      reasonably possible.

Why is the Reference for "Kerberos Second Factor Types" defined as above but
the “Kerberos SPAKE Groups” registry defines references (e.g., Specification,
Serialization, etc) to as a “Reference to the definition ...).  Aren’t all of
these entries some version of “Specification Required”?

** Appendix B.  Python needs a normative reference.