Kerberos SPAKE Pre-Authentication
draft-ietf-kitten-krb-spake-preauth-13

Thanks for this document. To the extent I was able to follow it as a decided non-expert, I found it clear and readable. I have just a few small notes that I hope may be helpful.

- Section 4.3 ends with the line,

   KEY_USAGE_SPAKE  65

  I understand this to be, that you're providing the reader with the IANA-assigned value. But without descriptive words around it, it's just puzzling and lacking in context. I think you could safely delete the line, since its information is included in Section 11 and in general it's desirable, in my experience, to have only a single source of truth for this kind of thing. Or otherwise, maybe you can work the information into the prose more smoothly.

- Although RFC 7322 section 4.8.6 provides shockingly little guidance about how to format your references, I still think you should try to do better than 

   [SPAKE]    Abdalla, M. and D. Pointcheval, "Simple Password-Based
              Encrypted Key Exchange Protocols", February 2005.

  which omits some of the usual things like what publication it appeared in. A few seconds of searching took me to https://dl.acm.org/doi/10.1007/978-3-540-30574-3_14, so assuming that authoritative perhaps something like the information provided there would be suitable? ("CT-RSA'05: Proceedings of the 2005 international conference on Topics in Cryptology February 2005 Pages 191–208")
  
- You might want to consider your usage of "man-in-the-middle" in light of https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/.

In Section 12, we're telling the Designated Experts that an I-D counts as a specification, even if it is never published as an RFC.  But an I-D can expire.  Are we OK with having an IANA registry with an entry that claims as its authoritative specification an expired I-D?

Section 12.2.2 appears to have four registrations all run together.  Could we separate them somehow, either with line breaks or with subsections?

Section 4.1: Why is this only a SHOULD?  Is it OK if I do something different?

Section 4.3: Same question.

===

Additional comments from incoming ART AD, Orie Steele:

9.  Hint for Authentication Sets

Why MAY and not SHOULD?

Phrasing around MUST NOT and must only could be clearer, and is possibly the reason for the MAYs?

10.2 Unauthenticated Plaintext

> Second factor
   types MUST account for this when specifying the semantics of the data
   field.

It's not clear (to me) how to comply with this MUST, an example of citation might help.

In 10.4

Several SHOULD's that maybe ought to be MUSTs?

It would be nice to see clearer recommendations on achieving forward secrecy, and on rotating the cookie.

** 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.

I'm going to steal John's opening comment, as it sums um my views nicely: "Thanks for this document. To the extent I was able to follow it as a decided non-expert, I found it clear and readable." :-)

[ Paul has reassured me that process is fine, converting from Abstain to NoObj ]