<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="std" docName="draft-ietf-kitten-krb-spake-preauth-13" number="9588" consensus="true" ipr="trust200902" obsoletes="" updates="" tocInclude="true" symRefs="true" sortRefs="true" xml:lang="en" prepTime="2024-08-27T14:01:37" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth-13" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9588" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Kerberos SPAKE Pre-authentication">Kerberos Simple Password-Authenticated Key Exchange (SPAKE) Pre‑authentication</title>
    <seriesInfo name="RFC" value="9588" stream="IETF"/>
    <author fullname="Nathaniel McCallum" initials="N." surname="McCallum">
      <organization showOnFrontPage="true">Red Hat, Inc.</organization>
      <address>
        <email>nathaniel@mccallum.life</email>
      </address>
    </author>
    <author fullname="Simo Sorce" initials="S." surname="Sorce">
      <organization showOnFrontPage="true">Red Hat, Inc.</organization>
      <address>
        <email>ssorce@redhat.com</email>
      </address>
    </author>
    <author fullname="Robbie Harwood" initials="R." surname="Harwood">
      <organization showOnFrontPage="true">Red Hat, Inc.</organization>
      <address>
        <email>rharwood@pm.me</email>
      </address>
    </author>
    <author fullname="Greg Hudson" initials="G." surname="Hudson">
      <organization showOnFrontPage="true">MIT</organization>
      <address>
        <email>ghudson@mit.edu</email>
      </address>
    </author>
    <date month="08" year="2024"/>
    <area>SEC</area>
    <workgroup>kitten</workgroup>
    <keyword>example</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a new pre-authentication mechanism for
      the Kerberos protocol.  The mechanism uses a
      password-authenticated key exchange (PAKE) to prevent brute-force
      password attacks, and it may incorporate a second factor.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9588" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-properties-of-pake">Properties of PAKE</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pake-algorithm-selection">PAKE Algorithm Selection</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pake-and-two-factor-authent">PAKE and Two-Factor Authentication</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.4">
                <t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent="1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-spake-overview">SPAKE Overview</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-document-conventions">Document Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-prerequisites">Prerequisites</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pa-etype-info2">PA-ETYPE-INFO2</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cookie-support">Cookie Support</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-more-pre-authentication-dat">More Pre-authentication Data Required</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-spake-pre-authentication-me">SPAKE Pre-authentication Message Protocol</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-first-pass">First Pass</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-second-pass">Second Pass</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-third-pass">Third Pass</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-subsequent-passes">Subsequent Passes</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reply-key-strengthening">Reply Key Strengthening</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-optimizations">Optimizations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-spake-parameters-and-conver">SPAKE Parameters and Conversions</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transcript-hash">Transcript Hash</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-derivation">Key Derivation</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-second-factor-types">Second-Factor Types</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hint-for-authentication-set">Hint for Authentication Sets</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-spake-computations">SPAKE Computations</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unauthenticated-plaintext">Unauthenticated Plaintext</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-side-channels">Side Channels</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kdc-state">KDC State</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.5">
                <t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent="10.5" format="counter" sectionFormat="of" target="section-10.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dictionary-attacks">Dictionary Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.6">
                <t indent="0" pn="section-toc.1-1.10.2.6.1"><xref derivedContent="10.6" format="counter" sectionFormat="of" target="section-10.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-brute-force-attacks">Brute-Force Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.7">
                <t indent="0" pn="section-toc.1-1.10.2.7.1"><xref derivedContent="10.7" format="counter" sectionFormat="of" target="section-10.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-denial-of-service-attacks">Denial-of-Service Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.8">
                <t indent="0" pn="section-toc.1-1.10.2.8.1"><xref derivedContent="10.8" format="counter" sectionFormat="of" target="section-10.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reflection-attacks">Reflection Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.9">
                <t indent="0" pn="section-toc.1-1.10.2.9.1"><xref derivedContent="10.9" format="counter" sectionFormat="of" target="section-10.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reply-key-encryption-type">Reply Key Encryption Type</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.10">
                <t indent="0" pn="section-toc.1-1.10.2.10.1"><xref derivedContent="10.10" format="counter" sectionFormat="of" target="section-10.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-kdc-authentication">KDC Authentication</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-assigned-constants">Assigned Constants</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kerberos-second-factor-type">Kerberos Second-Factor Types</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2.1.2">
                  <li pn="section-toc.1-1.12.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.12.2.1.2.1.1"><xref derivedContent="12.1.1" format="counter" sectionFormat="of" target="section-12.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-template">Registration Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.12.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.12.2.1.2.2.1"><xref derivedContent="12.1.2" format="counter" sectionFormat="of" target="section-12.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kerberos-spake-groups">Kerberos SPAKE Groups</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2.2.2">
                  <li pn="section-toc.1-1.12.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.12.2.2.2.1.1"><xref derivedContent="12.2.1" format="counter" sectionFormat="of" target="section-12.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-template-2">Registration Template</xref></t>
                  </li>
                  <li pn="section-toc.1-1.12.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.12.2.2.2.2.1"><xref derivedContent="12.2.2" format="counter" sectionFormat="of" target="section-12.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-registry-contents-2">Initial Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1-module">ASN.1 Module</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-spake-m-and-n-value-selecti">SPAKE M and N Value Selection</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-vectors">Test Vectors</xref></t>
          </li>
          <li pn="section-toc.1-1.17">
            <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.18">
            <t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Kerberos protocol <xref target="RFC4120" format="default" sectionFormat="of" derivedContent="RFC4120"/> commonly uses
      password-derived long-term keys to secure the initial authentication
      exchange between a Kerberos client and a Key Distribution Center (KDC).
      As noted in <xref target="RFC4120" section="10" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4120#section-10" derivedContent="RFC4120"/>, an attacker can
      perform an offline dictionary attack against the password; this is performed either by
      initiating an authentication exchange to a principal for which the KDC
      does not require pre-authentication or after eavesdropping on a
      legitimate authentication exchange that uses encrypted timestamp
      pre-authentication (<xref target="RFC4120" section="5.2.7.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4120#section-5.2.7.2" derivedContent="RFC4120"/>).</t>
      <t indent="0" pn="section-1-2">This document defines a pre-authentication mechanism that
      authenticates using long-term keys but is resistant to offline dictionary
      attacks. The mechanism additionally enables the use of second-factor
      authentication without the need for a separately established secure
      channel, by leveraging the trust relationship established by the shared
      long-term key.</t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-properties-of-pake">Properties of PAKE</name>
        <t indent="0" pn="section-1.1-1">Password-authenticated key exchange (PAKE) algorithms <xref target="RFC8125" format="default" sectionFormat="of" derivedContent="RFC8125"/> provide several properties that defend against
        offline dictionary attacks and make them ideal for use in a Kerberos
        pre-authentication mechanism.
        </t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-1.1-2">
          <li pn="section-1.1-2.1" derivedCounter="1.">Each side of the exchange contributes entropy.</li>
          <li pn="section-1.1-2.2" derivedCounter="2.">Passive attackers cannot determine the shared key.</li>
          <li pn="section-1.1-2.3" derivedCounter="3.">Active attackers cannot perform a machine-in-the-middle
          attack.</li>
        </ol>
        <t indent="0" pn="section-1.1-3">These properties of PAKE allow us to establish high-entropy
        encryption keys resistant to offline brute-force attacks, even when
        the passwords used are weak (low entropy).</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-pake-algorithm-selection">PAKE Algorithm Selection</name>
        <t indent="0" pn="section-1.2-1">The SPAKE algorithm (defined in <xref target="SPAKE" format="default" sectionFormat="of" derivedContent="SPAKE"/>) works by
        encrypting the public keys of a Diffie-Hellman (DH) key exchange with a
        shared secret. SPAKE is selected for this pre-authentication mechanism
        for the following properties:
        </t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-1.2-2">
          <li pn="section-1.2-2.1" derivedCounter="1.">SPAKE's encryption method ensures that the result is a
          member of the underlying group, so it can be used with elliptic curve
          cryptography, which is believed to provide equivalent security levels
          to finite-field DH key exchange at much smaller key sizes.</li>
          <li pn="section-1.2-2.2" derivedCounter="2.">It can compute the shared key after just one message from each
          party, minimizing the need for additional round trips and state.</li>
          <li pn="section-1.2-2.3" derivedCounter="3.">It requires a small number of group operations; therefore, it can
          be implemented simply and efficiently.</li>
        </ol>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.3">
        <name slugifiedName="name-pake-and-two-factor-authent">PAKE and Two-Factor Authentication</name>
        <t indent="0" pn="section-1.3-1">Using PAKE in a pre-authentication mechanism also has another
        benefit when used as a component of two-factor authentication (2FA).
        2FA methods often require the secure transfer of plaintext material to
        the KDC for verification. This includes one-time passwords,
        challenge/response signatures, and biometric data. Encrypting this data
        using the long-term secret results in packets that are vulnerable to
        offline brute-force attacks on the password, using either an
        authentication tag or statistical properties of the 2FA credentials to
        determine whether a password guess is correct.</t>
        <t indent="0" pn="section-1.3-2">In "One-Time Password (OTP) Pre-Authentication"
        <xref target="RFC6560" format="default" sectionFormat="of" derivedContent="RFC6560"/>, this problem is mitigated 
        using flexible authentication secure tunneling (FAST) (<xref target="RFC6113" section="5.4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-5.4" derivedContent="RFC6113"/>), which uses a
        secondary trust relationship to create a secure encryption channel
        within which pre-authentication data can be sent. However, the
        requirement for a secondary trust relationship has proven to be
        cumbersome to deploy and often introduces third parties into the trust
        chain (such as certification authorities). These requirements make it
        difficult to enable FAST without manual configuration of client
        hosts. In contrast, SPAKE pre-authentication, can create a secure
        encryption channel implicitly, using the key exchange to negotiate a
        high-entropy encryption key. This key can then be used to securely
        encrypt 2FA plaintext data without the need for a secondary trust
        relationship. Further, if the second-factor verifiers are sent at the
        same time as the first-factor verifier, and the KDC is careful to
        prevent timing attacks, then an online brute-force attack cannot be
        used to attack the factors separately.</t>
        <t indent="0" pn="section-1.3-3">For these reasons, this document departs from the advice given in
        <xref target="RFC6113" section="1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-1" derivedContent="RFC6113"/>, which states:
        "Mechanism designers should design FAST factors, instead of new
        pre-authentication mechanisms outside of FAST." However, the SPAKE
        pre-authentication mechanism does not intend to replace FAST and may
        be used with it to further conceal the metadata of the Kerberos
        messages.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.4">
        <name slugifiedName="name-spake-overview">SPAKE Overview</name>
        <t indent="0" pn="section-1.4-1">The SPAKE algorithm can be broadly described in a series of four
        steps:</t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-1.4-2">
          <li pn="section-1.4-2.1" derivedCounter="1.">Calculation and exchange of the public key</li>
          <li pn="section-1.4-2.2" derivedCounter="2.">Calculation of the shared secret (K)</li>
          <li pn="section-1.4-2.3" derivedCounter="3.">Derivation of an encryption key (K')</li>
          <li pn="section-1.4-2.4" derivedCounter="4.">Verification of the derived encryption key (K')</li>
        </ol>
        <t indent="0" pn="section-1.4-3">In this mechanism, key verification happens implicitly by a
        successful decryption of the 2FA data or of a placeholder value when
        no second factor is required. This mechanism uses a tailored method of
        deriving encryption keys from the calculated shared secret K, for
        several reasons:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1.4-4">
          <li pn="section-1.4-4.1">to fit within the framework of <xref target="RFC3961" format="default" sectionFormat="of" derivedContent="RFC3961"/>,</li>
          <li pn="section-1.4-4.2">to ensure negotiation integrity using a transcript
        hash,</li>
          <li pn="section-1.4-4.3">to derive different keys for each use, and</li>
          <li pn="section-1.4-4.4">to bind the KDC-REQ-BODY to the pre-authentication exchange.</li>
        </ul>
      </section>
    </section>
    <section anchor="conventions" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-document-conventions">Document Conventions</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">This document refers to numerous terms and protocol messages defined
      in <xref target="RFC4120" format="default" sectionFormat="of" derivedContent="RFC4120"/>.</t>
      <t indent="0" pn="section-2-3">The terms "encryption type", "key generation seed length", and
      "random-to-key" are defined in <xref target="RFC3961" format="default" sectionFormat="of" derivedContent="RFC3961"/>.</t>
      <t indent="0" pn="section-2-4">The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED",
      "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED",
      "pre-authentication facility", and "authentication set" are defined in
      <xref target="RFC6113" format="default" sectionFormat="of" derivedContent="RFC6113"/>.</t>
      <t indent="0" pn="section-2-5"><xref target="SPAKE" format="default" sectionFormat="of" derivedContent="SPAKE"/> defines SPAKE as a family of two key-exchange algorithms differing only in derivation of the final key. This
      mechanism uses a derivation similar to the second algorithm (SPAKE2). For
      simplicity, this document refers to the algorithm as "SPAKE".</t>
      <t indent="0" pn="section-2-6">The terms "Abstract Syntax Notation One (ASN.1)" and "Distinguished Encoding Rules (DER)" are defined in <xref target="ITU-T.X680.2021" format="default" sectionFormat="of" derivedContent="ITU-T.X680.2021"/> and <xref target="ITU-T.X690.2021" format="default" sectionFormat="of" derivedContent="ITU-T.X690.2021"/>,
      respectively.</t>
      <t indent="0" pn="section-2-7">When discussing operations within algebraic groups, this document
      uses additive notation (as described in <xref target="RFC6090" section="2.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6090#section-2.2" derivedContent="RFC6090"/>). Group elements are denoted with
      uppercase letters, while scalar multiplier values are denoted with
      lowercase letters.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-prerequisites">Prerequisites</name>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-pa-etype-info2">PA-ETYPE-INFO2</name>
        <t indent="0" pn="section-3.1-1">This mechanism requires the initial KDC pre-authentication state to
        contain a singular reply key. Therefore, a KDC that offers SPAKE
        pre-authentication as a stand-alone mechanism <bcp14>MUST</bcp14>
        supply a PA-ETYPE-INFO2 value containing a single ETYPE-INFO2-ENTRY,
        following the guidance in <xref target="RFC6113" section="2.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-2.1" derivedContent="RFC6113"/>. PA-ETYPE-INFO2 is specified in <xref target="RFC4120" section="5.2.7.5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4120#section-5.2.7.5" derivedContent="RFC4120"/>.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-cookie-support">Cookie Support</name>
        <t indent="0" pn="section-3.2-1">KDCs that implement SPAKE pre-authentication <bcp14>MUST</bcp14>
        have some secure mechanism for retaining state between authentication service requests (AS-REQs). For
        stateless KDC implementations, this method will most commonly be an
        encrypted PA-FX-COOKIE. Clients that implement SPAKE
        pre-authentication <bcp14>MUST</bcp14> support PA-FX-COOKIE, as
        described in <xref target="RFC6113" section="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-5.2" derivedContent="RFC6113"/>.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-more-pre-authentication-dat">More Pre-authentication Data Required</name>
        <t indent="0" pn="section-3.3-1">Both KDCs and clients that implement SPAKE pre-authentication <bcp14>MUST</bcp14>
        support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described in
        <xref target="RFC6113" section="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-5.2" derivedContent="RFC6113"/>.</t>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-spake-pre-authentication-me">SPAKE Pre-authentication Message Protocol</name>
      <t indent="0" pn="section-4-1">This mechanism uses the reply key and provides the client
      authentication and strengthening reply key pre-authentication facilities
      (<xref target="RFC6113" section="3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-3" derivedContent="RFC6113"/>). When the mechanism completes
      successfully, the client will have proved knowledge of the original
      reply key and possibly a second factor, and the reply key will be
      strengthened to a more uniform distribution based on the PAKE
      exchange. This mechanism also ensures the integrity of the KDC-REQ-BODY
      contents. This mechanism can be used in an authentication set; no
      pa-hint value is required or defined.</t>
      <t indent="0" pn="section-4-2">This mechanism negotiates a choice of group for the SPAKE algorithm.
      Groups are defined in the "Kerberos SPAKE Groups" registry created
      by this document (see <xref target="SPAKE-Groups" format="default" sectionFormat="of" derivedContent="Section 12.2"/>). Each group definition specifies an associated hash
      function, which will be used for transcript protection and key
      derivation. Clients and KDCs <bcp14>MUST</bcp14> implement the edwards25519 group, but they
      <bcp14>MAY</bcp14> choose not to offer or accept it by default.</t>
      <t indent="0" pn="section-4-3">The subsections that follow will describe the flow of messages when performing SPAKE
      pre-authentication. We will begin by explaining the most verbose version
      of the protocol, which all implementations <bcp14>MUST</bcp14> support. Then, we will
      describe several optional optimizations to reduce round trips.</t>
      <t indent="0" pn="section-4-4">Mechanism messages are communicated using PA-DATA elements within the
      padata field of KDC-REQ messages or within the METHOD-DATA in the e-data
      field of KRB-ERROR messages. All PA-DATA elements for this mechanism
      <bcp14>MUST</bcp14> use the following padata-type:
      </t>
      <dl indent="3" newline="false" spacing="normal" pn="section-4-5">
        <dt pn="section-4-5.1">PA-SPAKE</dt>
        <dd pn="section-4-5.2">151</dd>
      </dl>
      <t indent="0" pn="section-4-6">
      The padata-value for all PA-SPAKE PA-DATA values <bcp14>MUST</bcp14> be empty or
      contain a DER encoding for the ASN.1 type PA-SPAKE.</t>
      <sourcecode type="asn.1" markers="false" pn="section-4-7">
PA-SPAKE ::= CHOICE {
    support     [0] SPAKESupport,
    challenge   [1] SPAKEChallenge,
    response    [2] SPAKEResponse,
    encdata     [3] EncryptedData,
    ...
}
</sourcecode>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-first-pass">First Pass</name>
        <t indent="0" pn="section-4.1-1">The SPAKE pre-authentication exchange begins when the client sends
        an initial authentication service request (AS-REQ) without
        pre-authentication data. Upon receipt of this AS-REQ, a KDC that
        requires pre-authentication and supports SPAKE <bcp14>SHOULD</bcp14>
        (unless configuration indicates otherwise) reply with a
        KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty
        PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA
        elements). This message indicates to the client that the KDC supports
        SPAKE pre-authentication.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-second-pass">Second Pass</name>
        <t indent="0" pn="section-4.2-1">Once the client knows that the KDC supports SPAKE pre-authentication
        and the client wants to use it, the client will generate a new
        AS-REQ message containing a PA-SPAKE PA-DATA element using the support
        choice. This message indicates to the KDC which groups the client
        prefers for the SPAKE operation. The group numbers are defined in the 
        "Kerberos SPAKE Groups" registry (see <xref target="SPAKE-Groups" format="default" sectionFormat="of" derivedContent="Section 12.2"/>). The group's
        sequence is ordered from the most preferred group to the least preferred
        group.</t>
        <sourcecode type="asn.1" markers="false" pn="section-4.2-2">
SPAKESupport ::= SEQUENCE {
    groups      [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
    ...
}
</sourcecode>
        <t indent="0" pn="section-4.2-3">Upon receipt of the support message, the KDC will select a
        group. The KDC <bcp14>SHOULD</bcp14> choose a group from the groups provided by the
        support message. However, if the support message does not contain any
        group that is supported by the KDC, the KDC <bcp14>MAY</bcp14> select another group in
        hopes that the client might support it. Otherwise, the KDC <bcp14>MUST</bcp14> respond
        with a KDC_ERR_PREAUTH_FAILED error.</t>
        <t indent="0" pn="section-4.2-4">The group selection determines the group order, which shall be a
        large prime p multiplied by a small cofactor h (possibly 1), 
        a generator P of a prime-order subgroup, and two masking points M and
        N. The KDC selects a random integer x in the range 0 &lt;= x &lt; h*p,
        which <bcp14>MUST</bcp14> be divisible by h. The KDC computes a public key T=x*P+w*M,
        where w is computed from the initial reply key according to <xref target="spakeparams" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
        <t indent="0" pn="section-4.2-5">The KDC will reply to the client with a
        KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA-DATA
        element using the challenge choice.</t>
        <sourcecode type="asn.1" markers="false" pn="section-4.2-6">
SPAKEChallenge ::= SEQUENCE {
    group       [0] Int32,
    pubkey      [1] OCTET STRING,
    factors     [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor,
    ...
}
</sourcecode>
        <t indent="0" pn="section-4.2-7">The group field indicates the KDC-selected group 
        used for all SPAKE calculations as defined in the "Kerberos SPAKE
        Groups" registry (see <xref target="SPAKE-Groups" format="default" sectionFormat="of" derivedContent="Section 12.2"/>).</t>
        <t indent="0" pn="section-4.2-8">The pubkey field indicates the KDC's public key T, serialized
        according to <xref target="spakeparams" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
        <t indent="0" pn="section-4.2-9">The factors field contains an unordered list of second factors,
        which can be used to complete the authentication. Each second factor
        is represented by a SPAKESecondFactor.</t>
        <sourcecode type="asn.1" markers="false" pn="section-4.2-10">
SPAKESecondFactor ::= SEQUENCE {
    type        [0] Int32,
    data        [1] OCTET STRING OPTIONAL
}
</sourcecode>
        <t indent="0" pn="section-4.2-11">The type field is a unique integer that identifies the second-factor type. The factors field of SPAKEChallenge <bcp14>MUST NOT</bcp14> contain more than one SPAKESecondFactor with the same type
        value.</t>
        <t indent="0" pn="section-4.2-12">The data field contains optional challenge data. The contents in
        this field will depend upon the second-factor type chosen. Note that
        this challenge is initially transmitted as unauthenticated plaintext;
        see <xref target="unauthtext" format="default" sectionFormat="of" derivedContent="Section 10.2"/>.</t>
        <t indent="0" pn="section-4.2-13">The client and KDC will each initialize a transcript hash (<xref target="transcript" format="default" sectionFormat="of" derivedContent="Section 6"/>) using the hash function associated with the
        chosen group and update it with the concatenation of the DER-encoded
        PA-SPAKE messages sent by the client and the KDC.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-third-pass">Third Pass</name>
        <t indent="0" pn="section-4.3-1">Upon receipt of the challenge message, the client observes which
        group was selected by the KDC and deserializes the KDC's public key
        T. The client selects a random integer y in the range 0 &lt;= x &lt;
        h*p, which <bcp14>MUST</bcp14> be divisible by h. The client computes a public key
        S=y*P+w*N, where w is computed from the initial reply key according to
        <xref target="spakeparams" format="default" sectionFormat="of" derivedContent="Section 5"/>. The client computes a shared group
        element K=y*(T-w*M).</t>
        <t indent="0" pn="section-4.3-2">The client will then choose one of the second-factor types listed in
        the factors field of the challenge message and gather whatever data is
        required for the chosen second-factor type, possibly using the
        associated challenge data. Finally, the client will send an AS-REQ
        containing a PA-SPAKE PA-DATA element using the response choice.</t>
        <sourcecode type="asn.1" markers="false" pn="section-4.3-3">
SPAKEResponse ::= SEQUENCE {
    pubkey      [0] OCTET STRING,
    factor      [1] EncryptedData, -- SPAKESecondFactor
    ...
}
</sourcecode>
        <t indent="0" pn="section-4.3-4">The client and KDC will update the transcript hash with the pubkey
        value and use the resulting hash for all encryption key
        derivations.</t>
        <t indent="0" pn="section-4.3-5">The pubkey field indicates the client's public key S, serialized
        according to <xref target="spakeparams" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
        <t indent="0" pn="section-4.3-6">The factor field indicates the client's chosen second-factor data.
        The key for this field is K'[1] (specified in <xref target="keyderiv" format="default" sectionFormat="of" derivedContent="Section 7"/>). The kvno field of the EncryptedData sequence is
        omitted. The key usage number for the encryption is
        KEY_USAGE_SPAKE. The plaintext inside the EncryptedData is an encoding
        of the SPAKESecondFactor. Once decoded, the SPAKESecondFactor provides the
        type of the second factor and any optional data used. The contents of
        the data field will depend on the second-factor type chosen. The client
        <bcp14>MUST NOT</bcp14> send a response containing a second-factor type that was not
        listed in the factors field of the challenge message.</t>
        <t indent="0" pn="section-4.3-7">When the KDC receives the response message from the client, it
        deserializes the client's public key S, and computes the shared group
        element K=x*(S-w*N). The KDC derives K'[1] and decrypts the factors
        field. If decryption is successful, the first factor is successfully
        validated. The KDC then validates the second factor. If either factor
        fails to validate, the KDC <bcp14>MUST</bcp14> respond with a KDC_ERR_PREAUTH_FAILED
        error.</t>
        <t indent="0" pn="section-4.3-8">If validation of the second factor requires further round trips, the
        KDC <bcp14>MUST</bcp14> reply to the client with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error
        containing a PA-SPAKE PA-DATA element using the encdata choice. The
        kvno field of the EncryptedData sequence is omitted. The key for the
        EncryptedData value is K'[2] (specified in <xref target="keyderiv" format="default" sectionFormat="of" derivedContent="Section 7"/>),
        and the key usage number is KEY_USAGE_SPAKE. The plaintext of this
        message contains a DER-encoded SPAKESecondFactor message. As before,
        the type field of this message will contain the second-factor type and
        the data field will, optionally, contain data specific to the second-factor type.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
        <name slugifiedName="name-subsequent-passes">Subsequent Passes</name>
        <t indent="0" pn="section-4.4-1">Any number of additional round trips may occur using the encdata
        choice. The contents of the plaintexts are specific to the second-factor type.

	If a client receives a PA-SPAKE PA-DATA element using the
        encdata choice from the KDC, it <bcp14>MUST</bcp14> reply with a subsequent AS-REQ
        with a PA-SPAKE PA-DATA element using the encdata choice or abort the AS
        exchange.</t>
        <t indent="0" pn="section-4.4-2">The key for client-originated encdata messages in subsequent passes
        is K'[3] (specified in <xref target="keyderiv" format="default" sectionFormat="of" derivedContent="Section 7"/>) for the first
        subsequent pass, K'[5] for the second, and so on. The key for
        KDC-originated encdata messages is K'[4] for the first subsequent
        pass, K'[6] for the second, and so on.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-4.5">
        <name slugifiedName="name-reply-key-strengthening">Reply Key Strengthening</name>
        <t indent="0" pn="section-4.5-1">When the KDC has successfully validated both factors, the reply key
        is strengthened and the mechanism is complete.  The strengthening of
        the reply key is accomplished by the client and KDC replacing it with
        K'[0] (as specified in <xref target="keyderiv" format="default" sectionFormat="of" derivedContent="Section 7"/>). The KDC then replies
        with a KDC-REP message or continues on to the next mechanism in the
        authentication set. There is no final PA-SPAKE PA-DATA message from
        the KDC to the client.</t>
        <t indent="0" pn="section-4.5-2">Reply key strengthening occurs only once: at the end of the exchange. The client and KDC <bcp14>MUST</bcp14> use the initial reply key as the
        base key for all K'[n] derivations.</t>
      </section>
      <section anchor="optimizations" numbered="true" removeInRFC="false" toc="include" pn="section-4.6">
        <name slugifiedName="name-optimizations">Optimizations</name>
        <t indent="0" pn="section-4.6-1">The full protocol has two possible optimizations.</t>
        <t indent="0" pn="section-4.6-2">First, the KDC <bcp14>MAY</bcp14> reply to the initial AS-REQ (containing no
        pre-authentication data) with a PA-SPAKE PA-DATA element using the
        challenge choice instead of an empty padata-value. In this case, the
        KDC optimistically selects a group that the client may not
        support. If the group chosen by the challenge message is supported by
        the client, the client <bcp14>MUST</bcp14> skip to the third pass by issuing an
        AS-REQ with a PA-SPAKE message using the response choice. In this case,
        no SPAKESupport message is sent by the client, so the first update to
        the transcript hash contains only the KDC's optimistic challenge. If
        the KDC's chosen group is not supported by the client, the client <bcp14>MUST</bcp14>
        continue to the second pass. In this case, both the client and KDC <bcp14>MUST</bcp14>
        reinitialize the transcript hash for the client's support message.
        Clients <bcp14>MUST</bcp14> support this optimization.</t>
        <t indent="0" pn="section-4.6-3">Second, clients <bcp14>MAY</bcp14> skip the first pass and send an AS-REQ with a
        PA-SPAKE PA-DATA element using the support choice. If the KDC accepts
        the support message and generates a challenge, it <bcp14>MUST</bcp14> include a
        PA-ETYPE-INFO2 value within the METHOD-DATA of the
        KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may
        not otherwise be able to compute the initial reply key. If the KDC
        cannot continue with SPAKE (either because the initial reply key type is
        incompatible with SPAKE or because it does not support any of the
        client's groups) but can offer other pre-authentication mechanisms, the KDC
        <bcp14>MUST</bcp14> respond with a KDC_ERR_PREAUTH_FAILED error containing METHOD-DATA
        for the available mechanisms. A client supporting this optimization
        <bcp14>MUST</bcp14> continue after a KDC_ERR_PREAUTH_FAILED error as described in
        <xref target="RFC6113" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-2" derivedContent="RFC6113"/>. KDCs <bcp14>MUST</bcp14> support this
        optimization.</t>
      </section>
    </section>
    <section anchor="spakeparams" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-spake-parameters-and-conver">SPAKE Parameters and Conversions</name>
      <t indent="0" pn="section-5-1">Group elements are converted to and from octet strings using the
      serialization method defined in the "Kerberos SPAKE Groups" registry
       (see <xref target="SPAKE-Groups" format="default" sectionFormat="of" derivedContent="Section 12.2"/>).</t>
      <t indent="0" pn="section-5-2">The SPAKE algorithm requires constants M and N for each group. These
      constants are defined in the "Kerberos SPAKE Groups" registry
      (see <xref target="SPAKE-Groups" format="default" sectionFormat="of" derivedContent="Section 12.2"/>).</t>
      <t indent="0" pn="section-5-3">The SPAKE algorithm requires a shared secret input w to be used as a
      scalar multiplier. This value <bcp14>MUST</bcp14> be produced from the initial reply key
      as follows:
      </t>
      <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-5-4">
        <li pn="section-5-4.1" derivedCounter="1.">Determine the length of the multiplier octet string as defined in
        the "Kerberos SPAKE Groups" registry (see <xref target="SPAKE-Groups" format="default" sectionFormat="of" derivedContent="Section 12.2"/>).</li>
        <li pn="section-5-4.2" derivedCounter="2.">Compose a pepper string by concatenating the string "SPAKEsecret"
        and the group number as a big-endian four-byte two's complement binary
        number.</li>
        <li pn="section-5-4.3" derivedCounter="3.">Produce an octet string of the required length using PRF+(K,
        pepper), where K is the initial reply key and PRF+ is as defined in
        <xref target="RFC6113" section="5.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-5.1" derivedContent="RFC6113"/>.</li>
        <li pn="section-5-4.4" derivedCounter="4.">Convert the octet string to a multiplier scalar using the
        multiplier conversion method defined in the "Kerberos SPAKE
        Groups" registry (see <xref target="SPAKE-Groups" format="default" sectionFormat="of" derivedContent="Section 12.2"/>).</li>
      </ol>
      <t indent="0" pn="section-5-5">The KDC chooses a secret scalar value x and the client chooses a
      secret scalar value y. As required by the SPAKE algorithm, these values
      are chosen randomly and uniformly. The KDC and client <bcp14>MUST NOT</bcp14> reuse x
      or y values for authentications involving different initial reply
      keys (see <xref target="kdcstate" format="default" sectionFormat="of" derivedContent="Section 10.4"/>).</t>
    </section>
    <section anchor="transcript" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-transcript-hash">Transcript Hash</name>
      <t indent="0" pn="section-6-1">The transcript hash is an octet string of length equal to the output
      length of the hash function associated with the selected group. All bits are set to zero in the initial value.</t>
      <t indent="0" pn="section-6-2">When the transcript hash is updated with an octet string input, the
      new value is the hash function computed over the concatenation of the
      old value and the input.</t>
      <t indent="0" pn="section-6-3">In the normal message flow or with the second optimization described
      in <xref target="optimizations" format="default" sectionFormat="of" derivedContent="Section 4.6"/>, the transcript hash is:</t>
      <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-6-4"><li pn="section-6-4.1" derivedCounter="1.">updated
      with the concatenation of the client's support message and the KDC's
      challenge, then</li>
        <li pn="section-6-4.2" derivedCounter="2.">updated a second time with the client's pubkey
      value.</li>
      </ol>
      <t indent="0" pn="section-6-5">Therefore, it incorporates the client's supported groups, the
      KDC's chosen group, the KDC's initial second-factor messages, and the
      client and KDC public values. Once the transcript hash is finalized, it
      is used without change for all key derivations (<xref target="keyderiv" format="default" sectionFormat="of" derivedContent="Section 7"/>). In particular, encrypted second-factor messages are
      not included in the transcript hash.</t>
      <t indent="0" pn="section-6-6">If the first optimization described in <xref target="optimizations" format="default" sectionFormat="of" derivedContent="Section 4.6"/>
      is used successfully, the transcript hash is first updated with the
      KDC's challenge message and updated a second time with the client's pubkey value.</t>
      <t indent="0" pn="section-6-7">If the first optimization is used unsuccessfully (i.e., the client does
      not accept the KDC's selected group), the transcript hash is computed as
      in the normal message flow, without including the KDC's optimistic
      challenge.</t>
    </section>
    <section anchor="keyderiv" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-key-derivation">Key Derivation</name>
      <t indent="0" pn="section-7-1">Implementations <bcp14>MUST NOT</bcp14> use the shared group element (denoted by K)
      directly for any cryptographic operation. Instead, the SPAKE result is
      used to derive keys K'[n] (defined in this section).</t>
      <t indent="0" pn="section-7-2">First, compute the hash function associated with the selected group
      over the concatenation of the following values:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7-3">
        <li pn="section-7-3.1">The fixed string "SPAKEkey".</li>
        <li pn="section-7-3.2">The group number as a big-endian four-byte two's complement binary
        number.</li>
        <li pn="section-7-3.3">The encryption type of the initial reply key as a big-endian
        four-byte two's complement binary number.</li>
        <li pn="section-7-3.4">The PRF+ output used to compute the initial secret input w (as specified in <xref target="spakeparams" format="default" sectionFormat="of" derivedContent="Section 5"/>).</li>
        <li pn="section-7-3.5">The SPAKE result K, converted to an octet string (as specified in
        <xref target="spakeparams" format="default" sectionFormat="of" derivedContent="Section 5"/>).</li>
        <li pn="section-7-3.6">The transcript hash.</li>
        <li pn="section-7-3.7">The KDC-REQ-BODY encoding for the request being sent or responded
        to. Within a FAST channel, the inner KDC-REQ-BODY encoding <bcp14>MUST</bcp14> be
        used.</li>
        <li pn="section-7-3.8">The value n as a big-endian, four-byte, and unsigned binary number.</li>
        <li pn="section-7-3.9">A single-byte block counter with the initial value 0x01.</li>
      </ul>
      <t indent="0" pn="section-7-4">
      If the hash output is too small for the encryption type's key generation
      seed length, the block counter value is incremented and the hash
      function is recomputed to produce as many blocks as are required. The
      result is truncated to the key generation seed length, and the
      random-to-key function is used to produce an intermediate key with the
      same encryption type as the initial reply key.</t>
      <t indent="0" pn="section-7-5">The key K'[n] has the same encryption type as the initial reply key,
      and has the value KRB-FX-CF2(initial-reply-key, intermediate-key,
      "SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in <xref target="RFC6113" section="5.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-5.1" derivedContent="RFC6113"/>.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-second-factor-types">Second-Factor Types</name>
      <t indent="0" pn="section-8-1">This document defines one second-factor type:</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-8-2">
        <dt pn="section-8-2.1">SF-NONE</dt>
        <dd pn="section-8-2.2">1</dd>
      </dl>
      <t indent="0" pn="section-8-3">This second-factor type indicates that no second factor is used.
      Whenever a SPAKESecondFactor is used with SF-NONE, the data field <bcp14>MUST</bcp14> be
      omitted. The SF-NONE second factor always successfully validates.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-hint-for-authentication-set">Hint for Authentication Sets</name>
      <t indent="0" pn="section-9-1">If a KDC offers SPAKE pre-authentication as part of an authentication
      set (<xref target="RFC6113" section="5.3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6113#section-5.3" derivedContent="RFC6113"/>), it <bcp14>SHOULD</bcp14> provide a
      pa-hint value containing the DER encoding of the ASN.1 type
      PA-SPAKE-HINT. This helps the client determine whether SPAKE
      pre-authentication is likely to succeed if the authentication set is
      chosen.</t>
      <sourcecode type="asn.1" markers="false" pn="section-9-2">
PA-SPAKE-HINT ::= SEQUENCE {
    groups      [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
    factors     [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor
}
</sourcecode>
      <t indent="0" pn="section-9-3">The groups field indicates the KDC's supported groups. The factors
      field indicates the KDC's supported second factors. The KDC <bcp14>MAY</bcp14> omit the
      data field of values in the factors list.</t>
      <t indent="0" pn="section-9-4">A KDC <bcp14>MUST NOT</bcp14> include a PA-SPAKE-HINT message directly in a pa-value
      field; hints must only be provided within authentication sets. A KDC
      <bcp14>SHOULD</bcp14> include a hint if SPAKE pre-authentication is offered as the
      second or later element of an authentication set.</t>
      <t indent="0" pn="section-9-5">The PA-SPAKE-HINT message is not part of the transcript, and it does not
      replace any part of the SPAKE message flow.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.1">
        <name slugifiedName="name-spake-computations">SPAKE Computations</name>
        <t indent="0" pn="section-10.1-1">The deserialized public keys S and T <bcp14>MUST</bcp14> be verified to be elements
        of the group to prevent invalid curve attacks. It is not necessary to
        verify that they are members of the prime-order subgroup; the
        computation of K by both parties involves a multiplication by the
        cofactor h.</t>
        <t indent="0" pn="section-10.1-2">The aforementioned cofactor multiplication is accomplished by
        choosing private scalars x and y, which are divisible by the
        cofactor. If the client or KDC chooses a scalar that might not be
        divisible by the cofactor, an attacker might be able to coerce values
        of K that are not members of the prime-order subgroup and deduce a
        limited amount of information about w from the order of K.</t>
        <t indent="0" pn="section-10.1-3">The scalars x and y <bcp14>MUST</bcp14> be chosen uniformly. They <bcp14>MUST NOT</bcp14> be reused
        for different initial reply keys. If an x or y value is reused for
        pre-authentications involving two different initial reply keys, an
        attacker who observes both authentications and knows one of the initial
        reply keys can conduct an offline dictionary attack to recover the
        other one.</t>
        <t indent="0" pn="section-10.1-4">The M and N values for a group <bcp14>MUST NOT</bcp14> have known discrete logs. An
        attacker who knows the discrete log of M or N can perform an offline
        dictionary attack on passwords. Therefore, it is important to
        demonstrate that the M and N values for each group were computed
        without multiplying a known value by the generator P.</t>
      </section>
      <section anchor="unauthtext" numbered="true" removeInRFC="false" toc="include" pn="section-10.2">
        <name slugifiedName="name-unauthenticated-plaintext">Unauthenticated Plaintext</name>
        <t indent="0" pn="section-10.2-1">This mechanism includes unauthenticated plaintext in the support and
        challenge messages. Beginning with the third pass, the integrity of
        this plaintext is ensured by incorporating the transcript hash into
        the derivation of the final reply key and second-factor encryption
        keys. Downgrade attacks on support and challenge messages will result
        in the client and KDC deriving different reply keys and EncryptedData
        keys. The KDC-REQ-BODY contents are also incorporated into key
        derivation, ensuring their integrity. The unauthenticated plaintext in
        the KDC-REP message is not protected by this mechanism.</t>
        <t indent="0" pn="section-10.2-2">Unless FAST is used, the factors field of a challenge message is not
        integrity protected until the response is verified. Second-factor types
        <bcp14>MUST</bcp14> account for this when specifying the semantics of the data
        field. In particular, second-factor data in the challenge should not be
        included in user prompts: it could be modified by an attacker to
        contain misleading or offensive information.</t>
        <t indent="0" pn="section-10.2-3">Unless FAST is used, the factors field of a challenge message is
        visible to an attacker, who can use it to determine whether a second
        factor is required for the client.</t>
        <t indent="0" pn="section-10.2-4">Subsequent factor data, including the data in the response, are
        encrypted in a derivative of the shared secret K. Therefore, it is not
        possible to exploit the untrustworthiness of the challenge to turn the
        client into an encryption or signing oracle for the second-factor
        credentials, unless the attacker knows the client's long-term key.</t>
        <t indent="0" pn="section-10.2-5">Unless FAST is used, any PA-SPAKE-HINT messages are unauthenticated
        and are not protected by the transcript hash if they are included when
        SPAKE is advertised in authentication sets. Since hints do not replace
        any part of the message flow, manipulation of hint messages can only
        affect the client's decision to use or not use an authentication set,
        which could more easily be accomplished by removing authentication
        sets entirely.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.3">
        <name slugifiedName="name-side-channels">Side Channels</name>
        <t indent="0" pn="section-10.3-1">An implementation of the SPAKE pre-authentication mechanism can have
        the property of indistinguishability, meaning that an attacker who
        guesses a long-term key and a second-factor value cannot determine
        whether one of the factors was correct unless both are
        correct. Indistinguishability is only maintained if the second factor
        can be validated solely based on the data in the response; the use of
        additional round trips will reveal to the attacker whether the
        long-term key is correct.  Indistinguishability also requires that
        there are no side channels.

	When the KDC processes a response message, whether or not it decrypts
	the factor field, it must reply with the same error fields, take the
	same amount of time, and make the same observable communications to
	other servers.</t>
        <t indent="0" pn="section-10.3-2">Both the size of the EncryptedData and the number of EncryptedData
        messages used for second-factor data (including the factor field of the
        SPAKEResponse message and messages using the encdata PA-SPAKE choice)
        may reveal information about the second factor used in an
        authentication. Care should be taken to keep second-factor messages as
        small and as few as possible.</t>
        <t indent="0" pn="section-10.3-3">Any side channels in the creation of the shared secret input w, or
        in the multiplications wM and wN, could allow an attacker to recover
        the client long-term key. Implementations <bcp14>MUST</bcp14> take care to avoid side
        channels, particularly timing channels. Generation of the secret scalar
        values x and y need not take constant time, but the amount of time
        taken <bcp14>MUST NOT</bcp14> provide information about the resulting value.</t>
        <t indent="0" pn="section-10.3-4">The conversion of the scalar multiplier for the SPAKE w parameter
        may produce a multiplier that is larger than the order of the group.
        Some group implementations may be unable to handle such a multiplier.
        Others may silently accept such a multiplier but proceed to perform
        multiplication that is not constant time. This is only a minor risk in
        most commonly used groups, but it is a more serious risk for P-521 due to
        the extra seven high bits in the input octet string. A common solution
        to this problem is achieved by reducing the multiplier modulo the group
        order, taking care to ensure constant time operation.</t>
      </section>
      <section anchor="kdcstate" numbered="true" removeInRFC="false" toc="include" pn="section-10.4">
        <name slugifiedName="name-kdc-state">KDC State</name>
        <t indent="0" pn="section-10.4-1">A stateless KDC implementation generally must use a PA-FX-COOKIE
        value to remember its private scalar value x and the transcript hash.
        The KDC <bcp14>MUST</bcp14> maintain confidentiality and integrity of the cookie
        value, perhaps by encrypting it in a key known only to the realm's
        KDCs. Cookie values may be replayed by attackers, perhaps by splicing them
        into different SPAKE exchanges. The KDC <bcp14>SHOULD</bcp14> limit the time window of
        replays using a timestamp, and it <bcp14>SHOULD</bcp14> prevent cookie values from being
        applied to other pre-authentication mechanisms or other client
        principals. Within the validity period of a cookie, an attacker can
        replay the final message of a pre-authentication exchange to any of the
        realm's KDCs and make it appear that the client has authenticated.</t>
        <t indent="0" pn="section-10.4-2">The SPAKE pre-authentication mechanism is not designed to provide
        forward secrecy. Nevertheless, some measure of forward secrecy may
        result depending on implementation choices. A passive attacker who
        determines the client long-term key after the exchange generally will
        not be able to recover the ticket session key; however, an attacker who
        also determines the PA-FX-COOKIE encryption key (if the KDC uses an
        encrypted cookie) will be able to recover the ticket session key. If
        the KDC or client retains the x or y value for reuse with the same
        client long-term key, an attacker who recovers the x or y value and the
        long-term key will be able to recover the ticket session key.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.5">
        <name slugifiedName="name-dictionary-attacks">Dictionary Attacks</name>
        <t indent="0" pn="section-10.5-1">Although the SPAKE pre-authentication mechanism is designed to
        prevent an offline dictionary attack by an active attacker posing as
        the KDC, such an attacker can attempt to downgrade the client to
        the encrypted timestamp pre-authentication mechanism. Client implementations <bcp14>SHOULD</bcp14> provide a
        configuration option to enable or disable the encrypted timestamp mechanism on a
        per-realm basis to mitigate this attack.</t>
        <t indent="0" pn="section-10.5-2">If the user enters the wrong password, the client might fall back
        to the encrypted timestamp mechanism after receiving a
        KDC_ERR_PREAUTH_FAILED error from the KDC, if the encrypted timestamp mechanism
        is offered by the KDC and not disabled by client configuration. This
        fallback will enable a passive attacker to mount an offline dictionary
        attack against the incorrect password, which may be similar to the
        correct password. Client implementations <bcp14>SHOULD</bcp14> assume
        that the encrypted timestamp and encrypted challenge mechanisms are unlikely to
        succeed if SPAKE pre-authentication fails in the second pass and
        SF-NONE was used.</t>
        <t indent="0" pn="section-10.5-3">Like any other pre-authentication mechanism using the client
        long-term key, the SPAKE pre-authentication mechanism does not prevent
        online password guessing attacks. The KDC is made aware of unsuccessful
        guesses and can apply facilities such as rate limiting to mitigate the
        risk of online attacks.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.6">
        <name slugifiedName="name-brute-force-attacks">Brute-Force Attacks</name>
        <t indent="0" pn="section-10.6-1">The selected group's resistance to offline brute-force attacks may
        not correspond to the size of the reply key. For performance reasons, a
        KDC <bcp14>MAY</bcp14> select a group whose brute-force work factor is less than the
        reply key length. A passive attacker who solves the group discrete
        logarithm problem after the exchange will be able to conduct an offline
        attack against the client long-term key. Although the use of password
        policies and costly, salted string-to-key functions may increase the
        cost of such an attack, the resulting cost will likely not be higher
        than the cost of solving the group discrete logarithm.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.7">
        <name slugifiedName="name-denial-of-service-attacks">Denial-of-Service Attacks</name>
        <t indent="0" pn="section-10.7-1">Elliptic curve group operations are more computationally expensive
        than secret-key operations. As a result, the use of this mechanism may
        affect the KDC's performance under normal load and its resistance to
        denial-of-service attacks.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.8">
        <name slugifiedName="name-reflection-attacks">Reflection Attacks</name>
        <t indent="0" pn="section-10.8-1">The encdata choice of PA-SPAKE can be used in either direction;
        the factor-specific plaintext does not necessarily indicate a
        direction. However, each encdata message is encrypted using a derived
        key K'[n], with client-originated messages using only odd values of n
        and KDC-originated messages using only even values. Therefore, an attempted
        reflection attack would result in a failed decryption.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.9">
        <name slugifiedName="name-reply-key-encryption-type">Reply Key Encryption Type</name>
        <t indent="0" pn="section-10.9-1">This mechanism does not upgrade the encryption type of the initial
        reply key and relies on that encryption type for confidentiality,
        integrity, and pseudorandom functions. If the client long-term key
        uses a weak encryption type, an attacker might be able to subvert the
        exchange, and the replaced reply key will also be of the same weak
        encryption type.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-10.10">
        <name slugifiedName="name-kdc-authentication">KDC Authentication</name>
        <t indent="0" pn="section-10.10-1">This mechanism does not directly provide the KDC Authentication
        pre-authentication facility because it does not send a key
        confirmation from the KDC to the client. When used as a stand-alone
        mechanism, the preexisting KDC authentication provided by the KDC-REP
        enc-part still applies.</t>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-11">
      <name slugifiedName="name-assigned-constants">Assigned Constants</name>
      <t indent="0" pn="section-11-1">The following key usage values are assigned for this mechanism:</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-11-2">
        <dt pn="section-11-2.1">KEY_USAGE_SPAKE</dt>
        <dd pn="section-11-2.2">65</dd>
      </dl>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-12">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-12-1">IANA has assigned the following number for PA-SPAKE in the
      "Pre-authentication and Typed Data" registry:</t>
      <table align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Type</th>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">PA-SPAKE</td>
            <td align="left" colspan="1" rowspan="1">151</td>
            <td align="left" colspan="1" rowspan="1">RFC 9588</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-12-3">This document establishes two registries (see Sections <xref target="Second-Factor" format="counter" sectionFormat="of" derivedContent="12.1"/> and <xref target="SPAKE-Groups" format="counter" sectionFormat="of" derivedContent="12.2"/>) with the following
      procedure, in accordance with <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>:</t>
      <t indent="0" pn="section-12-4">Registry entries are to be evaluated using the Specification
      Required method. All specifications must be published prior
      to entry inclusion in the registry. Once published, they can be
      submitted directly to the krb5-spake-review@ietf.org mailing
      list, where there will be a three-week-long review period by
      designated experts.</t>
      <t indent="0" pn="section-12-5">The designated experts ensure that the specification is publicly
      available. They may provide additional in-depth
      reviews, but their approval should not be taken as endorsement of the
      specification.</t>
      <t indent="0" pn="section-12-6">Prior to the end of the review period, the designated experts
      must approve or deny the request. This decision is conveyed to
      both IANA and the submitter. Since the mailing list archives are
      not public, it should include both a reasonably detailed
      explanation in the case of a denial as well as whether the
      request can be resubmitted.</t>
      <t indent="0" pn="section-12-7">IANA must only accept registry updates from the designated experts
      and should direct all requests for registration to the review mailing
      list.</t>
      <section anchor="Second-Factor" numbered="true" removeInRFC="false" toc="include" pn="section-12.1">
        <name slugifiedName="name-kerberos-second-factor-type">Kerberos Second-Factor Types</name>
        <t indent="0" pn="section-12.1-1">This section specifies the "Kerberos Second-Factor Types"
        registry, which records the number, name, and reference for
        each second-factor protocol.</t>
        <section numbered="true" removeInRFC="false" toc="include" pn="section-12.1.1">
          <name slugifiedName="name-registration-template">Registration Template</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-12.1.1-1">
            <dt pn="section-12.1.1-1.1">ID Number:</dt>
            <dd pn="section-12.1.1-1.2">
                A value that uniquely identifies this entry.  It is a
                signed integer in the range -2147483648 to 2147483647, inclusive.
                Positive values must be assigned only for algorithms specified
                in accordance with these rules for use with Kerberos and
                related protocols.  Negative values should be used for private
                and experimental algorithms only.  Zero is reserved and must
                not be assigned.  Values should be assigned in increasing
                order.
              </dd>
            <dt pn="section-12.1.1-1.3">Name:</dt>
            <dd pn="section-12.1.1-1.4">A brief, unique, human-readable name for this algorithm.</dd>
            <dt pn="section-12.1.1-1.5">Reference:</dt>
            <dd pn="section-12.1.1-1.6">
                A URI or otherwise unique identifier for where the details of
                this algorithm can be found.  It should be as specific as
                reasonably possible.
            </dd>
          </dl>
        </section>
        <section numbered="true" removeInRFC="false" toc="include" pn="section-12.1.2">
          <name slugifiedName="name-initial-registry-contents">Initial Registry Contents</name>
          <dl spacing="compact" indent="3" newline="false" pn="section-12.1.2-1">
            <dt pn="section-12.1.2-1.1">ID Number:</dt>
            <dd pn="section-12.1.2-1.2">0</dd>
            <dt pn="section-12.1.2-1.3">Name:</dt>
            <dd pn="section-12.1.2-1.4">Reserved</dd>
            <dt pn="section-12.1.2-1.5">Reference:</dt>
            <dd pn="section-12.1.2-1.6">RFC 9588</dd>
          </dl>
          <dl spacing="compact" indent="3" newline="false" pn="section-12.1.2-2">
            <dt pn="section-12.1.2-2.1">ID Number:</dt>
            <dd pn="section-12.1.2-2.2">1</dd>
            <dt pn="section-12.1.2-2.3">Name:</dt>
            <dd pn="section-12.1.2-2.4">SF-NONE</dd>
            <dt pn="section-12.1.2-2.5">Reference:</dt>
            <dd pn="section-12.1.2-2.6">RFC 9588</dd>
          </dl>
        </section>
      </section>
      <section anchor="SPAKE-Groups" numbered="true" removeInRFC="false" toc="include" pn="section-12.2">
        <name slugifiedName="name-kerberos-spake-groups">Kerberos SPAKE Groups</name>
        <t indent="0" pn="section-12.2-1">This section specifies the "Kerberos SPAKE Groups" registry, which
        records the number, name, specification, serialization,
        multiplier length, multiplier conversion, SPAKE M and N constants, and
        associated hash function for each SPAKE Group.</t>
        <section numbered="true" removeInRFC="false" toc="include" pn="section-12.2.1">
          <name slugifiedName="name-registration-template-2">Registration Template</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-12.2.1-1">
            <dt pn="section-12.2.1-1.1">ID Number:</dt>
            <dd pn="section-12.2.1-1.2">
                A value that uniquely identifies this entry.  It is a
                signed integer in the range -2147483648 to 2147483647, inclusive.
                Positive values must be assigned only for algorithms specified in
                accordance with these rules for use with Kerberos and related
                protocols.  Negative values should be used for private and
                experimental use only.  Zero is reserved and must not be
                assigned.  Values should be assigned in increasing order.
              </dd>
            <dt pn="section-12.2.1-1.3">Name:</dt>
            <dd pn="section-12.2.1-1.4">
                A brief, unique, human-readable name for this entry.
              </dd>
            <dt pn="section-12.2.1-1.5">Specification:</dt>
            <dd pn="section-12.2.1-1.6">
                A reference to the definition of the group parameters and operations.
              </dd>
            <dt pn="section-12.2.1-1.7">Serialization:</dt>
            <dd pn="section-12.2.1-1.8">
                A reference to the definition of the method used to serialize
                and deserialize group elements.
              </dd>
            <dt pn="section-12.2.1-1.9">Multiplier Length:</dt>
            <dd pn="section-12.2.1-1.10">
                The length of the input octet string to multiplication operations.
              </dd>
            <dt pn="section-12.2.1-1.11">Multiplier Conversion:</dt>
            <dd pn="section-12.2.1-1.12">
                A reference to the definition of the method used to convert an
                octet string to a multiplier scalar.
              </dd>
            <dt pn="section-12.2.1-1.13">SPAKE M Constant:</dt>
            <dd pn="section-12.2.1-1.14">
                The serialized value of the SPAKE M constant in hexadecimal notation.
              </dd>
            <dt pn="section-12.2.1-1.15">SPAKE N Constant:</dt>
            <dd pn="section-12.2.1-1.16">
                The serialized value of the SPAKE N constant in hexadecimal notation.
              </dd>
            <dt pn="section-12.2.1-1.17">Hash Function:</dt>
            <dd pn="section-12.2.1-1.18">
                The group's associated hash function.
            </dd>
          </dl>
        </section>
        <section numbered="true" removeInRFC="false" toc="include" pn="section-12.2.2">
          <name slugifiedName="name-initial-registry-contents-2">Initial Registry Contents</name>
          <section numbered="true" removeInRFC="false" toc="exclude" pn="section-12.2.2.1">
            <name slugifiedName="name-edwards-25519">Edwards 25519</name>
            <dl spacing="compact" indent="3" newline="false" pn="section-12.2.2.1-1">
              <dt pn="section-12.2.2.1-1.1">ID Number:</dt>
              <dd pn="section-12.2.2.1-1.2">1</dd>
              <dt pn="section-12.2.2.1-1.3">Name:</dt>
              <dd pn="section-12.2.2.1-1.4">edwards25519</dd>
              <dt pn="section-12.2.2.1-1.5">Specification:</dt>
              <dd pn="section-12.2.2.1-1.6">
                <xref target="RFC7748" section="4.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7748#section-4.1" derivedContent="RFC7748"/> (edwards25519)</dd>
              <dt pn="section-12.2.2.1-1.7">Serialization:</dt>
              <dd pn="section-12.2.2.1-1.8">
                <xref target="RFC8032" section="3.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8032#section-3.1" derivedContent="RFC8032"/></dd>
              <dt pn="section-12.2.2.1-1.9">Multiplier Length:</dt>
              <dd pn="section-12.2.2.1-1.10">32</dd>
              <dt pn="section-12.2.2.1-1.11">Multiplier Conversion:</dt>
              <dd pn="section-12.2.2.1-1.12">
                <xref target="RFC8032" section="3.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8032#section-3.1" derivedContent="RFC8032"/></dd>
              <dt pn="section-12.2.2.1-1.13">SPAKE M Constant:</dt>
              <dd pn="section-12.2.2.1-1.14">d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf</dd>
              <dt pn="section-12.2.2.1-1.15">SPAKE N Constant:</dt>
              <dd pn="section-12.2.2.1-1.16">d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab</dd>
              <dt pn="section-12.2.2.1-1.17">Hash function:</dt>
              <dd pn="section-12.2.2.1-1.18">SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></dd>
            </dl>
          </section>
          <section numbered="true" removeInRFC="false" toc="exclude" pn="section-12.2.2.2">
            <name slugifiedName="name-p-256">P-256</name>
            <dl spacing="compact" indent="3" newline="false" pn="section-12.2.2.2-1">
              <dt pn="section-12.2.2.2-1.1">ID Number:</dt>
              <dd pn="section-12.2.2.2-1.2">2</dd>
              <dt pn="section-12.2.2.2-1.3">Name:</dt>
              <dd pn="section-12.2.2.2-1.4">P-256</dd>
              <dt pn="section-12.2.2.2-1.5">Specification:</dt>
              <dd pn="section-12.2.2.2-1.6">Section 2.4.2 of <xref target="SEC2" format="default" sectionFormat="of" derivedContent="SEC2"/></dd>
              <dt pn="section-12.2.2.2-1.7">Serialization:</dt>
              <dd pn="section-12.2.2.2-1.8">Section 2.3.3 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/> (compressed format)</dd>
              <dt pn="section-12.2.2.2-1.9">Multiplier Length:</dt>
              <dd pn="section-12.2.2.2-1.10">32</dd>
              <dt pn="section-12.2.2.2-1.11">Multiplier Conversion:</dt>
              <dd pn="section-12.2.2.2-1.12">Section 2.3.8 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/></dd>
              <dt pn="section-12.2.2.2-1.13">SPAKE M Constant:</dt>
              <dd pn="section-12.2.2.2-1.14">02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f</dd>
              <dt pn="section-12.2.2.2-1.15">SPAKE N Constant:</dt>
              <dd pn="section-12.2.2.2-1.16">03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49</dd>
              <dt pn="section-12.2.2.2-1.17">Hash function:</dt>
              <dd pn="section-12.2.2.2-1.18">SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></dd>
            </dl>
          </section>
          <section numbered="true" removeInRFC="false" toc="exclude" pn="section-12.2.2.3">
            <name slugifiedName="name-p-384">P-384</name>
            <dl spacing="compact" indent="3" newline="false" pn="section-12.2.2.3-1">
              <dt pn="section-12.2.2.3-1.1">ID Number:</dt>
              <dd pn="section-12.2.2.3-1.2">3</dd>
              <dt pn="section-12.2.2.3-1.3">Name:</dt>
              <dd pn="section-12.2.2.3-1.4">P-384</dd>
              <dt pn="section-12.2.2.3-1.5">Specification:</dt>
              <dd pn="section-12.2.2.3-1.6">Section 2.5.1 of <xref target="SEC2" format="default" sectionFormat="of" derivedContent="SEC2"/></dd>
              <dt pn="section-12.2.2.3-1.7">Serialization:</dt>
              <dd pn="section-12.2.2.3-1.8">Section 2.3.3 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/> (compressed format)</dd>
              <dt pn="section-12.2.2.3-1.9">Multiplier Length:</dt>
              <dd pn="section-12.2.2.3-1.10">48</dd>
              <dt pn="section-12.2.2.3-1.11">Multiplier Conversion:</dt>
              <dd pn="section-12.2.2.3-1.12">Section 2.3.8 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/></dd>
              <dt pn="section-12.2.2.3-1.13">SPAKE M Constant:</dt>
              <dd pn="section-12.2.2.3-1.14">030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc36f15314739074d2eb8613fceec2853</dd>
              <dt pn="section-12.2.2.3-1.15">SPAKE N Constant:</dt>
              <dd pn="section-12.2.2.3-1.16">02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb252c5490214cf9aa3f0baab4b665c10</dd>
              <dt pn="section-12.2.2.3-1.17">Hash function:</dt>
              <dd pn="section-12.2.2.3-1.18">SHA-384 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></dd>
            </dl>
          </section>
          <section numbered="true" removeInRFC="false" toc="exclude" pn="section-12.2.2.4">
            <name slugifiedName="name-p-521">P-521</name>
            <dl spacing="compact" indent="3" newline="false" pn="section-12.2.2.4-1">
              <dt pn="section-12.2.2.4-1.1">ID Number:</dt>
              <dd pn="section-12.2.2.4-1.2">4</dd>
              <dt pn="section-12.2.2.4-1.3">Name:</dt>
              <dd pn="section-12.2.2.4-1.4">P-521</dd>
              <dt pn="section-12.2.2.4-1.5">Specification:</dt>
              <dd pn="section-12.2.2.4-1.6">Section 2.6.1 of <xref target="SEC2" format="default" sectionFormat="of" derivedContent="SEC2"/></dd>
              <dt pn="section-12.2.2.4-1.7">Serialization:</dt>
              <dd pn="section-12.2.2.4-1.8">Section 2.3.3 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/> (compressed format)</dd>
              <dt pn="section-12.2.2.4-1.9">Multiplier Length:</dt>
              <dd pn="section-12.2.2.4-1.10">48</dd>
              <dt pn="section-12.2.2.4-1.11">Multiplier Conversion:</dt>
              <dd pn="section-12.2.2.4-1.12">Section 2.3.8 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/></dd>
              <dt pn="section-12.2.2.4-1.13">SPAKE M Constant:</dt>
              <dd pn="section-12.2.2.4-1.14">02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa</dd>
              <dt pn="section-12.2.2.4-1.15">SPAKE N Constant:</dt>
              <dd pn="section-12.2.2.4-1.16">0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25</dd>
              <dt pn="section-12.2.2.4-1.17">Hash function:</dt>
              <dd pn="section-12.2.2.4-1.18">SHA-512 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></dd>
            </dl>
          </section>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-13">
      <name slugifiedName="name-references">References</name>
      <references pn="section-13.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="ITU-T.X680.2021" quoteTitle="true" derivedAnchor="ITU-T.X680.2021">
          <front>
            <title>Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="February" year="2021"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>
        <reference anchor="ITU-T.X690.2021" quoteTitle="true" derivedAnchor="ITU-T.X690.2021">
          <front>
            <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="February" year="2021"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1:2021"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3961" target="https://www.rfc-editor.org/info/rfc3961" quoteTitle="true" derivedAnchor="RFC3961">
          <front>
            <title>Encryption and Checksum Specifications for Kerberos 5</title>
            <author fullname="K. Raeburn" initials="K." surname="Raeburn"/>
            <date month="February" year="2005"/>
            <abstract>
              <t indent="0">This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3961"/>
          <seriesInfo name="DOI" value="10.17487/RFC3961"/>
        </reference>
        <reference anchor="RFC4120" target="https://www.rfc-editor.org/info/rfc4120" quoteTitle="true" derivedAnchor="RFC4120">
          <front>
            <title>The Kerberos Network Authentication Service (V5)</title>
            <author fullname="C. Neuman" initials="C." surname="Neuman"/>
            <author fullname="T. Yu" initials="T." surname="Yu"/>
            <author fullname="S. Hartman" initials="S." surname="Hartman"/>
            <author fullname="K. Raeburn" initials="K." surname="Raeburn"/>
            <date month="July" year="2005"/>
            <abstract>
              <t indent="0">This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4120"/>
          <seriesInfo name="DOI" value="10.17487/RFC4120"/>
        </reference>
        <reference anchor="RFC6113" target="https://www.rfc-editor.org/info/rfc6113" quoteTitle="true" derivedAnchor="RFC6113">
          <front>
            <title>A Generalized Framework for Kerberos Pre-Authentication</title>
            <author fullname="S. Hartman" initials="S." surname="Hartman"/>
            <author fullname="L. Zhu" initials="L." surname="Zhu"/>
            <date month="April" year="2011"/>
            <abstract>
              <t indent="0">Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal.</t>
              <t indent="0">This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.</t>
              <t indent="0">This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6113"/>
          <seriesInfo name="DOI" value="10.17487/RFC6113"/>
        </reference>
        <reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6234" quoteTitle="true" derivedAnchor="RFC6234">
          <front>
            <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="May" year="2011"/>
            <abstract>
              <t indent="0">Federal Information Processing Standard, FIPS</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6234"/>
          <seriesInfo name="DOI" value="10.17487/RFC6234"/>
        </reference>
        <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748" quoteTitle="true" derivedAnchor="RFC7748">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2016"/>
            <abstract>
              <t indent="0">This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7748"/>
          <seriesInfo name="DOI" value="10.17487/RFC7748"/>
        </reference>
        <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032" quoteTitle="true" derivedAnchor="RFC8032">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8032"/>
          <seriesInfo name="DOI" value="10.17487/RFC8032"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="SEC1" quoteTitle="true" derivedAnchor="SEC1">
          <front>
            <title>SEC 1: Elliptic Curve Cryptography</title>
            <author>
              <organization showOnFrontPage="true">Standards for Efficient Cryptography Group</organization>
            </author>
            <date month="May" year="2009"/>
          </front>
        </reference>
        <reference anchor="SEC2" quoteTitle="true" derivedAnchor="SEC2">
          <front>
            <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
            <author>
              <organization showOnFrontPage="true">Standards for Efficient Cryptography Group</organization>
            </author>
            <date month="January" year="2010"/>
          </front>
        </reference>
      </references>
      <references pn="section-13.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC6090" target="https://www.rfc-editor.org/info/rfc6090" quoteTitle="true" derivedAnchor="RFC6090">
          <front>
            <title>Fundamental Elliptic Curve Cryptography Algorithms</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="K. Igoe" initials="K." surname="Igoe"/>
            <author fullname="M. Salter" initials="M." surname="Salter"/>
            <date month="February" year="2011"/>
            <abstract>
              <t indent="0">This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6090"/>
          <seriesInfo name="DOI" value="10.17487/RFC6090"/>
        </reference>
        <reference anchor="RFC6560" target="https://www.rfc-editor.org/info/rfc6560" quoteTitle="true" derivedAnchor="RFC6560">
          <front>
            <title>One-Time Password (OTP) Pre-Authentication</title>
            <author fullname="G. Richards" initials="G." surname="Richards"/>
            <date month="April" year="2012"/>
            <abstract>
              <t indent="0">The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password (OTP) authentication. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6560"/>
          <seriesInfo name="DOI" value="10.17487/RFC6560"/>
        </reference>
        <reference anchor="RFC8125" target="https://www.rfc-editor.org/info/rfc8125" quoteTitle="true" derivedAnchor="RFC8125">
          <front>
            <title>Requirements for Password-Authenticated Key Agreement (PAKE) Schemes</title>
            <author fullname="J. Schmidt" initials="J." surname="Schmidt"/>
            <date month="April" year="2017"/>
            <abstract>
              <t indent="0">Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8125"/>
          <seriesInfo name="DOI" value="10.17487/RFC8125"/>
        </reference>
        <reference anchor="SPAKE" quoteTitle="true" target="https://doi.org/10.1007/978-3-540-30574-3_14" derivedAnchor="SPAKE">
          <front>
            <title>Simple Password-Based Encrypted Key Exchange Protocols</title>
            <author surname="Abdalla" initials="M."/>
            <author surname="Pointcheval" initials="D."/>
            <date month="February" year="2005"/>
          </front>
          <refcontent>CT-RSA 2005, Lecture Notes in Computer
        Science, Volume 3376, pages 191-208, Springer</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-540-30574-3_14"/>
        </reference>
      </references>
    </references>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-asn1-module">ASN.1 Module</name>
      <sourcecode type="asn.1" markers="false" pn="section-appendix.a-1">
KerberosV5SPAKE {
        iso(1) identified-organization(3) dod(6) internet(1)
        security(5) kerberosV5(2) modules(4) spake(8)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN

IMPORTS
    EncryptedData, Int32
      FROM KerberosV5Spec2 { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) kerberosV5(2) modules(4)
        krb5spec2(2) };
        -- as defined in RFC 4120.

SPAKESupport ::= SEQUENCE {
    groups      [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
    ...
}

SPAKEChallenge ::= SEQUENCE {
    group       [0] Int32,
    pubkey      [1] OCTET STRING,
    factors     [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor,
    ...
}

SPAKESecondFactor ::= SEQUENCE {
    type        [0] Int32,
    data        [1] OCTET STRING OPTIONAL
}

SPAKEResponse ::= SEQUENCE {
    pubkey      [0] OCTET STRING,
    factor      [1] EncryptedData, -- SPAKESecondFactor
    ...
}

PA-SPAKE ::= CHOICE {
    support     [0] SPAKESupport,
    challenge   [1] SPAKEChallenge,
    response    [2] SPAKEResponse,
    encdata     [3] EncryptedData,
    ...
}

PA-SPAKE-HINT ::= SEQUENCE {
    groups      [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
    factors     [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor
}

END
</sourcecode>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-spake-m-and-n-value-selecti">SPAKE M and N Value Selection</name>
      <t indent="0" pn="section-appendix.b-1">The M and N values for the initial contents of the SPAKE group
      registry were generated using the following Python snippet, which assumes
      an elliptic curve implementation following the interface of
      Edwards25519Point.stdbase() and Edwards448Point.stdbase() in <xref target="RFC8032" sectionFormat="of" section="A" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8032#appendix-A" derivedContent="RFC8032"/>:</t>
      <sourcecode type="python" markers="false" pn="section-appendix.b-2">
def iterhash(seed, n):
    h = seed
    for i in range(n):
        h = hashlib.sha256(h).digest()
    return h

def bighash(seed, start, sz):
    n = -(-sz // 32)
    hashes = [iterhash(seed, i) for i in range(start, start + n)]
    return b''.join(hashes)[:sz]

def canon_pointstr(ecname, s):
    if ecname == 'edwards25519':
        return s
    elif ecname == 'edwards448':
        return s[:-1] + bytes([s[-1] &amp; 0x80])
    else:
        return bytes([(s[0] &amp; 1) | 2]) + s[1:]

def gen_point(seed, ecname, ec):
    for i in range(1, 1000):
        hval = bighash(seed, i, len(ec.encode()))
        pointstr = canon_pointstr(ecname, hval)
        try:
            p = ec.decode(pointstr)
            if p != ec.zero_elem() and p * p.l() == ec.zero_elem():
                return pointstr, i
        except Exception:
            pass
</sourcecode>
      <t indent="0" pn="section-appendix.b-3">The initial seed strings are as follows:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.b-4">
        <li pn="section-appendix.b-4.1">For group 1 M: edwards25519 point generation seed (M)</li>
        <li pn="section-appendix.b-4.2">For group 1 N: edwards25519 point generation seed (N)</li>
        <li pn="section-appendix.b-4.3">For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M)</li>
        <li pn="section-appendix.b-4.4">For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N)</li>
        <li pn="section-appendix.b-4.5">For group 3 M: 1.3.132.0.34 point generation seed (M)</li>
        <li pn="section-appendix.b-4.6">For group 3 N: 1.3.132.0.34 point generation seed (N)</li>
        <li pn="section-appendix.b-4.7">For group 4 M: 1.3.132.0.35 point generation seed (M)</li>
        <li pn="section-appendix.b-4.8">For group 4 N: 1.3.132.0.35 point generation seed (N)</li>
      </ul>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-test-vectors">Test Vectors</name>
      <t indent="0" pn="section-appendix.c-1">For the following text vectors:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.c-2">
        <li pn="section-appendix.c-2.1">The key is the string-to-key of "password" with the salt
        "ATHENA.MIT.EDUraeburn" for the designated initial reply key
        encryption type.</li>
        <li pn="section-appendix.c-2.2">x and y were chosen randomly within the order of the
        designated group, then multiplied by the cofactor.</li>
        <li pn="section-appendix.c-2.3">The SPAKESupport message contains only the designated
        group's number.</li>
        <li pn="section-appendix.c-2.4">The SPAKEChallenge message offers only the SF-NONE second-factor type.</li>
        <li pn="section-appendix.c-2.5">The KDC-REQ-BODY message does not contain KDC options, but
        does contain the client principal name "raeburn@ATHENA.MIT.EDU", the
        server principal name "krbtgt/ATHENA.MIT.EDU", the realm
        "ATHENA.MIT.EDU", the till field "19700101000000Z", the nonce zero,
        and an etype list containing only the designated encryption type.</li>
      </ul>
      <sourcecode type="test-vector" markers="false" pn="section-appendix.c-3">
des3-cbc-sha1 edwards25519
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
w (PRF+ output): 686d84730cb8679ae95416c6567c6a63
                 f2c9cef124f7a3371ae81e11cad42a37
w (reduced multiplier): a1f1a25cbd8e3092667e2fddba8ecd24
                        f2c9cef124f7a3371ae81e11cad42a07
x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723
y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25
X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e
Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028
T: 18f511e750c97b592acd30db7d9e5fca660389102e6bf610c1bfbed4616c8362
S: 5d10705e0d1e43d5dbf30240ccfbde4a0230c70d4c79147ab0b317edad2f8ae7
K: 25bde0d875f0feb5755f45ba5e857889d916ecf7476f116aa31dc3e037ec4292
SPAKESupport: a0093007a0053003020101
SPAKEChallenge: a1363034a003020101a122042018f511e750c97b592acd30
                db7d9e5fca660389102e6bf610c1bfbed4616c8362a20930
                073005a003020101
Transcript hash after challenge: 22bb2271e34d329d52073c70b1d11879
                                 73181f0bc7614266bb79ee80d3335175
Final transcript hash after pubkey: eaaa08807d0616026ff51c849efbf35b
                                    a0ce3c5300e7d486da46351b13d4605b
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020110
K'[0]: baf12fae7cd958cbf1a29bfbc71f89ce49e03e295d89dafd
K'[1]: 64f73dd9c41908206bcec1f719026b574f9d13463d7a2520
K'[2]: 0454520b086b152c455829e6baeff78a61dfe9e3d04a895d
K'[3]: 4a92260b25e3ef94c125d5c24c3e5bced5b37976e67f25c4

rc4-hmac edwards25519
key: 8846f7eaee8fb117ad06bdd830b7586c
w (PRF+ output): 7c86659d29cf2b2ea93bfe79c3cefb88
                 50e82215b3ea6fcd896561d48048f49c
w (reduced multiplier): 2713c1583c53861520b849bfef0525cd
                        4fe82215b3ea6fcd896561d48048f40c
x: c8a62e7b626f44cad807b2d695450697e020d230a738c5cd5691cc781dce8754
y: 18fe7c1512708c7fd06db270361f04593775bc634ceaf45347e5c11c38aae017
X: b0bcbbdd25aa031f4608d0442dd4924be7731d49c089a8301859d77343ffb567
Y: 7d1ab8aeda1a2b1f9eab8d11c0fda60b616005d0f37d1224c5f12b8649f579a5
T: 7db465f1c08c64983a19f560bce966fe5306c4b447f70a5bca14612a92da1d63
S: 38f8d4568090148ebc9fd17c241b4cc2769505a7ca6f3f7104417b72b5b5cf54
K: 03e75edd2cd7e7677642dd68736e91700953ac55dc650e3c2a1b3b4acdb800f8
SPAKESupport: a0093007a0053003020101
SPAKEChallenge: a1363034a003020101a12204207db465f1c08c64983a19f5
                60bce966fe5306c4b447f70a5bca14612a92da1d63a20930
                073005a003020101
Transcript hash after challenge: 3cde9ed9b562a09d816885b6c225f733
                                 6d9e2674bb4df903dfc894d963a2af42
Final transcript hash after pubkey: f4b208458017de6ef7f6a307d47d87db
                                    6c2af1d291b726860f68bc08bfef440a
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020117
K'[0]: 770b720c82384cbb693e85411eedecba
K'[1]: 621deec88e2865837c4d3462bb50a1d5
K'[2]: 1cc8f6333b9fa3b42662fd9914fbd5bb
K'[3]: edb4032b7fc3806d5211a534dcbc390c

aes128-cts-hmac-sha1-96 edwards25519
key: fca822951813fb252154c883f5ee1cf4
w (PRF+ output): 0d591b197b667e083c2f5f98ac891d3c
                 9f99e710e464e62f1fb7c9b67936f3eb
w (reduced multiplier): 17c2a9030afb7c37839bd4ae7fdfeb17
                        9e99e710e464e62f1fb7c9b67936f30b
x: 50be049a5a570fa1459fb9f666e6fd80602e4e87790a0e567f12438a2c96c138
y: b877afe8612b406d96be85bd9f19d423e95be96c0e1e0b5824127195c3ed5917
X: e73a443c678913eb4a0cad5cbd3086cf82f65a5a91b611e01e949f5c52efd6dd
Y: 473c5b44ed2be9cb50afe1762b535b3930530489816ea6bd962622cccf39f6e8
T: 9e9311d985c1355e022d7c3c694ad8d6f7ad6d647b68a90b0fe46992818002da
S: fbe08f7f96cd5d4139e7c9eccb95e79b8ace41e270a60198c007df18525b628e
K: c2f7f99997c585e6b686ceb62db42f17cc70932def3bb4cf009e36f22ea5473d
SPAKESupport: a0093007a0053003020101
SPAKEChallenge: a1363034a003020101a12204209e9311d985c1355e022d7c
                3c694ad8d6f7ad6d647b68a90b0fe46992818002daa20930
                073005a003020101
Transcript hash after challenge: 4512310282c01b39dd9aebd0cc2a5e53
                                 2ed077a6c11d4c973c4593d525078797
Final transcript hash after pubkey: 951285f107c87f0169b9c918a1f51f60
                                    cb1a75b9f8bb799a99f53d03add94b5f
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020111
K'[0]: 548022d58a7c47eae8c49dccf6baa407
K'[1]: b2c9ba0e13fc8ab3a9d96b51b601cf4a
K'[2]: 69f0ee5fdb6c237e7fcd38d9f87df1bd
K'[3]: 78f91e2240b5ee528a5cc8d7cbebfba5

aes256-cts-hmac-sha1-96 edwards25519
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3
                 f2108f1b6aa97b381012b9400c9e3f4e
w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060
                        f2108f1b6aa97b381012b9400c9e3f0e
x: 88c6c0a4f0241ef217c9788f02c32d00b72e4310748cd8fb5f94717607e6417d
y: 88b859df58ef5c69bacdfe681c582754eaab09a74dc29cff50b328613c232f55
X: 23c48eaff2721051946313840723b38f563c59b92043d6ffd752f95781af0327
Y: 3d51486ec1d9be69bc45386bb675c013db87fd0488f6a9cacf6b43e8c81a0641
T: 6f301aacae1220e91be42868c163c5009aeea1e9d9e28afcfc339cda5e7105b5
S: 9e2cc32908fc46273279ec75354b4aeafa70c3d99a4d507175ed70d80b255dda
K: cf57f58f6e60169d2ecc8f20bb923a8e4c16e5bc95b9e64b5dc870da7026321b
SPAKESupport: a0093007a0053003020101
SPAKEChallenge: a1363034a003020101a12204206f301aacae1220e91be428
                68c163c5009aeea1e9d9e28afcfc339cda5e7105b5a20930
                073005a003020101
Transcript hash after challenge: 23a5e72eb4dedd1ca860f43736c458f0
                                 775c3bb1370a26af8a9374d521d70ec9
Final transcript hash after pubkey: 1c605649d4658b58cbe79a5faf227acc
                                    16c355c58b7dade022f90c158fe5ed8e
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020112
K'[0]: a9bfa71c95c575756f922871524b6528
       8b3f695573ccc0633e87449568210c23
K'[1]: 1865a9ee1ef0640ec28ac007391cac62
       4c42639c714767a974e99aa10003015f
K'[2]: e57781513fefdb978e374e156b0da0c1
       a08148f5eb26b8e157ac3c077e28bf49
K'[3]: 008e6487293c3cc9fabbbcdd8b392d6d
       cb88222317fd7fe52d12fbc44fa047f1

aes256-cts-hmac-sha1-96 P-256
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): eb2984af18703f94dd5288b8596cd369
                 88d0d4e83bfb2b44de14d0e95e2090bd
w (reduced multiplier): eb2984af18703f94dd5288b8596cd369
                        88d0d4e83bfb2b44de14d0e95e2090bd
x: 935ddd725129fb7c6288e1a5cc45782198a6416d1775336d71eacd0549a3e80e
y: e07405eb215663abc1f254b8adc0da7a16febaa011af923d79fdef7c42930b33
X: 03bc802165aea7dbd98cc155056249fe0a37a9c203a7c0f7e872d5bf687bd105e2
Y: 0340b8d91ce3852d0a12ae1f3e82c791fc86df6b346006431e968a1b869af7c735
T: 024f62078ceb53840d02612195494d0d0d88de21feeb81187c71cbf3d01e71788d
S: 021d07dc31266fc7cfd904ce2632111a169b7ec730e5f74a7e79700f86638e13c8
K: 0268489d7a9983f2fde69c6e6a1307e9d252259264f5f2dfc32f58cca19671e79b
SPAKESupport: a0093007a0053003020102
SPAKEChallenge: a1373035a003020102a1230421024f62078ceb53840d0261
                2195494d0d0d88de21feeb81187c71cbf3d01e71788da209
                30073005a003020101
Transcript hash after challenge: 0a142afca77c2e92b066572a90389eac
                                 40a6b1f1ed8b534d342591c0e7727e00
Final transcript hash after pubkey: 20ad3c1a9a90fc037d1963a1c4bfb15a
                                    b4484d7b6cf07b12d24984f14652de60
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020112
K'[0]: 7d3b906f7be49932db22cd3463f032d0
       6c9c078be4b1d076d201fc6e61ef531e
K'[1]: 17d74e36f8993841fbb7feb12fa4f011
       243d3ae4d2ace55b39379294bbc4db2c
K'[2]: d192c9044081a2aa6a97a6c69e2724e8
       e5671c2c9ce073dd439cdbaf96d7dab0
K'[3]: 41e5bad6b67f12c53ce0e2720dd6a988
       7f877bf9463c2d5209c74c36f8d776b7

aes256-cts-hmac-sha1-96 P-384
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): 0304cfc55151c6bbe889653db96dbfe0ba4acafc024c1e88
                 40cb3a486f6d80c16e1b8974016aa4b7fa43042a9b3825b1
w (reduced multiplier): 0304cfc55151c6bbe889653db96dbfe0
                        ba4acafc024c1e8840cb3a486f6d80c1
                        6e1b8974016aa4b7fa43042a9b3825b1
x: f323ca74d344749096fd35d0adf20806e521460637176e84d977e9933c49d76f
   cfc6e62585940927468ff53d864a7a50
y: 5b7c709acb175a5afb82860deabca8d0b341facdff0ac0f1a425799aa905d750
   7e1ea9c573581a81467437419466e472
X: 0211e3334f117b76635dd802d4022f601680a1fd066a56606b7f246493a10351
   7797b81789b225bd5bb1d9ae1da2962250
Y: 0383dfa413496e5e7599fc8c6430f8d6910d37cf326d81421bc92c0939b555c4
   ca2ef6a993f6d3db8cb7407655ef60866e
T: 02a1524603ef14f184696f854229d3397507a66c63f841ba748451056be07879
   ac298912387b1c5cdff6381c264701be57
S: 020d5adfdb92bc377041cf5837412574c5d13e0f4739208a4f0c859a0a302bc6
   a533440a245b9d97a0d34af5016a20053d
K: 0264aa8c61da9600dfb0beb5e46550d63740e4ef29e73f1a30d543eb43c25499
   037ad16538586552761b093cf0e37c703a
SPAKESupport: a0093007a0053003020103
SPAKEChallenge: a1473045a003020103a133043102a1524603ef14f184696f
                854229d3397507a66c63f841ba748451056be07879ac2989
                12387b1c5cdff6381c264701be57a20930073005a0030201
                01
Transcript hash after challenge: 4d4095d9f94552e15015881a3f2cf458
                                 1be83217cf7ad830d2f051dba3ec8caa
                                 6e354eaa85738d7035317ac557f8c294
Final transcript hash after pubkey: 5ac0d99ef9e5a73998797fe64f074673
                                    e3952dec4c7d1aacce8b75f64d2b0276
                                    a901cb8539b4e8ed69e4db0ce805b47b
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020112
K'[0]: b917d37c16dd1d8567fbe379f64e1ee3
       6ca3fd127aa4e60f97e4afa3d9e56d91
K'[1]: 93d40079dab229b9c79366829f4e7e72
       82e6a4b943ac7bac69922d516673f49a
K'[2]: bfc4f16f12f683e71589f9a888e23287
       5ef293ac9793db6c919567cd7b94bcd4
K'[3]: 3630e2b5b99938e7506733141e8ec344
       166f6407e5fc2ef107c156e764d1bc20

aes256-cts-hmac-sha1-96 P-521
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8
                 2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45
                 e85d1a5435d1c8c83662999722d542831f9a
w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1
                        caf95bc8425665d82370aff58b0471f3
                        4cce63791cfed967f0c94c16054b3e17
                        03133681bece1e05219f5426bc944b0f
                        bfb3
x: 017c38701a14b490b6081dfc83524562be7fbb42e0b20426465e3e37952d30bc
   ab0ed857010255d44936a1515607964a870c7c879b741d878f9f9cdf5a865306
   f3f5
y: 003e2e2950656fa231e959acdd984d125e7fa59cec98126cbc8f3888447911eb
   cd49428a1c22d5fdb76a19fbeb1d9edfa3da6cf55b158b53031d05d51433ade9
   b2b4
X: 03003e95272223b210b48cfd908b956a36add04a7ff443511432f94ddd87e064
   1d680ba3b3d532c21fa6046192f6bfae7af81c4b803aa154e12459d1428f8f2f
   56e9f2
Y: 030064916687960df496557ecab08298bf075429eca268c6dabbae24e258d568
   c62841664dc8ecf545369f573ea84548faa22f118128c0a87e1d47315afabb77
   3bb082
T: 02017d3de19a3ec53d0174905665ef37947d142535102cd9809c0dfbd0dfe007
   353d54cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc275adbd9675
   6696ec
S: 02004d142d87477841f6ba053c8f651f3395ad264b7405ca5911fb9a55abd454
   fef658a5f9ed97d1efac68764e9092fa15b9e0050880d78e95fd03abf5931791
   6822b5
K: 03007c303f62f09282cc849490805bd4457a6793a832cbeb55df427db6a31e99
   b055d5dc99756d24d47b70ad8b6015b0fb8742a718462ed423b90fa3fe631ac1
   3fa916
SPAKESupport: a0093007a0053003020104
SPAKEChallenge: a1593057a003020104a145044302017d3de19a3ec53d0174
                905665ef37947d142535102cd9809c0dfbd0dfe007353d54
                cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc2
                75adbd96756696eca20930073005a003020101
Transcript hash after challenge: 554405860f8a80944228f1fa2466411d
                                 cf236162aa385e1289131b39e1fd59f2
                                 5e58b4c281ff059c28dc20f5803b87c6
                                 7571ce64cea01b39a21819d1ef1cdc7f
Final transcript hash after pubkey: 8d6a89ae4d80cc4e47b6f4e48ea3e579
                                    19cc69598d0d3dc7c8bd49b6f1db1409
                                    ca0312944cd964e213aba98537041102
                                    237cff5b331e5347a0673869b412302e
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020112
K'[0]: 1eb3d10bee8fab483adcd3eb38f3ebf1
       f4feb8db96ecc035f563cf2e1115d276
K'[1]: 482b92781ce57f49176e4c94153cc622
       fe247a7dbe931d1478315f856f085890
K'[2]: a2c215126dd3df280aab5a27e1e0fb7e
       594192cbff8d6d8e1b6f1818d9bb8fac
K'[3]: cc06603de984324013a01f888de6d43b
       410a4da2dea53509f30e433c352fb668

aes256-cts-hmac-sha1-96 edwards25519, accepted optimistic challenge
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3
                 f2108f1b6aa97b381012b9400c9e3f4e
w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060
                        f2108f1b6aa97b381012b9400c9e3f0e
x: 70937207344cafbc53c8a55070e399c584cbafce00b836980dd4e7e74fad2a64
y: 785d6801a2490df028903ac6449b105f2ff0db895b252953cdc2076649526103
X: 13841224ea50438c1d9457159d05f2b7cd9d05daf154888eeed223e79008b47c
Y: d01fc81d5ce20d6ea0939a6bb3e40ccd049f821baaf95e323a3657309ef75d61
T: 83523b35f1565006cbfc4f159885467c2fb9bc6fe23d36cb1da43d199f1a3118
S: 2a8f70f46cee9030700037b77f22cec7970dcc238e3e066d9d726baf183992c6
K: d3c5e4266aa6d1b2873a97ce8af91c7e4d7a7ac456acced7908d34c561ad8fa6
SPAKEChallenge: a1363034a003020101a122042083523b35f1565006cbfc4f
                159885467c2fb9bc6fe23d36cb1da43d199f1a3118a20930
                073005a003020101
Transcript hash after challenge: 0332da8ba3095ccd127c51740cb905ba
                                 c76e90725e769570b9d8338e6d62a7f2
Final transcript hash after pubkey: 26f07f9f8965307434d11ea855461d41
                                    e0cbabcc0a1bab48ecee0c6c1a4292b7
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020112
K'[0]: 4569ec08b5de5c3cc19d941725913ace
       8d74524b521a341dc746acd5c3784d92
K'[1]: 0d96ce1a4ac0f2e280a0cfc31742b064
       61d83d04ae45433db2d80478dd882a4c
K'[2]: 58018c19315a1ba5d5bb9813b58029f0
       aec18a6f9ca59e0847de1c60bc25945c
K'[3]: ed7e9bffd68c54d86fb19cd3c03f317f
       88a71ad9a5e94c28581d93fc4ec72b6a

aes256-cts-hmac-sha1-96 P-521, rejected edwards25519 challenge
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8
                 2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45
                 e85d1a5435d1c8c83662999722d542831f9a
w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1
                        caf95bc8425665d82370aff58b0471f3
                        4cce63791cfed967f0c94c16054b3e17
                        03133681bece1e05219f5426bc944b0f
                        bfb3
x: 01687b59051bf40048d7c31d5a973d792fa12284b7a447e7f5938b5885ca0bb2
   c3f0bd30291a55fea08e143e2e04bdd7d19b753c7c99032f06cab0d9c2aa8f83
   7ef7
y: 01ded675ebf74fe30c9a53710f577e9cf84f09f6048fe245a4600004884cc167
   733f9a9e43108fb83babe8754cd37cbd7025e28bc9ff870f084c7244f536285e
   25b4
X: 03001bed88af987101ef52db5b8876f6287eb49a72163876c2cf99deb94f4c74
   9bfd118f0f400833cc8daad81971fe40498e6075d8ba0a2acfac35eb9ec8530e
   e0edd5
Y: 02007bd3bf214200795ea449852976f241c9f50f445f78ff2714fffe42983f25
   cd9c9094ba3f9d7adadd6c251e9dc0991fc8210547e7769336a0ac406878fb94
   be2f1f
T: 02014cb2e5b592ece5990f0ef30d308c061de1598bc4272b4a6599bed466fd15
   21693642abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03fb96ef5f1e
   d3e645
S: 02016c64995e804416f748fd5fa3aa678cbc7cbb596a4f523132dc8af7ce84e5
   41f484a2c74808c6b21dcf7775baefa6753398425becc7b838b210ac5daa0cb0
   b710e2
K: 0200997f4848ae2e7a98c23d14ac662030743ab37fccc2a45f1c721114f40bcc
   80fe6ec6aba49868f8aea1aa994d50e81b86d3e4d3c1130c8695b68907c673d9
   e5886a
Optimistic SPAKEChallenge: a1363034a003020102a122042047ca8c
                           24c3a4a70b6eca228322529dadcfa85c
                           f58faceecf5d5c02907b9e2deba20930
                           073005a003020101
SPAKESupport: a0093007a0053003020104
SPAKEChallenge: a1593057a003020104a145044302014cb2e5b592ece5990f
                0ef30d308c061de1598bc4272b4a6599bed466fd15216936
                42abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03
                fb96ef5f1ed3e645a20930073005a003020101
Transcript hash after challenge: cb925b8baeae5e2867ab5b10ae1c941c
                                 4ff4b58a4812c1f7bd1c862ad480a8e1
                                 c6fcd5e88d846a2045e385841c91a75a
                                 d2035f0ff692717608e2a5a90842eff2
Final transcript hash after pubkey: d0efed5e3e2c39c26034756d92a66fec
                                    3082ad793d0197f3f89ad36026f146a3
                                    996e548aa3fc49e2e82f8cac5d132c50
                                    5aa475b39e7be79cded22c26c41aa777
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020112
K'[0]: 631fcc8596e7f40e59045950d72aa0b7
       bac2810a07b767050e983841cf3a2d4c
K'[1]: 881464920117074dbc67155a8f3341d1
       121ef65f78ea0380bfa81a134c1c47b1
K'[2]: 377b72ac3af2caad582d73ae4682fd56
       b531ee56706200dd6c38c42b8219837a
K'[3]: 35ad8e4d580ed3f0d15ad928329773c0
       81bd19f9a56363f3a5f77c7e66108c26
</sourcecode>
      <t indent="0" pn="section-appendix.c-4">There are currently no encryption types with a seed size large enough
      to require multiple hash blocks during key derivation with any of the
      assigned hash functions. To exercise this possibility, the following
      test vector illustrates what keys would be derived if there were a copy
      of the edwards25519 group with group number -1 and associated hash
      function SHA-1:</t>
      <sourcecode type="test-vector" markers="false" pn="section-appendix.c-5">
AES256 edwards25519 SHA-1 group number -1
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): 26da6b118cee6fa5ea795ed32d61490d
                 82b2f11102312f3f2fc04fb01c93df91
w (reduced multiplier): d166c7cc9e72ca8c61f6a9185a987251
                        81b2f11102312f3f2fc04fb01c93df01
x: 606c1b668008ed78fe2eee942e8f08007f3f1dcbef66d37fd69033525bda2030
y: 10fc4e0bb1a902e58f632a1ea0bceb366360ac985f46996d956a02572bfcf050
X: 389621509665abad35eaab26eab3a0f593c7b4380562aa5513c1140fd78ce048
Y: de3ed05986eeac518958b566f9bad065b321402025cd188f3d198dc55c6d6b8d
T: 2289a4f3c613e6e1df95e94aaa3c127dc062b9fceec3f9b62378dc729d61d0e3
S: f9a7fa352930dedb422d567700bfcd39ba221e7f9ac3e6b36f2b63b68b88642c
K: 6f61d6b18323b6c3ddaac7c56712845335384f095d3e116f69feb926a04f1340
SPAKESupport: a0093007a00530030201ff
SPAKEChallenge: a1363034a0030201ffa12204202289a4f3c613e6e1df95e9
                4aaa3c127dc062b9fceec3f9b62378dc729d61d0e3a20930
                073005a003020101
Transcript hash after challenge: f5c051eb75290f92142c
                                 bbe80557ec2c85902c94
Final transcript hash after pubkey: 9e26a3b148400c8f9cb8
                                    545331e4e7dcab399cc0
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
              1b077261656275726ea2101b0e415448454e412e4d49542e
              454455a3233021a003020102a11a30181b066b7262746774
              1b0e415448454e412e4d49542e454455a511180f31393730
              303130313030303030305aa703020100a8053003020112
K'[0]: 40bceb51bba474fd29ae65950022b704
       17b80d973fa8d8d6cd39833ff89964ad
K'[1]: c29a7315453dc1cce938fa12a9e5c0db
       2894b2194da14c9cd4f7bc3a6a37223d
K'[2]: f261984dba3c230fad99d324f871514e
       5aad670e44f00daef3264870b0851c25
K'[3]: d24b2b46bab7c4d1790017d9116a7eeb
       ca88b0562a5ad8989c826cb7dab715c7
</sourcecode>
    </section>
    <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.d-1"><contact fullname="Nico Williams"/> (Cryptonector)</t>
      <t indent="0" pn="section-appendix.d-2"><contact fullname="Taylor Yu"/> (MIT)</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Nathaniel McCallum" initials="N." surname="McCallum">
        <organization showOnFrontPage="true">Red Hat, Inc.</organization>
        <address>
          <email>nathaniel@mccallum.life</email>
        </address>
      </author>
      <author fullname="Simo Sorce" initials="S." surname="Sorce">
        <organization showOnFrontPage="true">Red Hat, Inc.</organization>
        <address>
          <email>ssorce@redhat.com</email>
        </address>
      </author>
      <author fullname="Robbie Harwood" initials="R." surname="Harwood">
        <organization showOnFrontPage="true">Red Hat, Inc.</organization>
        <address>
          <email>rharwood@pm.me</email>
        </address>
      </author>
      <author fullname="Greg Hudson" initials="G." surname="Hudson">
        <organization showOnFrontPage="true">MIT</organization>
        <address>
          <email>ghudson@mit.edu</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
