<?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.35 (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-ietf-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.33.0 -->
  <front>
    <title abbrev="tcp-ao-algs">Additional Security Algorithms For Use With TCP-AO</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-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="April" day="27"/>
    <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:  512 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-512-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+1abVPbOhb+rl+hhS/QxW6StlyavW8pL7dsobAQttO59w6j
2EqswbG8kk2aKfyX/S37y/Y5kp04AQo7LTvM3MtMG1mWj44ePec5kuwgCFik
Y5WNurwshsHW/MoGwkZKMVaoIpVd3otjVSidiZSfyqg0qpjyXjrSKCRjy/e0
4WdW8g+45P3t46B3xMRgYORllxdRHggdiHRkWayjTIxhLzZiWARKolfcHweN
RkGrxSJRSBifdrktYlbmMa5tl5/sbfNXrzubzJaDsbIWDhXTHOb2d/t7jNlC
ZPG5SHWGqqm0LFdd/muhow2O//Q4F1HhiiqLZYai1aYwcmhRmo59oWr2O2Mq
N3DelLbotFqvWx0mjBRd3jciszkeZBMAhbEe8g/aXAA2/ovRZc4uJt0aAibK
ItGmyxjnAf5xrjIaRsjf6ExFwlV5QE501qzUBsbfHu+6i0iXWUFgnJ32XIUc
C5V2uaH5iMOBe+znJJchvF/qqx/yA9Xop6+zaV3zoE4KPBCm6ufql3HGMm3G
olCXsouGmJNOu/VyVmy/roovN9uvqiLmrFHcrIpb7e/cYztH+2G7FW62OlvP
3++f9sO9/ePTsL3VCr50+/V3d9/stDq33jw9DrdareDF1htMSRAEXAxsYTDd
jFWucZvLSA2VtDwy07zQIyPyREVczMk+BNn9BIdsv+DyU54KYM0TPQFaiB3J
3+3snb897G2fn77ttTlY6Wp6u6fn7c7W+TbucCYsVdqQw4ZIrb7VEBkJYCRo
B683nSEGKwGsBGTFVVpO9uYOhoz1E2U5gq0cg+eNMVl5KQ1iOJMT17mziKfZ
7cPj/UQutGvCUFuNQTTOioUeyXUgq7ORNE0gp6HHfaziOJWMrfJ9kE7HZUTi
wj+vKrq8xgC2j7nM4iDXqLHOXgFfqLqHmEIfoLx75ih3P2ve5XX++XNFuOtr
AlHMW0tm5YjcA+a+NTcyJVjKXGdgxDPe44fCFvD5nZzyfpmnkq8dvuuvu1tU
tyONuvQd75WZ93oNCPkWh9JaMZLLLm7rmOz0ttfn+Lkhkgt2ig4BJ9QFMZgN
1ag0wHRCSgohQ5DyscY9uOHnRooooZaZ9N0XiSgInCnPjS5QGbIP6J2LZiNM
jrAWygcYKuPjMi0UjZAsb9SIRCKDrhRoxsUY80eWxzyG4mcjRlMAnTCYDT1E
BzQdVjodJq6gk6GIVKrocbBhCslB6FzAtSgR4IKjkVgEZ46IGNGjRJFeRk6B
V1FaxhB+mpr+RPtKkm7inYHTBBC4ETtgLAhDMkydLNwwMpLqkgZAk9REZWaL
r6lQhhv1mHR0IQueC2X8xI49K2gks4Y2ETRRVkZGFhVDdvY8D5qR4mqGqRhh
PLEbNXycJBIouEDj2jHYcu1qMJ1ZPRnEiSaBY4psF5F8JDNEMsEskKTEcOiB
JjWx6CgvC0epitW5lWWskbliPebDGXGPT/bWPUyIlNqiC7SGScIeNXMIULGN
xCs/FTUYPT5QmTBTinkaHSAuoGRUVNnQZwv0h2hz9ENnnkn1RBB6R2UBp3kq
sxHIWRmmZlUNCLfk2AYJz0AVdt3DsoA6BQNkxeGDG05lSaHkUGVwYTD1pKrQ
nD/2QDTud+rWhvBk3sA5PdRpqieOtpjsauIqgGhAs0WW83fRkbGXmxtSUsXN
zIbKavGsRX06U1QS/yWZ5DOZZKxW002o6Z+p8aGpsWbZ/5YYe1GkjVMwjNAB
Twur6+sNvtLL87QSTEtcorE7qY4SrWkmNa1Us6gmrPbBVLccTKsapz2OsSDm
sBhrWzgu1vz0drEELgsfsk5X9VhCCw3Wj6QAxUroqbswYBsZNfBDXhzxl/yC
25gu70EV8e1NeAtZW3cIY02O3LdBcpn5HEdRIjPsU3xffjY2GvwmWbHo2vJO
y5sKaZ0BxbokghOANGM7NEVuS1MFImn7BPhbvnJ4dtpf2fC//P2RK5/s/uNs
/2R3h8og3cHBrMCqFqdvj84Odual+ZPbR4eHu+93/MOo5QtVbOWw9xF3yKuV
o+P+/tH73sHKTSBp5ABsQCqBeciRdYCBwKaqCf6b7eP//Lv9Evz5S7UcR+T6
C1pv44Kw3KiSZDqtLglbJvJcCkNWRJqCXjkSeYosizCyCLyM04QAzWe/EjK/
d/n3gyhvv/yxqqABL1TWmC1UOsxu1tx42IN4S9Ut3czQXKhfQnrR397Hhesa
90bl9z+lCGIetLd++pEx4tCZ34fSLMx2omzVcYvWAF4PqGZ1QeU6r9CMdshL
lU7RkYJdkNE9BFSXz3QNLZoqgPIXNkrX17CFHXiX+7+GkbV3lJX2KbOsh2jl
Sr7dGlf8t6vfrviBGMjUF+vU7i58Uj4/cEmMsjRs1V34lfK5s95YuA5cbjGe
YTkWnfOE75dHCzZhjMZZJcwTabEodR30fabz5l1SrrIY6cZsBYPO6q32Muov
tl7eRB2V96COFl+POow8ddRpnI+A+qt25ybqqLwHdbT4etRh5KmjTuN8DK4H
t2qMq76P78FDdabT6tzJ9+APrDPB7UoTPEBrgoeqzRex/+OqzYvgVr1x1fdi
/1DN+SL2fxzNoYXOwobU8s+rbnF/vbyTteXA+o29WziWaUyrVhHH3tXT6vTl
RdihnUBjixn6KSZrZ/6MqbGOoZ0dY2+mfnfllu4bfhvRnEUj/1Uq47b9i7vU
RNhkNrCQVQusicJKdyD9IdpCk/nxUfPAqjpeyo2+VLRVY7QWH7nXIZciVbHf
NemsOhrz+2h/3kauVjunIjESgKlP6EGm0jeirpaGOzvBcVtkx1/8La8tHWtu
6hxxkVrNbtRbrdBFjLNL6P3gWiE6+NoCKarDzHXGlr2ab4MJMsea+eQDhrI6
sqvsdpdXpHQ0Mu+py/8pjBKDVP7NmTKOpPWOFIN1A/HOeFPuOKo6avU7ooVD
Mr9haZ5ON86EN2b0exW27+YbBOub841E8InyrRru/XyjXLfEt1rbvz3faq++
im/e46fON4j0N+cbCf8T5Vs13Pv5Rvl9iW91Pvv2fKu9+iq+eY+fDN/uFLjg
MVKq3008UdLNhvwAmaOm4f8vs85d+zqtq91+MvS7k32PkmCDp5xig4cnWWp6
g32PmGeDb5Npa7efPvseI936HeWTZd+DU65reoN9j5d15659Jfsqt58O++af
ymHTb1VML5T9C6c/X/U92qu+ZvTSdwgqA22A6weafowXnsazb2ZqL6u39AVN
eKbp2lr/JUYi0uEtnyG4yK4eXsPYxqKIEndnoEyRxALuF4WILvhAl1m87oJ8
0fJWq0JDcFuqgljKwXXA7h7h2p/HZOV4gDr061o7zzPpT1LgbW5krKLCHwzB
qu9VmnVAsb80QRv+jd9iXC29uiZG0FtBEhjX1ww0xxIXf8uHMs9uW1Wu8v3e
+94N5rtK+ETCKm31NYiI4yWv4K1RcvYlxMr2gvj2bnslz0/kSNHnfNTTCl9L
iiK33efPJ5NJqEQmQm1Gz4W1apQ5fXxO35zOuL58GX5KinG6ulgZvCBY2dXc
AX6FbocgbxZJfsWugtnfX+fFADegLY0TlCv/tdROHTmzBnUivrNBrZV3Wwju
7yS4t5u5KN9s8rnLVwlQ7r4N/mHFTWnPn/etXLs3pb3oItOTVMYjn4tIRUR2
4ebzQBjLd0cjaUDIX7QxU74nlElKY1GxHR6G/K0UBlp7UiJW3urSppQ5/q6T
jB+C39ZSqv6obaKG5Vjx9wqlWFALKIMuowRpRkWJkCnvl5/qt92HYpSVln8g
1pmUIoy4A3Yp+kLsUsmJa+bZ7vIZY/8FNFEn1CItAAA=

-->

</rfc>
