<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.2.3) -->
<?rfc tocompact="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bonica-tcpm-tcp-ao-algs-00" category="std" consensus="true" submissionType="IETF" updates="RFC 5926" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.32.0 -->
  <front>
    <title abbrev="tcp-ao-algs">Additional Security Algorithms For Use With TCP-AO</title>
    <seriesInfo name="Internet-Draft" value="draft-bonica-tcpm-tcp-ao-algs-00"/>
    <author initials="R." surname="Bonica" fullname="Ron Bonica">
      <organization>HPE</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>ronald.bonica@hpe.com</email>
      </address>
    </author>
    <author initials="T." surname="Li" fullname="Tony Li">
      <organization>HPE</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>tony.li@tony.li</email>
      </address>
    </author>
    <date year="2026" month="March" day="23"/>
    <area>Transport</area>
    <workgroup>TCPM Working Group</workgroup>
    <keyword>TCP-AO</keyword>
    <abstract>
      <?line 49?>

<t>RFC5926 specifies cryptographic algorithms for TCP-AO.
It explains how to use KDF_HMAC_SHA1 and KDF_AES_128_CMAC 
as KDFs. It also explains how to use HMAC-SHA-1-96 and 
AES-128-CMAC-96 as MAC algorithms.</t>
      <t>This document specifies several new KDFs and MAC
algorithms for TCP-AO. The KDFs and MAC algorithms specified in 
this document use stronger cryptography.</t>
    </abstract>
  </front>
  <middle>
    <?line 60?>

<section anchor="intro">
      <name>Introduction</name>
      <t>TCP end-points use the TCP Authentication Option (TCP-AO) <xref target="RFC5925"/> to authenticate
segments. TCP-AO relies upon:</t>
      <ul spacing="normal">
        <li>
          <t>A Master Key Tuple (MKT)</t>
        </li>
        <li>
          <t>A Key Derivation Function (KDF)</t>
        </li>
        <li>
          <t>A Message Authentication Code (MAC) algorithm</t>
        </li>
      </ul>
      <t>TCP-AO systems are configured with one or more MKTs for each connection that they protect.
When a connection is associated with multiple MKTs, TCP-AO can rotate among them during
the course of a TCP session. This facilitates dynamic key change and authentication algorithm
agility.</t>
      <t>An MKT includes:</t>
      <ul spacing="normal">
        <li>
          <t>Two MKT identifiers, one used for sending and one used for receiving</t>
        </li>
        <li>
          <t>A connection identifier (i.e., a TCP socket pair)</t>
        </li>
        <li>
          <t>A master key (i.e., a shared secret)</t>
        </li>
        <li>
          <t>A KDF</t>
        </li>
        <li>
          <t>A MAC algorithm</t>
        </li>
        <li>
          <t>A flag indicating whether TCP options other than TCP-AO are authenticated</t>
        </li>
      </ul>
      <t>The KDF generates a traffic key. Its inputs are:</t>
      <ul spacing="normal">
        <li>
          <t>A pseudorandom function (PRF) used to generate the traffic key</t>
        </li>
        <li>
          <t>The master key</t>
        </li>
        <li>
          <t>Context (i.e., A binary string containing information related to the connection)</t>
        </li>
        <li>
          <t>Output length (i.e., the length of the traffic key, in bits)</t>
        </li>
      </ul>
      <t>The MAC algorithm produces a MAC. It is defined by:</t>
      <ul spacing="normal">
        <li>
          <t>The KDF algorithm used to generate the traffic key</t>
        </li>
        <li>
          <t>The length of the traffic key, in bits</t>
        </li>
        <li>
          <t>The length of the MAC, in bits</t>
        </li>
      </ul>
      <t>The following are inputs to the MAC Algorithm:</t>
      <ul spacing="normal">
        <li>
          <t>traffic key</t>
        </li>
        <li>
          <t>message</t>
        </li>
      </ul>
      <t>TCP-AO systems include the MAC in the TCP-AO. They use the MAC
to authenticate segments.</t>
      <t><xref target="RFC5926"/> specifies cryptographic algorithms for TCP-AO.
It explains how to use KDF_HMAC_SHA1 and KDF_AES_128_CMAC 
as KDFs. It also explains how to use HMAC-SHA-1-96 and 
AES-128-CMAC-96 as MAC algorithms.</t>
      <t>This document specifies several new KDFs and MAC
algorithms for TCP-AO. The KDFs and MAC algorithms defined in 
this document use stronger cryptography.</t>
      <t>According to <xref target="RFC2104"/>, "Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t".</t>
      <t>The algorithms described in this document truncate the output of HMAC to 128 bits (i.e., 16 bytes). Therefore, when they are encoded in TCP-AO, the TCP-AO consumes 20 bytes.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>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 BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="updates-to-rfc-5926">
      <name>Updates to RFC 5926</name>
      <section anchor="concrete-kdfs">
        <name>Concrete KDFs</name>
        <section anchor="kdfhmacsha256">
          <name>KDF_HMAC_SHA256</name>
          <t>For KDF_HMAC_SHA256:</t>
          <ul spacing="normal">
            <li>
              <t>PRF for KDF_alg:  HMAC-SHA256 <xref target="RFC2104"/> <xref target="DOI.10.6028_NIST.FIPS.180-4"/></t>
            </li>
            <li>
              <t>Use:       HMAC-SHA256(Key, Input).</t>
            </li>
            <li>
              <t>Input:     ( i || Label || Context || Output_Length)</t>
            </li>
            <li>
              <t>Key:       Master_Key, configured by user, and passed to the KDF</t>
            </li>
            <li>
              <t>Output_Length:  256 bits</t>
            </li>
            <li>
              <t>Result:    Traffic_Key, used in the MAC function by TCP-AO</t>
            </li>
          </ul>
        </section>
        <section anchor="kdfhmacsha384">
          <name>KDF_HMAC_SHA384</name>
          <t>For KDF_HMAC_SHA384:</t>
          <ul spacing="normal">
            <li>
              <t>PRF for KDF_alg:  HMAC-SHA384 <xref target="RFC2104"/> <xref target="DOI.10.6028_NIST.FIPS.180-4"/></t>
            </li>
            <li>
              <t>Use:       HMAC-SHA384(Key, Input).</t>
            </li>
            <li>
              <t>Input:     ( i || Label || Context || Output_Length)</t>
            </li>
            <li>
              <t>Key:       Master_Key, configured by user, and passed to the KDF</t>
            </li>
            <li>
              <t>Output_Length:  384 bits</t>
            </li>
            <li>
              <t>Result:    Traffic_Key, used in the MAC function by TCP-AO</t>
            </li>
          </ul>
        </section>
        <section anchor="kdfhmacsha512">
          <name>KDF_HMAC_SHA512</name>
          <t>For KDF_HMAC_SHA512:</t>
          <ul spacing="normal">
            <li>
              <t>PRF for KDF_alg:  HMAC-SHA512 <xref target="RFC2104"/> <xref target="DOI.10.6028_NIST.FIPS.180-4"/></t>
            </li>
            <li>
              <t>Use:       HMAC-SHA512(Key, Input).</t>
            </li>
            <li>
              <t>Input:     ( i || Label || Context || Output_Length)</t>
            </li>
            <li>
              <t>Key:       Master_Key, configured by user, and passed to the KDF</t>
            </li>
            <li>
              <t>Output_Length:  224 bits</t>
            </li>
            <li>
              <t>Result:    Traffic_Key, used in the MAC function by TCP-AO</t>
            </li>
          </ul>
        </section>
        <section anchor="kdfhmacsha3-256">
          <name>KDF_HMAC_SHA3-256</name>
          <t>For KDF_HMAC_SHA3-256:</t>
          <ul spacing="normal">
            <li>
              <t>PRF for KDF_alg:  HMAC-SHA3-256 <xref target="RFC2104"/> <xref target="DOI.10.6028_NIST.FIPS.202"/></t>
            </li>
            <li>
              <t>Use:       HMAC-SHA3-256(Key, Input).</t>
            </li>
            <li>
              <t>Input:     ( i || Label || Context || Output_Length)</t>
            </li>
            <li>
              <t>Key:       Master_Key, configured by user, and passed to the KDF</t>
            </li>
            <li>
              <t>Output_Length:  256 bits</t>
            </li>
            <li>
              <t>Result:    Traffic_Key, used in the MAC function by TCP-AO</t>
            </li>
          </ul>
        </section>
        <section anchor="kdfhmacsha3-384">
          <name>KDF_HMAC_SHA3-384</name>
          <t>For KDF_HMAC_SHA3-384:</t>
          <ul spacing="normal">
            <li>
              <t>PRF for KDF_alg:  HMAC-SHA3-384 <xref target="RFC2104"/> <xref target="DOI.10.6028_NIST.FIPS.202"/></t>
            </li>
            <li>
              <t>Use:       HMAC-SHA3-384(Key, Input).</t>
            </li>
            <li>
              <t>Input:     ( i || Label || Context || Output_Length)</t>
            </li>
            <li>
              <t>Key:       Master_Key, configured by user, and passed to the KDF</t>
            </li>
            <li>
              <t>Output_Length:  384 bits</t>
            </li>
            <li>
              <t>Result:    Traffic_Key, used in the MAC function by TCP-AO</t>
            </li>
          </ul>
        </section>
        <section anchor="kdfhmacsha3-512">
          <name>KDF_HMAC_SHA3-512</name>
          <t>For KDF_HMAC_SHA3-512:</t>
          <ul spacing="normal">
            <li>
              <t>PRF for KDF_alg:  HMAC-SHA3-512 <xref target="RFC2104"/> <xref target="DOI.10.6028_NIST.FIPS.202"/></t>
            </li>
            <li>
              <t>Use:       HMAC-SHA3-512(Key, Input).</t>
            </li>
            <li>
              <t>Input:     ( i || Label || Context || Output_Length)</t>
            </li>
            <li>
              <t>Key:       Master_Key, configured by user, and passed to the KDF</t>
            </li>
            <li>
              <t>Output_Length:  512 bits</t>
            </li>
            <li>
              <t>Result:    Traffic_Key, used in the MAC function by TCP-AO</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="trunc">
        <name>MAC Algorithms</name>
        <t>The following subsections should be added to Section 3.2 of <xref target="RFC5926"/>.</t>
        <section anchor="the-use-of-hmac-sha256-128">
          <name>The Use of HMAC-SHA256-128</name>
          <t>By definition, HMAC <xref target="RFC2104"/> requires a cryptographic hash function.
SHA256 will be that hash function used for authenticating and providing
integrity validation on TCP segments with HMAC.</t>
          <t>The three fixed elements for HMAC-SHA256-128 are:</t>
          <ul spacing="normal">
            <li>
              <t>KDF_Alg:     KDF_HMAC_SHA256</t>
            </li>
            <li>
              <t>Key_Length:  256 bits.</t>
            </li>
            <li>
              <t>MAC_Length:  128 bits.</t>
            </li>
          </ul>
          <t>For:</t>
          <ul spacing="normal">
            <li>
              <t>MAC = MAC_alg (Traffic_Key, Message)</t>
            </li>
          </ul>
          <t>HMAC-SHA256-128 for TCP-AO has the following values:</t>
          <ul spacing="normal">
            <li>
              <t>MAC_alg:     HMAC-SHA256</t>
            </li>
            <li>
              <t>Traffic_Key: Variable; the result of the KDF.</t>
            </li>
            <li>
              <t>Message:     The message to be authenticated, as specified in <xref target="RFC5925"/>, Section 5.1.</t>
            </li>
          </ul>
        </section>
        <section anchor="the-use-of-hmac-sha384-128">
          <name>The Use of HMAC-SHA384-128</name>
          <t>By definition, HMAC <xref target="RFC2104"/> requires a cryptographic hash function.
SHA384 will be that hash function used for authenticating and providing
integrity validation on TCP segments with HMAC.</t>
          <t>The three fixed elements for HMAC-SHA384-128 are:</t>
          <ul spacing="normal">
            <li>
              <t>KDF_Alg:     KDF_HMAC_SHA384</t>
            </li>
            <li>
              <t>Key_Length:  384 bits.</t>
            </li>
            <li>
              <t>MAC_Length:  128 bits.</t>
            </li>
          </ul>
          <t>For:</t>
          <ul spacing="normal">
            <li>
              <t>MAC = MAC_alg (Traffic_Key, Message)</t>
            </li>
          </ul>
          <t>HMAC-SHA384-128 for TCP-AO has the following values:</t>
          <ul spacing="normal">
            <li>
              <t>MAC_alg:     HMAC-SHA384</t>
            </li>
            <li>
              <t>Traffic_Key: Variable; the result of the KDF.</t>
            </li>
            <li>
              <t>Message:     The message to be authenticated, as specified in <xref target="RFC5925"/>, Section 5.1.</t>
            </li>
          </ul>
        </section>
        <section anchor="the-use-of-hmac-sha512-128">
          <name>The Use of HMAC-SHA512-128</name>
          <t>By definition, HMAC <xref target="RFC2104"/> requires a cryptographic hash function.
SHA512 will be that hash function used for authenticating and providing
integrity validation on TCP segments with HMAC.</t>
          <t>The three fixed elements for HMAC-SHA512-128 are:</t>
          <ul spacing="normal">
            <li>
              <t>KDF_Alg:     KDF_HMAC_SHA512</t>
            </li>
            <li>
              <t>Key_Length:  512 bits.</t>
            </li>
            <li>
              <t>MAC_Length:  128 bits.</t>
            </li>
          </ul>
          <t>For:</t>
          <ul spacing="normal">
            <li>
              <t>MAC = MAC_alg (Traffic_Key, Message)</t>
            </li>
          </ul>
          <t>HMAC-SHA512-128 for TCP-AO has the following values:</t>
          <ul spacing="normal">
            <li>
              <t>MAC_alg:     HMAC-SHA512</t>
            </li>
            <li>
              <t>Traffic_Key: Variable; the result of the KDF.</t>
            </li>
            <li>
              <t>Message:     The message to be authenticated, as specified in <xref target="RFC5925"/>, Section 5.1.</t>
            </li>
          </ul>
        </section>
        <section anchor="the-use-of-hmac-sha3-256-128">
          <name>The Use of HMAC-SHA3-256-128</name>
          <t>By definition, HMAC <xref target="RFC2104"/> requires a cryptographic hash function.
SHA3-256 will be that hash function used for authenticating and providing
integrity validation on TCP segments with HMAC.</t>
          <t>The three fixed elements for HMAC-SHA3-256-128 are:</t>
          <ul spacing="normal">
            <li>
              <t>KDF_Alg:     KDF_HMAC_SHA3-256.</t>
            </li>
            <li>
              <t>Key_Length:  256 bits.</t>
            </li>
            <li>
              <t>MAC_Length:  128 bits.</t>
            </li>
          </ul>
          <t>For:</t>
          <ul spacing="normal">
            <li>
              <t>MAC = MAC_alg (Traffic_Key, Message)</t>
            </li>
          </ul>
          <t>HMAC-SHA3-256-128 for TCP-AO has the following values:</t>
          <ul spacing="normal">
            <li>
              <t>MAC_alg:     HMAC-SHA3-256.</t>
            </li>
            <li>
              <t>Traffic_Key: Variable; the result of the KDF.</t>
            </li>
            <li>
              <t>Message:     The message to be authenticated, as specified in <xref target="RFC5925"/>, Section 5.1.</t>
            </li>
          </ul>
        </section>
        <section anchor="the-use-of-hmac-sha3-384-128">
          <name>The Use of HMAC-SHA3-384-128</name>
          <t>By definition, HMAC <xref target="RFC2104"/> requires a cryptographic hash function.
SHA3-384 will be that hash function used for authenticating and providing
integrity validation on TCP segments with HMAC.</t>
          <t>The three fixed elements for HMAC-SHA3-384-128 are:</t>
          <ul spacing="normal">
            <li>
              <t>KDF_Alg:     KDF_HMAC_SHA3-384.</t>
            </li>
            <li>
              <t>Key_Length:  384 bits.</t>
            </li>
            <li>
              <t>MAC_Length:  128 bits.</t>
            </li>
          </ul>
          <t>For:</t>
          <ul spacing="normal">
            <li>
              <t>MAC = MAC_alg (Traffic_Key, Message)</t>
            </li>
          </ul>
          <t>HMAC-SHA3-384-128 for TCP-AO has the following values:</t>
          <ul spacing="normal">
            <li>
              <t>MAC_alg:     HMAC-SHA3-384.</t>
            </li>
            <li>
              <t>Traffic_Key: Variable; the result of the KDF.</t>
            </li>
            <li>
              <t>Message:     The message to be authenticated, as specified in <xref target="RFC5925"/>, Section 5.1.</t>
            </li>
          </ul>
        </section>
        <section anchor="the-use-of-hmac-sha3-512-128">
          <name>The Use of HMAC-SHA3-512-128</name>
          <t>By definition, HMAC <xref target="RFC2104"/> requires a cryptographic hash function.
SHA3-512 will be that hash function used for authenticating and providing
integrity validation on TCP segments with HMAC.</t>
          <t>The three fixed elements for HMAC-SHA3-224-128 are:</t>
          <ul spacing="normal">
            <li>
              <t>KDF_Alg:     KDF_HMAC_SHA3-512.</t>
            </li>
            <li>
              <t>Key_Length:  512 bits.</t>
            </li>
            <li>
              <t>MAC_Length:  128 bits.</t>
            </li>
          </ul>
          <t>For:</t>
          <ul spacing="normal">
            <li>
              <t>MAC = MAC_alg (Traffic_Key, Message)</t>
            </li>
          </ul>
          <t>HMAC-SHA3-512-128 for TCP-AO has the following values:</t>
          <ul spacing="normal">
            <li>
              <t>MAC_alg:     HMAC-SHA3-512.</t>
            </li>
            <li>
              <t>Traffic_Key: Variable; the result of the KDF.</t>
            </li>
            <li>
              <t>Message:     The message to be authenticated, as specified in <xref target="RFC5925"/>, Section 5.1.</t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>According to <xref target="RFC2104"/>, "Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t".</t>
      <t>The algorithms described in this document truncate the output of HMAC to 128 bits (i.e., 16 bytes). Therefore, when they are encoded in TCP-AO, the TCP-AO consumes 20 bytes.</t>
      <t><xref target="RFC2104"/> continues, "We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker).</t>
      <t>In this document, only the following MAC algorithms comply with that recommendation:</t>
      <ul spacing="normal">
        <li>
          <t>HMAC-SHA256-128</t>
        </li>
        <li>
          <t>HMAC-SHA3-256-128</t>
        </li>
      </ul>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to add the following entries to the "Cryptographic Algorithms for TCP-AO Registration" (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-3).</t>
      <table anchor="iana">
        <name>IANA Actions</name>
        <thead>
          <tr>
            <th align="left">Algorithm</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">SHA256-128</td>
            <td align="left">This Document</td>
          </tr>
          <tr>
            <td align="left">SHA384-128</td>
            <td align="left">This Document</td>
          </tr>
          <tr>
            <td align="left">SHA512-128</td>
            <td align="left">This Document</td>
          </tr>
          <tr>
            <td align="left">SHA3-256-128</td>
            <td align="left">This Document</td>
          </tr>
          <tr>
            <td align="left">SHA3-384-128</td>
            <td align="left">This Document</td>
          </tr>
          <tr>
            <td align="left">SHA3-512-128</td>
            <td align="left">This Document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to Lars Eggert, Gorry Fairhurst, C.M. Heard, Russ Housley, John Mattsson, Yoshifumi Nishida, Joe Touch, Michael Tuxen, and Magnus Westerlund for their review and comments.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC2104">
        <front>
          <title>HMAC: Keyed-Hashing for Message Authentication</title>
          <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
          <author fullname="M. Bellare" initials="M." surname="Bellare"/>
          <author fullname="R. Canetti" initials="R." surname="Canetti"/>
          <date month="February" year="1997"/>
          <abstract>
            <t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2104"/>
        <seriesInfo name="DOI" value="10.17487/RFC2104"/>
      </reference>
      <reference anchor="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>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="RFC4615">
        <front>
          <title>The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)</title>
          <author fullname="J. Song" initials="J." surname="Song"/>
          <author fullname="R. Poovendran" initials="R." surname="Poovendran"/>
          <author fullname="J. Lee" initials="J." surname="Lee"/>
          <author fullname="T. Iwata" initials="T." surname="Iwata"/>
          <date month="August" year="2006"/>
          <abstract>
            <t>Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES). This memo describes such an algorithm, called AES-CMAC-PRF-128. It supports fixed and variable key sizes. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4615"/>
        <seriesInfo name="DOI" value="10.17487/RFC4615"/>
      </reference>
      <reference anchor="RFC5925">
        <front>
          <title>The TCP Authentication Option</title>
          <author fullname="J. Touch" initials="J." surname="Touch"/>
          <author fullname="A. Mankin" initials="A." surname="Mankin"/>
          <author fullname="R. Bonica" initials="R." surname="Bonica"/>
          <date month="June" year="2010"/>
          <abstract>
            <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5925"/>
        <seriesInfo name="DOI" value="10.17487/RFC5925"/>
      </reference>
      <reference anchor="RFC5926">
        <front>
          <title>Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)</title>
          <author fullname="G. Lebovitz" initials="G." surname="Lebovitz"/>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
          <date month="June" year="2010"/>
          <abstract>
            <t>The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5926"/>
        <seriesInfo name="DOI" value="10.17487/RFC5926"/>
      </reference>
      <reference anchor="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>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="DOI.10.6028_NIST.FIPS.180-4">
        <front>
          <title>Secure hash standard</title>
          <author>
            <organization/>
          </author>
          <date year="2015"/>
        </front>
        <seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/>
        <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
      </reference>
      <reference anchor="DOI.10.6028_NIST.FIPS.197">
        <front>
          <title>Advanced Encryption Standard (AES)</title>
          <author>
            <organization/>
          </author>
          <date year="2001"/>
        </front>
        <seriesInfo name="DOI" value="10.6028/nist.fips.197"/>
        <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
      </reference>
      <reference anchor="DOI.10.6028_NIST.FIPS.202">
        <front>
          <title>SHA-3 standard :: permutation-based hash and extendable-output functions</title>
          <author>
            <organization/>
          </author>
          <date year="2015"/>
        </front>
        <seriesInfo name="DOI" value="10.6028/nist.fips.202"/>
        <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
      </reference>
      <reference anchor="DOI.10.6028_NIST.SP.800-38B">
        <front>
          <title>Recommendation for block cipher modes of operation :: the CMAC mode for authentication</title>
          <author fullname="M J Dworkin" initials="M." surname="Dworkin">
            <organization/>
          </author>
          <date year="2016"/>
        </front>
        <seriesInfo name="DOI" value="10.6028/nist.sp.800-38b"/>
        <refcontent>National Institute of Standards and Technology</refcontent>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1a7XLbuBX9j6dA7T92ajKSkngddb8Uf2zc2LFry83s7O54
IBISMaYILkBa0cR+lz5Ln6znAqREyXbsTuKOO7ueSQSC4MXFwbnnAiCDIGCR
jlU26vKyGAZb8ysbCBspxVihilR2eS+OVaF0JlJ+KqPSqGLKe+lIo5CMLd/T
hp9ZyT/gkve3j4PeERODgZGXXV5EeSB0INKRZbGOMjGGvdiIYREMdKYiEaDF
OGg0C1otFolCwvy0y20RszKPcW27/GRvm7963dlkthyMlbVwqZjmMLi/299j
zBYii89FqjNUTaVlueryXwodbXD8p8e5iApXVFksMxStNoWRQ4vSdOwLVbPf
GFO5gfumtEWn1Xrd6jBhpOjyvhGZzfEgmwAqjPaQf9DmAsDxn4wuc3Yx6dYg
MFEWiTZdxjgP8I9zldEwQv7Gjd1VeUhOdNas1AbG3x7vuotIl1lBYJyd9lyF
HAuVdrmhGYlDj+OPSS5DeL/UVz/kB6rRT19n07rmQZ0UeCBM1Y/VL+OMZdqM
RaEuZRcNMSedduvlrNh+XRVfbrZfVUXMWaO4WRW32t+4x3aO9sN2K9xsdbae
v98/7Yd7+8enYXurFXzu9utv7r7ZaXVuvXl6HG61WsGLrTeYkiAIuBjYwmC6
Gatc4zaXkRoqaXlkpnmhR0bkiYq4mNN9CLr7CQ7ZfsHlxzwVwJonegK0ED2S
v9vZO3972Ns+P33ba3Ow0tX0dk/P252t823c4UxYqrQhhw2RWn2rITISwEjQ
Dl5vOkMMVgJYCciKq7Sc7M0dDBnrJ8pyhFs5Bs8bY7LyUhpEcSYnrnNnEU+z
24fH+4lcaNeEobYag2icFQs9kutAVmcjaZpATkOP+1jFcSoZW+X7IJ2Oy4jk
hX9aVXR5jQFsH3OZxUGuUWOdvQK+UHUPMYU+QHn3zFHufta8y+v806eKcNfX
BKKYt5bMyhG5B8x9a25kSrCUuc7AiGe8xw+FLeDzOznl/TJPJV87fNdfd7eo
bkcadek73isz7/UaEPItDqW1YiSXXdzWMdnpba/P8XNDJBfsFB0CTqgLYjAb
qlFpgOmEtBRChiDlY417cMPPjRRRQi0z6bsvElEQOFOeG12gMmQf0DsXzUaY
HGEtlA8wVMbHZVooGiFZ3qgRiUQGXSnQjIsx5o8sj3kMzc9GjKYAOmEwG3qI
Dmg6rHQ6TFxBJ0MRqVTR42DDFJKD0LmAa1EiwAVHI7EIzhwRMaJHiSK9jJwC
r6K0jCH8NDX9ifaVJN3EOwOnCSBwI3bAWBCGZJg6WbhhZCTVJQ2AJqmJyswW
X1OhDDfqMenoQhY8F8r4iR17VtBIZg1tImiirIyMLCqG7Ox5HjQjxdUMUzHC
eGI3avg4SSRQcIHGtWOw5drVYDqzejKIE00CxxTZLiL5SGaIZIJZIEmJ4dAD
TWpi0VFeFo5SFatzK8tYI3PFesyHM+Ien+yte5gQKbVFF2gNk4Q9auYQoGIb
iVd+LGowenygMmGmFPM0OkBcQMmoqLKhzxboD9Hm6IfOPJPqiSD0jsoCTvNU
ZiOQszJMzaoaEG7JsQ0SnoEq7LqHZQF1CgbIisMHN5zKkkLJocrgwmDqSVWh
OX/sgWjc79StDeHJvIFzeqjTVE8cbTHZ1cRVANGAZsss5++iI2MvNzekpIqb
mQ2V1eJZi/p0pqgk/ksyyWcyyVitpptQ0z9T40NTY82y/y4x9qJIG6dgGKED
nhZW19cbfKWX52klmJa4RGN3Uh0lWtNMalqpZlFNWO2DqW45mFY1TnscY0HM
YTHWtnBcrPnp7WIJXBY+ZJ2u6rGEFhqsH0kBipXQU3dhwDYyauCHvDjiz/kF
tzFd3oMq4tub8Baytu4QxpocuW+D5DLzOY6iRGbYqfi+/GxsNPhNsmLRteWd
ljcV0joDinVJBCcAacZ2aIrcpqYKRNL2CfC3fOXw7LS/suF/+fsjVz7Z/cfZ
/snuDpVBuoODWYFVLU7fHp0d7MxL8ye3jw4Pd9/v+IdRyxeq2Mph72fcIa9W
jo77+0fvewcrN4GkkQOwAakE5iFH1gEGAtuqJvhvto///a/2S/DnL9VyHJHr
L2i9jQvCcqNKkum0uiRsmchzKQxZEWkKeuVI5CmyLMLIIvAyThMCNJ/9Qsj8
1uXfDqK8/fL7qoIGvFBZY7ZQ6TC7WXPjYQ/iLVW3dDNDc6F+CelFf3s/L1zX
uDcqv/0hRRDzoL31w/eMEYfO/D6UZmG2E2Wrjlu0BvB6QDWrCyrXeYVmtEde
qnSKjhTsgozuIaC6fKZraNFUAZQ/s1G6voYt7MG73P81jKy9o6y0T5llPUQr
V/Lt1rjiv179esUPxECmvlindnfhk/L5gUtilKVhq+7Cr5TPnfXGwnXgcovx
DMux6JwnfL88WrAJYzTOKmGeSItFqeug7zOdN++ScpXFSDdmKxh0Vm+1l1F/
sfXyJuqovAd1tPhy1GHkqaNO43wE1F+1OzdRR+U9qKPFl6MOI08d9U7nUVB/
EdyqMa76Pr4HD9WZTqtzJ9+DP7DOBLcrTfAArQkeqjafxf6PqzYvglv1xlXf
i/1DNeez2P8faA6N8ytgTwudhQ2p5Z9W3eL+enkna8uB9Rt7t3As05hWrSKO
vaun1enLi7BDO4HGFjP0U0zWzvwZU2MdQzs7xt5M/e7KLd03/DaiOYtG/l4q
47b9i7vURNhkNrCQVQusicJKdyD9IdpCk/nxUfPAqjpeyo2+VLRVY7QWH7kX
IpciVbHfNemsOhrz+2h/3kauVjunIjESgKmP6EGm0jeirpaGOzvBcVtkx1/8
La8tHWtu6hxxkVrNbtRbrdBFjLNL6H3nWiE6+NoCKarDzHXGlr2ab4MJMsea
+eQDhrI6sqvsdpdXpHQ0Mu+py/8pjBKDVP7NmTKOpPWOFIN1A/HOeFPuOKo6
avU7ooVDMr9haZ5ON86EN2b0exW27+YbBOur841E8InyrRru/XyjXLfEt1rb
vz7faq++iG/e46fON4j0V+cbCf8T5Vs13Pv5Rvl9iW91Pvv6fKu9+iK+eY+f
DN/uFLjgMVKq3008UdLNhvwAmaOm4f8us85d+zKtq91+MvS7k32PkmCDp5xi
g4cnWWp6g32PmGeDr5Npa7efPvseI936HeWTZV+n82D2YRw32Pd4WXc2G1/K
vsrtp8O++cdy2PRbFdMLZf/C6c9XfY/2qq8ZvfQdgspAG+D6gaYf44Wn8eyb
mdrL6i19QROeabq21n+JkYh0eMtnCC6yq4fXMLaxKKLE3RkoUySxgPtFIaIL
PtBlFq+7IF+0vNWq0BDclqoglnJwHbC7R7j25zFZOR6gDv261s7zTPqTFHib
GxmrqPAHQ7Dqe5VmHVDsL03Qhn/jtxhXS6+uiRH0VpAExvU1A82xxMXf8qHM
s9tWlat8v/e+d4P5rhI+kbBKW30NIuJ4ySt4a5ScfQmxsr0gvr3bXsnzEzlS
9Dkf9bTC15KiyG33+fPJZBIqkYlQm9FzYa0aZU4fn9M3pzOuL1+GH5NinK4u
VgYvCFZ2NXeAX6HbIcibRZJfsatg9vfXeTHADWhL4wTlyn8ttVNHzqxBnYjv
bFBr5d0Wgvs7Ce7tZi7KN5t86vJVApS7r4O/W3FT2vPnfSvX7k1pL7rI9CSV
8cjnIlIRkV24+TwQxvLd0UgaEPInbcyU7wllktJYVGyHhyF/K4WB1p6UiJW3
urQpZY6/6yTjh+C3tZSqf9Y2UcNyrPh7hVIsqAWUQZdRgjSjokTIlPfLj/Xb
7kMxykrLPxDrTEoRRtwBuxR9IXap5MQ182x3+Yyx/wC9+9D1JC0AAA==

-->

</rfc>
