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

[Ballot comment]
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.

[Ballot comment]

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 ]

[Ballot 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.

[Ballot comment]
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.

[Ballot discuss]
[For the IESG to discuss]

I'd like to discuss some of the procedural stuff that's been raised by others before going to either ABSTAIN or NO OBJECTION.  Basically I have the same concerns as Eric: The shepherd writeup is 4+ years old and doesn't use an approved template; the directorate reviews are stale; IETF Last Call was 3+ years ago.  Maybe this is all fine, but I'd like to be sure we talk about it first.

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?

[Ballot comment]
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.

[Ballot comment]
Like Eric I am abstaining, simply because I don't really understand the process and somewhat odd timing.
I'm assuming that the responsible AD will be able to reassure me, at which point I'll happily convert this into a NoObjection.

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." :-)

[Ballot comment]
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/.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-kitten-krb-spake-preauth-11

Thank you for the work put into this document. Due to the very specialised content of this I-D, I only quickly browsed through it.

Please find below some non-blocking COMMENT points.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Global history of the document

I find the trajectory of this document really weird, hence my ABSTAIN:

* The outdated shepherd write-up is dated 2019-01-23 (i.e., it deserves a refresh about IPR & AD at least)
* The IETF Last call is dated 2020-05-12 https://mailarchive.ietf.org/arch/msg/ietf-announce/_PtiER1BI4UJGuSnX2LQn5R1xJU/ ending 2020-05-26
* There is an IPR declaration dated 2020-06-02
* 3.5 years later, it is at IESG evaluation

I am trusting the responsible AD for checking the last call comments/reviews and that the IPR declaration should not influence the intended status.

## Section 1.2

`this pre-authentication mechanism`, which one is this ? I guess the Kerberos one but it may be worth being clear on "this".

## Section 1.3

Suggest to expand "OTP" at first use.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-kitten-krb-spake-preauth-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Pre-authentication and Typed Data registry on the Kerberos Parameters registry page located at:

https://www.iana.org/assignments/kerberos-parameters/

the existing registration for:

Type: 151
Name: PA-SPAKE
Reference: [draft-ietf-kitten-krb-spake-preauth]

will have its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the Kerberos Second Factor Types registry.

IANA Question --> This document says that 'All specifications must be published prior to entry inclusion in the registry.' Does an I-D count as a published specification, or is the intention that an I-D must be published as an RFC before an assignment can be made?

For documents produced by other organizations, does making the document available online in any form count as publication?

IANA Question --> Where should this new registry be located? Does it belong on the Kerberos Parameters registry page located at:

https://www.iana.org/assignments/kerberos-parameters/

or, should it be added to another existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed via Specification Required as defined in RFC8126.

There is a single, initial registration in the new registry as follows:

ID Number Name Reference
------------------------------+-----------------+------------
-2147483648 to -1 Reserved for Private and/or Experimental Use
0 Reserved
1 SF-NONE [ RFC-to-be ]
2 to 2147483647 Unassigned

Third, a new registry is to be created called the Kerveros SPAKE Groups registry.

IANA Question --> Where should this new registry be located? Does it belong on the Kerberos Parameters registry page located at:

https://www.iana.org/assignments/kerberos-parameters/

or, should it be added to another existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed via Specification Required as defined in RFC8126.

The registry has values between -2147483648 to 2147483647, inclusive. Value 0 is reserved. There are four initial registrations in the new registry as follows:

ID Number: 1
Name: edwards25519
Specification: Section 4.1 of [RFC7748] (edwards25519)
Serialization: Section 3.1 of [RFC8032]
Multiplier Length: 32
Multiplier Conversion: Section 3.1 of [RFC8032]
SPAKE M Constant:
d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
SPAKE N Constant:
d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab
Hash function: SHA-256 ([RFC6234])


ID Number: 2
Name: P-256
Specification: Section 2.4.2 of [SEC2]
Serialization: Section 2.3.3 of [SEC1] (compressed format)
Multiplier Length: 32
Multiplier Conversion: Section 2.3.8 of [SEC1]
SPAKE M Constant:
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
SPAKE N Constant:
03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
Hash function: SHA-256 ([RFC6234])


ID Number: 3
Name: P-384
Specification: Section 2.5.1 of [SEC2]
Serialization: Section 2.3.3 of [SEC1] (compressed format)
Multiplier Length: 48
Multiplier Conversion: Section 2.3.8 of [SEC1]
SPAKE M Constant:
030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664
34b363d3dc36f15314739074d2eb8613fceec2853
SPAKE N Constant:
02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215
18f9c543bb252c5490214cf9aa3f0baab4b665c10
Hash function: SHA-384 ([RFC6234])

ID Number: 4
Name: P-521
Specification: Section 2.6.1 of [SEC2]
Serialization: Section 2.3.3 of [SEC1] (compressed format)
Multiplier Length: 66
Multiplier Conversion: Section 2.3.8 of [SEC1]
SPAKE M Constant:
02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1
8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5
6979962d7aa
SPAKE N Constant:
0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b
c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34
9d95575cd25
Hash function: SHA-512 ([RFC6234])

IANA Question --> How should the references to the Standards for Efficient Cryptography Group references appear in the registry?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-26):

From: The IESG
To: IETF-Announce
CC: kaduk@mit.edu, kitten-chairs@ietf.org, draft-ietf-kitten-krb-spake-preauth@ietf.org, kitten@ietf.org, Nicolas Williams , nico@cryptonector.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SPAKE Pre-Authentication) to Proposed Standard


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document: - 'SPAKE
Pre-Authentication'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a new pre-authentication mechanism for the
  Kerberos protocol that uses a password authenticated key exchange.
  This document has three goals.  First, increase the security of
  Kerberos pre-authentication exchanges by making offline brute-force
  attacks infeasible.  Second, enable the use of second factor
  authentication without relying on FAST.  This is achieved using the
  existing trust relationship established by the shared first factor.
  Third, make Kerberos pre-authentication more resilient against time
  synchronization errors by removing the need to transfer an encrypted
  timestamp from the client.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/



No IPR declarations have been submitted directly on this I-D.

Summary:
Nico Williams is the shepherd, Ben Kaduk is the responsible AD.

This document describes a new "pre-authentication" protocol for Kerberos
V5 [RFC4120], one that uses a zero-knowledge password proof for
authenticating a client principal to a Kerberos Authentication Server
(AS), part of the Kerberos key distribution center (KDC).  Besides
supporting the use of simple passwords, this method also supports second
factors.

Review and Consensus:
The KITTEN WG mailing list has had a number of threads on the topic of
Simple Password Authenticate Key Exchange (SPAKE) for Kerberos, and four
on this particular Internet-Draft.

Recent threads make it clear that this document is ready for
advancement.  Some participants have suggested additional features, but
there is consensus that these can be added as extensions to this
protocol in future updates (the protocol is extensible), or if need be
as a new protocol.

Intellectual Property:
There are no intellectual property disclosures against this document,
and all authors have confirmed compliance with BCPs 78 and 79.

Note:
This draft is targeting Proposed Standard status, and has a normative
down-reference to draft-irtf-cfrg-spake2-06, which draft is targeting
Informational status, and is not yet out of CFRG.

Summary:
Nico Williams is the shepherd, Ben Kaduk is the responsible AD.

This document describes a new "pre-authentication" protocol for Kerberos
V5 [RFC4120], one that uses a zero-knowledge password proof for
authenticating a client principal to a Kerberos Authentication Server
(AS), part of the Kerberos key distribution center (KDC).  Besides
supporting the use of simple passwords, this method also supports second
factors.

Review and Consensus:
The KITTEN WG mailing list has had a number of threads on the topic of
Simple Password Authenticate Key Exchange (SPAKE) for Kerberos, and four
on this particular Internet-Draft.

Recent threads make it clear that this document is ready for
advancement.  Some participants have suggested additional features, but
there is consensus that these can be added as extensions to this
protocol in future updates (the protocol is extensible), or if need be
as a new protocol.

Intellectual Property:
There are no intellectual property disclosures against this document,
and all authors have confirmed compliance with BCPs 78 and 79.

Note:
This draft is targeting Proposed Standard status, and has a normative
down-reference to draft-irtf-cfrg-spake2-06, which draft is targeting
Informational status, and is not yet out of CFRG.