<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<rfc category="std" docName="draft-mahesh-karp-rkmp-06" ipr="trust200902">
  <front>
    <title abbrev="TCP-AO-IKEv2">Negotiation for Keying Pairwise Routing
    Protocols in IKEv2</title>

    <author fullname="Mahesh Jethanandani" initials="M. J."
            surname="Jethanandani">
      <organization/>

      <address>
        <postal>
          <street/>

          <city/>

          <region>California</region>

          <code/>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>mjethanandani@gmail.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Brian Weis" initials="B. W." surname="Weis">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone>+1 (408) 526-4796</phone>

        <facsimile/>

        <email>bew@cisco.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Keyur Patel" initials="K. P." surname="Patel">
      <organization>Arrcus</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region>California</region>

          <code/>

          <country>USA</country>
        </postal>

        <facsimile/>

        <email>keyur@arrcus.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Dacheng Zhang" initials="D. Z." surname="Zhang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhangdacheng@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Sam Hartman" initials="S. H." surname="Hartman">
      <organization>Painless Security</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>hartmans@painless-security.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Uma Chunduri" initials="U. C." surname="Chunduri">
      <organization>Ericsson Inc.</organization>

      <address>
        <postal>
          <street>300 Holger Way</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>uma.chunduri@ericsson.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Albert Tian" initials="A. T." surname="Tian">
      <organization>Ericsson Inc.</organization>

      <address>
        <postal>
          <street>300 Holger Way</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>albert.tian@ericsson.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Joe Touch" initials="J. T." surname="Touch">
      <organization>USC/ISI</organization>

      <address>
        <postal>
          <street>4676 Admiralty Way</street>

          <city>Marina del Rey</city>

          <region>California</region>

          <code>90292-6695</code>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>touch@isi.edu</email>

        <uri/>
      </address>
    </author>

    <date day="22" month="July" year="2018"/>

    <abstract>
      <t>This document describes a mechanism to secure the routing protocols
      which use unicast to transport their signaling messages. Most of such
      routing protocols are TCP-based (e.g., BGP and LDP), and the TCP
      Authentication Option (TCP-AO) is primarily employed for securing the
      signaling messages of these routing protocols. There are also two
      exceptions: BFD which is over UDP or MPLS, and RSVP-TE which is over IP
      (but employs an integrated approach to protecting the signaling messages
      instead of using IPsec). The proposed mechanism secures pairwise
      TCP-based Routing Protocol (RP) associations, BFD associations and
      RSVP-TE associations using the IKEv2 Key Management Protocol (KMP)
      integrated with TCP-AO, BFD, and RSVP-TE respectively. Included are
      extensions to IKEv2 and its Security Associations to enable its key
      negotiation to support TCP-AO, BFD, and RSVP-TE.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Existing routing protocols using unicast pairwise communication model
      (e.g., BGP, LDP, RSVP-TE, and BFD) have cryptographic authentication
      mechanisms that use a key shared between the network devices (devices
      for short) on the both sides of the model to protect routing message
      exchanges between endpoints. The unicast key management for these
      protocols today is limited to statically configured master keys in
      individual network devices. This document defines a mechanism to secure
      such pairwise Routing Protocol (RP) associations using <xref
      target="RFC7296">IKEv2</xref>, allowing network devices to automatically
      exchange keying material related information between the network
      devices. To benefit the discussion, it is implied that the routing
      protocols mentioned in the remainder of this memo use unicast pair-wise
      communication model, unless otherwise mentioned.</t>

      <t>This memo assumes that network devices need to be provisioned with
      some credentials for a one-to-one authentication protocol. Any method
      for a pairwise security protocol specified for use with IKEv2 is
      applicable.</t>

      <t>When two network devices running a routing protocol have not yet
      established a secure association, the two endpoints need to select a KMP
      solution that meets their mutual requirements and use that KMP solution
      to establish the required security before sending out any routing
      protocol packets. The KMP solution typically enables the network devices
      to perform mutual authentication using their provisioned credentials and
      to agree upon certain keying material as the result of an successful
      authentication. The keying material then can be applied to secure the
      routing protocol.</t>

      <section title="Terminologies">
        <t>This section lists the key terminologies used throughout the
        memo.</t>

        <t>Network Device: In this memo, a router or any other type of device
        participating in routing protocols is referred to as a network
        device.</t>

        <t>Key Management Database (KDMB): A KDMB is a conceptual database
        which locates in the middle of a key management protocol and a routing
        protocol to provide the long-term key management service. Therefore,
        the RP and the KMP need not to cooperate directly.</t>
      </section>

      <section title="Acronyms and Abbreviations">
        <t>The following acronyms and abbreviations are used throughout this
        memo.</t>

        <t><list counter="" hangIndent="6" style="hanging">
            <t hangText="IKEv2">Internet Key Exchange Protocol Version 2</t>

            <t hangText="RP">Routing Protocol</t>

            <t hangText="SA">Security Association</t>

            <t hangText="KMP">Key Management Protocol</t>
          </list></t>
      </section>
    </section>

    <section title="Overview">
      <t>As illustrated in Figure 1, this work makes use the state machine of
      IKEv2. Assume a network device and its peer device are in State 1. That
      is, the device has not authenticated its peer device and does not have
      the keys to secure the routing protocol packets which it would like to
      exchange with the peer. Before sending any routing protocol packets, the
      two devices need to perform a IKE_SA_INIT exchange. If the IKE_SA_INIT
      exchange succeeds, both network devices are transferred to State 2 where
      they have agreed upon certain keying material but have decided how to
      use the material to derive keys to secure routing protocols. To achieve
      this objective, the two network devices perform an IKE_AUTH exchange, in
      which both endpoints try to authenticate each other and generate
      security associations for the routing protocol they intend to support.
      If the IKE_AUTH exchange succeeds, the network devices transfer their
      state to State 3 where both endpoints are authenticated and keys for
      securing the routing protocols are generated. If the endpoints intend to
      generate new SAs for routing protocols by using the keying material
      already generated, they can just perform an CREATE_CHILD_SA exchange. A
      discussion in more details can be found in Section 4.<figure
          align="center" anchor="state-machine" title="State Diagram">
          <preamble/>

          <artwork><![CDATA[


                 -----------------------
      =======> |   Not Authenticated   |==========
     ||        |   No RP Keys          |          ||
     ||         -----------------------       IKE_SA_INIT exchange
     ||                State 1                    ||
     ||                                           ||
INFORMATIONAL                                     VV
     ||                                 --------------------------
     ||                                 | Privacy Keys Exchanged | 
     ||                                 | No RP Keys             |
     ||                                 --------------------------
     ||                                           ||  State 2
     ||                                           ||   
     ||         |--------------------          IKE_AUTH exchange
       =========| Authenticated     | <============                   
                | RP Keys Derived   | ==== 
                 --------------------   ||
                 State 3 ^^             ||
                         ||        CREATE_CHILD_SA
                         ||             ||
                          =============== ]]></artwork>
        </figure></t>

      <section title="Types of Keys">
        <t>Three types of keys mentioned the discussion of this memo are
        listed as follows:</t>

        <t><list style="symbols">
            <t>PSK (Pre-Shared Key) : a PSK is a pair-wise unique key, which
            can be used for securing the routing protocol exchanges or be used
            for authenticating a network device by a KMP. These keys are
            configured by some mechanism such as manual configuration or a
            management application outside of the scope of KMP.</t>

            <t>Protocol master key: A protocol master key is a key exported by
            a KMP for use by a routing protocol. This is the key that is
            shared in the KMDB between the routing protocol and KMP. A routing
            protocol may use a protocol master key directly or derive traffic
            keys from it.</t>

            <t>Traffic key: A traffic key is the key actually used to protect
            the integrity of the routing messages exchanged in a routing
            protocol. In existing cryptographic authentication mechanisms for
            routing protocols, the traffic key can be the same as or derived
            from the protocol master key. If there is no KMP provided, a
            traffic key can be the same as or derived from a pre-shared
            key.</t>
          </list></t>
      </section>
    </section>

    <section title="Protocol Exchanges">
      <t>The KARP analysis in BGP, LDP, PCEP, and MSDP indicates that all of
      these routing protocols need a dedicated key management protocol<xref
      target="RFC6952"> </xref> to confidentially exchange keying material
      between endpoints. There is no need to define an entirely new protocol
      for this purpose, when existing mature protocol exchanges and methods
      have been vetted. This draft makes use of the IKEv2 protocol exchanges,
      state machine, and policy definitions to define a dedicated key
      management protocol.</t>

      <t>The notations contained in the IKEv2 message are defined as
      follows.</t>

      <texttable align="center" title="Acronyms Used in Protocol Exchange">
        <ttcol>Notation</ttcol>

        <ttcol>Payload</ttcol>

        <c>AUTH</c>

        <c>Authentication</c>

        <c>CERT</c>

        <c>Certificate</c>

        <c>CERTREQ</c>

        <c>Certificate Request</c>

        <c>D</c>

        <c>Delete</c>

        <c>HDR</c>

        <c>IKEv2 Header (not a payload)</c>

        <c>IDi</c>

        <c>Identification - Initiator</c>

        <c>IDr</c>

        <c>Identification - Responder</c>

        <c>KE</c>

        <c>Key Exchange</c>

        <c>Ni, Nr</c>

        <c>Nonce</c>

        <c>N</c>

        <c>Notify</c>

        <c>SA</c>

        <c>Security Association</c>

        <c>SK</c>

        <c>Encrypted and Authenticated</c>

        <c>TSi</c>

        <c>Traffic Selector - Initiator</c>

        <c>TSr</c>

        <c>Traffic Selector - Responder</c>
      </texttable>

      <t/>

      <section anchor="IKE_SA_INIT" title="IKE_SA_INIT">
        <t>A network device desiring to negotiate a key and other associated
        parameters for a pair-wise routing protocol to a peer initiates an
        IKE_SA_INIT exchange defined in <xref target="RFC7296">IKEv2 </xref>.
        The IKE_SA_INIT exchange is a two-message exchange that allows the
        network devices to negotiate cryptographic algorithms, exchange nonce
        information, and do a <xref target="DH"> Diffie-Hellman (DH) </xref>
        exchange, for their routing protocols, after which protocols on these
        network devices can communicate privately. Note that at the end of a
        IKE_SA_INIT exchange the endpoints on the both sides have not
        authenticated each other yet. For the details of this exchange, refer
        to IKE_SA_INIT in <xref target="RFC7296">IKEv2 </xref>.</t>

        <t><figure align="center" title="IKE_SA_INIT">
            <artwork><![CDATA[ Peer (Initiator)                   Peer (Responder)
 --------------------               ------------------
 HDR, SAi1, KEi, Ni        -->
                           <--      HDR, SAr1, KEr, Nr, [CERTREQ,]
]]></artwork>
          </figure></t>

        <t>Up to this step, this work introduces no change to IKEv2.</t>
      </section>

      <section anchor="IKE_AUTH" title="IKE_AUTH ">
        <t>Next, the network devices perform an IKE_AUTH exchange defined in
        <xref target="RFC7296">IKEv2</xref>. The SA payloads contain the
        security policies for a key and the associated parameters (as defined
        in <xref target="PAYLOAD-FORMATS">Header and Payload Formats</xref>),
        and the TS payloads contains traffic selectors as defined in <xref
        target="RFC7296">IKEv2</xref>. For the details of the exchange please
        refer to IKE_AUTH in <xref target="RFC7296">IKEv2</xref>.</t>

        <t><figure align="center" title="IKE_AUTH">
            <artwork><![CDATA[Peer (Initiator)                         Peer (Responder)
--------------------                     ------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr}     -->
                                 <--     HDR, SK {IDr, [CERT,] AUTH,
                                         SAr2, TSi, TSr}

]]></artwork>
          </figure>In the IKE_AUTH exchange, the Initiator proposes one or
        more sets of policies for the key used for securing a routing protocol
        in the SAi2. The SA payload indicates that the supported policies
        associated with the key are being proposed. The Responder returns the
        one policy contained in SAr2 that it accepts. Based on this policy,
        appropriate keying material is derived from the existing shared keying
        material. At the successful conclusion of the IKE_AUTH exchange, the
        initiator and responder have agreed upon a single set of policy and
        keying material for a particular routing protocol.</t>
      </section>

      <section anchor="CREATE_CHILD_SA" title="CREATE_CHILD_SA">
        <t>The network devices may then destroy the state associated with the
        IKEv2 SA, continuing to use the RP policy and keying material, or they
        may choose to retain them for further usages. Note that this policy
        differs from IKEv2/IPsec, where the deletion of the IKEv2 SA
        necessitates the deletion of the IPsec SAs. If both the network
        devices choose to retain them, they may use the IKEv2 SA to
        subsequently agree upon replacement policy for the same RP, or agree
        upon the policy and keying material for another routing protocol.
        Either case will require the use of the IKEv2 CREATE_CHILD_SA exchange
        as defined in <xref target="RFC7296">IKEv2</xref>.</t>

        <t>A CREATE_CHILD_SA exchange therefore can be triggered in order
        to</t>

        <t><list style="numbers">
            <t>Rekey an antique RP master key and establish a new equivalent
            one,</t>

            <t>Generate needed keying material for a newly executed routing
            protocol based on an existing SA, or</t>

            <t>Rekey an IKEv2 SA and establish a new equivalent IKEv2 SA.</t>
          </list></t>

        <t><figure align="center" title="CREATE_CHILD_SA">
            <artwork><![CDATA[Peer (Initiator)                      Peer (Responder)
--------------------                  ------------------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]}                   -->   
                              <--    HDR, SK {SA, Nr, [KEr],
                                     [TSi, TSr]}
]]></artwork>
          </figure></t>

        <t>A CREATE_CHILD_SA exchange MAY be initiated by either end of the SA
        after the initial exchanges are completed. All messages in a
        CREATE_CHILD_SA exchange are cryptographically protected using the
        cryptographic algorithms and keys negotiated in the initial
        exchange.</t>

        <t>For details on the exchange, refer to the CREATE_CHILD_SA exchange
        as defined in <xref target="RFC7296">IKEv2</xref>.</t>
      </section>

      <section title="INFORMATIONAL">
        <t>The IKEv2 INFORMATIONAL exchange is also useful for deleting
        specific IKEv2 SAs or sending status information. The Notify (N) and
        Delete (D) payloads are as those defined by <xref
        target="IKEV2-PARAMS">IKEv2</xref>. For example, if the Responder
        refused to accept one of Proposals sent by the Initiator, it would
        return an INFORMATIONAL exchange of type NO_PROPOSAL_CHOSEN instead of
        the response to CREATE_CHILD_SA.<figure align="center"
            title="INFORMATIONAL">
            <artwork><![CDATA[Peer (Initiator)                   Peer (Responder)
-------------------                ------------------
HDR, SK {[N,] [D,] ... }    -->
                            <--    HDR, SK {[N,] [D,] ... }]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Operation Details">
      <section title="General">
        <t>IKEv2 is used to dynamically derive keying material information
        between the two network devices trying to establish or maintain a
        routing protocol neighbor adjacency. Typically network devices running
        the routing protocols establish neighbor adjacencies at the routing
        protocol level. These routing protocols may run different security
        algorithms that provide transport level security for the protocol
        neighbor adjacencies. Depending on the security algorithm used, the
        routing protocols are configured with security algorithm specific keys
        that are either long term keys or short term session keys. These keys
        are specific to the security algorithms used to enforce transport
        level security for the routing protocols.</t>

        <t>A routing protocol causes IKEv2 to execute when it needs keying
        material to establish neighbor adjacency. This can be as a result of
        the routing protocol neighbor being configured, neighbor changed or
        updated, a local rekey policy decision, or some other event dictated
        by the implementation. The keying material would allow the network
        devices to then independently generate the same key and establish an
        IKEv2 session between them. This is typically done by the Initiator
        (IKEv2 speaker) initiating an IKEv2 IKE_SA_INIT exchange mentioned in
        the section 2.1 towards its IKEv2 peer. As part of IKEv2_INIT
        exchange, IKEv2 will send a message to the peer's IKEv2 port. The
        format of the message is explained in <xref
        target="PAYLOAD-FORMATS"/>. The procedure to exchange key information
        is explained in <xref target="PAYLOAD-FORMATS"/>. Once the keying
        material information is successfully exchanged by both of the IKEv2
        speakers, the IKEv2 neighbor adjacency may be torn down or kept around
        as explained in <xref target="PAYLOAD-FORMATS"/>.</t>

        <t>The master key data received from IKEv2 peers is stored in the
        separate Key Management Database known as KMDB. KMDB follows the
        guidelines in <xref target="RFC7210">Database of Long Lived Symmetric
        Cryptographic Keys </xref>, and each entry consists of Key specific
        information, Security algorithm to which the Key is applicable to,
        Routing Protocol Clients of interest, and the announcing KMP Peer.
        KMDB is also used to notify the routing protocols about the key
        updates. Typically keying material information is exchanged whenever a
        routing protocol is about to create a new neighbor adjacency. This is
        considered as an Initial Key exchange mode. Keying material
        information is also exchanged to refresh existing key data on an
        already existing neighbor adjacency. This is considered as Key
        rollover exchange mode. The following sections describes their detail
        behavior.</t>
      </section>

      <section title="Initial Key Specific Data Exchange">
        <t>Routing protocols informs IKEv2 of its new neighbor adjacency. It
        does so by creating a local entry in KMDB which consists of a Security
        algorithm, Key specific information, routing protocol client and the
        routing protocol neighbor. Upon a successful creation of such an entry
        IKEv2 initiates KMP peering with the neighbor and starts an initial
        IKE_SA_INIT exchange explained in <xref target="IKE_SA_INIT"/>
        followed by the RP_AUTH exchanged explained in <xref
        target="IKE_AUTH"/>. Once the key related information is successfully
        exchanged, KMDB may invoke the routing protocol client to provide key
        specific information updates if any.</t>
      </section>

      <section title="Key Selection, Rollover and Protocol Interaction">
        <t>A routing protocol may need to perform the key selection and
        rollover in cooperation with KMDB. Such a procedure is described in
        Section 3 of <xref target="RFC7210">Database of Long-Lived Symmetric
        Cryptographic Keys </xref>. Details of how RP interact with KMDB and
        deals with multiple keys during rollover are also described in that
        section. When a routing protocol uses TCP-AO to secure its message
        exchanges, conditions could be a little more complex. Typically, a
        TCP-AO implementation has its own key tables. TCP-AO may only carry
        out key management operations on the key tables if the key information
        maintained in KDMB needs not to be updated. In <xref
        target="I-D.chunduri-karp-using-ikev2-with-tcp-ao"/>, a Gatekeeper
        (GK) mechanism is provided to orchestrate the key management
        operations on the TCP-AO key tables and KMDB.</t>
      </section>
    </section>

    <section title="Key Management Database">
      <t>Protocol interaction between KMP and its client routing protocols is
      typically done using KMDB. Routing protocols may be able to update KMDB
      by performing key selection and rollover operations. During a key
      selection, if there is no appropriate key found in the conceptual
      database, as a part of the KMDB update, IKEv2 is initiated to connect
      with its appropriate IKEv2 peer so as to generate a new key. When a key
      needs to be revoked, it is also the responsibility of IKEv2 to inform
      its peer to guarantee the synchronization of the databases on the both
      sides. In addition, when a key is obsoleted for some reasons when it is
      being used by a client routing protocol, the routing protocol may need
      to be informed of this update. For the routing protocols which using
      TCP-AO to secure their message exchanges, a Gatekeeper mechanism is
      provided to trigger the update of keys and manage the key revocation
      <xref target="I-D.chunduri-karp-using-ikev2-with-tcp-ao"/>.</t>
    </section>

    <section anchor="PAYLOAD-FORMATS" title="Header and Payload Formats">
      <t>The protocol defined in this memo uses IKEv2 payload definitions.
      However, new security policy definitions are described to support
      security transforms and policy defined by routing protocol
      documents.</t>

      <section title="Header and Payload Formats for TCP-AO">
        <t/>

        <section title="Security Association Payload for TCP-AO">
          <t>The <xref target="RFC5925">TCP Authentication Option (TCP-AO)
          </xref> is primarily intended for BGP and other TCP-based routing
          protocols. In order for IKEv2 to negotiate TCP-AO policy, a new
          Security Protocol Identifier needs to be defined in the IANA
          registry for "IKEv2 Security Protocol Identifiers" <xref
          target="IKEV2-PROTOCOL-IDS">Magic Numbers' for ISAKMP
          Protocol</xref>. This memo proposes adding a new Protocol Identifier
          to the table, with a Protocol Name of "TCP_AO" and a value of 6.</t>

          <t>The Security Association (SA) payload contains a list of
          Proposals, which describe one or more sets of policies that a
          network device is willing to use to protect a routing protocol. In
          the Initiator's message, the SAi2 payload contains a list of
          Proposal payloads (as defined in the next sections), each of which
          contains a single set of policy that can be applied to the packets
          described in the Traffic Selector (TS) payloads in the same
          exchange. Each set of policy is given a particular "Proposal Number"
          uniquely identifying this set of policy.</t>

          <t>The responder includes a single Proposal payload in it's SA
          policy, which denotes the choice it has made amongst the initiator's
          list of Proposals. Any attributes of a selected transform MUST be
          returned unmodified as explained in <xref
          target="RFC7296">IKEv2</xref> section 3.3.6. The initiator of an
          exchange MUST check that the accepted offer is consistent with one
          of its proposals, and if not MUST terminate the exchange.</t>

          <section title="Transforms Substructures for TCP-AO">
            <t>Each Proposal has a list of Transform (T) substructures, each
            of which describe a particular set of cryptographic policy
            choices. A TCP-AO proposal uses the INTEG transform to negotiate
            the MKT Message Authentication Code (MAC) algorithm. <xref
            target="RFC5926">Cryptographic Algorithms for TCP-AO </xref>
            describes HMAC-SHA-1-96, AES-128-CMAC-96, which map to the
            existing INTEG transform IDs of AUTH_HMAC_SHA1_96 and
            AUTH_AES_CMAC_96 respectively. The use of each INTEG algorithm
            implies the use of a specific KDF (deriving session keys from a
            master key), and so the choice of a particular INTEG transform ID
            also specifies the required KDF transform. This will be true for
            every transform ID used with TCP-AO, as required in RFC 5926 (see
            Section 3.2 where the "KDF_Alg" is a fixed element of a MAC
            algorithm definition for TCP-AO).</t>

            <t>A TCP-AO proposal also requires a new type of transform, which
            describes whether TCP options are to be protected by the integrity
            algorithm. This memo proposes adding a new Transform Type in the
            IANA registry for "Transform Type Values" <xref
            target="IKEV2-TRANSFORM-TYPES"/><figure align="center"
                anchor="TCP-AO-TRANSFORMS"
                title="Transform Type 6 - TCP Authentication Option Transform IDs">
                <artwork><![CDATA[+-------+---------------------------------+
|Number |            Name                 |
+-------+---------------------------------+
|  0    |Options Not Integrity Protected  |
|  1    |Options Integrity Protected      |
+-------+---------------------------------]]></artwork>
              </figure>The TCP-AO KeyID is sent in the SPI field of an IKEv2
            proposal. A KeyID for TCP-AO has the same purpose as an IPsec SPI
            value, so it is natural to place it in this portion of the
            proposal. If the KeyID values in a responder's Proposal does not
            mach the KeyID values initiator's Proposal, then they have chosen
            to use different KeyID values to represent the same master key and
            associated proposal policy. This is consistent with how IPsec uses
            the SPI value, and the semantic of initiator and responder using
            different SendIDs is supported by RFC 5925.</t>

            <t>The following table shows the Transforms that can be negotiated
            for a TCP-AO protocol.</t>

            <t><figure align="center" anchor="TCPAO-TRANSFORMS"
                title="Mandatory and Optional Transforms for TCP-AO">
                <artwork><![CDATA[Protocol    Mandatory Types          Optional Types
---------------------------------------------------
TCP-AO      INTEG, TCP               D-H]]></artwork>
              </figure></t>
          </section>

          <section title="Example Proposal Exchange">
            <t><xref target="TCP-EXAMPLE"/> shows an example of IKEv2 SA
            Payload including a single Proposal sent in the first message of
            an IKE_AUTH or CREATE_CHILD_SA exchange. It indicates a
            willingness to use either of the two MAC algorithms defined in RFC
            5926, and is willing to either protect TCP options or not. The SPI
            value represents the new SendID it is associating with the TCP-AO
            Master Key Tuple (MKT) policy being negotiated.</t>

            <t><figure anchor="TCP-EXAMPLE"
                title="Example Initiator SA Payload for TCP-AO">
                <artwork align="center"><![CDATA[   SA Payload
      |
      +--- Proposal #1 ( Proto ID = TCP-AO(T6), SPI size = 1,
            |            4 transforms,      SPI = 0x01 )
            |
            +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
            +-- Transform INTEG ( Name = AUTH_AES_CMAC_96 )
            +-- Transform TCP ( Name = PROTECT_OPTIONS )
            +-- Transform TCP ( Name = NO_PROTECT_OPTIONS )]]></artwork>
              </figure>The responder will record the SPI value to be the
            RecvID of the MKT. It chooses its own SendID value, one of each
            Transform type, and returns this policy in the response message.
            For example, if the responder chose HMAC-SHA-1-96 and chose to
            protect the TCP options, the corresponding SA payload would
            be:</t>

            <t><figure anchor="TCP-EXAMPLE2"
                title="Example Responder SA Payload for TCP-AO">
                <artwork align="center"><![CDATA[   SA Payload
      |
      +--- Proposal #1 ( Proto ID = TCP-AO(6), SPI size = 1,
            |            2 transforms,      SPI = 0x11 )
            |
            +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
            +-- Transform TCP ( Name = PROTECT_OPTIONS )
]]></artwork>
              </figure>In this example, the Proposal responder chose to use a
            different SPI value (0x11) as its SendID. This is possible because
            Section 2.2 of <xref target="RFC5925"/> declares that "KeyID
            values MAY be the same in both directions of a connection, but do
            not have to be and there is no special meaning when they are."</t>
          </section>
        </section>

        <section title="Derivation of TCP-AO Keying Material">
          <t>Each TCP-AO MAC algorithm specification in Section 3.2 of <xref
          target="RFC5926">Crypto for TCP-AO </xref> defines the Key_Length as
          a number of bits &lt;n&gt; needed as keying material for the MAC
          algorithm.</t>
        </section>
      </section>

      <section title="Security Association Payload for BFD">
        <t>In order for IKEv2 to negotiate BFD authentication policy, a new
        Security Protocol Identifier needs to be defined in the IANA registry
        for "IKEv2 Security Protocol Identifiers" <xref
        target="IKEV2-PROTOCOL-IDS">Magic Numbers' for ISAKMP Protocol</xref>.
        This memo proposes adding a new Protocol Identifier to the table, with
        a Protocol Name of "BFD" and a value of 7.</t>

        <section title="Transforms Substructures for BFD Authentication">
          <t><xref target="RFC5880">The base BFD specification</xref> defines
          five authentication mechanisms: Password, Keyed MD5, Meticulous
          Keyed MD5, Keyed SHA1, and Meticulous Keyed SHA1. Because Password
          does not use keys, the support of this mechanism is out of the scope
          of this work. In the other four mechanisms, Keyed MD5 and Meticulous
          Keyed MD5 use MD5 as the Message Authentication Code (MAC)
          algorithm, while Keyed SHA1 and Meticulous Keyed SHA1 use SHA1. In
          <xref target="I-D.ietf-bfd-generic-crypto-auth"/>, a generic
          authentication mechanism and a generic meticulous authentication
          mechanism which can support various MAC algorithms is proposed.</t>

          <t>Therefore, a BFD proposal also requires a new type of transform
          to identify the type of BFD authentication. This memo proposes
          adding a new Transform Type in the IANA registry for "Transform Type
          Values"<xref target="IKEV2-TRANSFORM-TYPES"/></t>

          <t><figure align="center" anchor="BFD-TRANSFORM"
              title="Transform Type 7 - BFD Authentication Option Transform IDs">
              <artwork><![CDATA[+-------+---------------------------------+
|Number |            Name                 |
+-------+---------------------------------+
|  0    |Base Authentication              |
|  1    |Base Meticulous Authentication   |
|  2    |Generic Authentication           |
|  3    |Generic Meticulous Authentication|
+-------+---------------------------------+]]></artwork>
            </figure></t>

          <t>Base Authentication in <xref target="BFD-TRANSFORM"/> indicates
          the keyed (MD5 or SHA-1) authentication mechanism defined in <xref
          target="RFC5880">the base BFD specification</xref>. Base Meticulous
          Authentication indicates the meticulous keyed (MD5 or SHA-1)
          authentication mechanism defined in the base BFD specification.
          Generic Authentication and Generic Meticulous Authentication
          indicate the generic keyed authentication and the generic keyed
          meticulous authentication mechanisms defined in <xref
          target="I-D.ietf-bfd-generic-crypto-auth"/> respectively.</t>

          <t>A BFD proposal uses INTEG transforms to negotiate Message
          Authentication Code (MAC) algorithms. In the base BFD <xref
          target="RFC5880"/>, keyed MD5 and keyed SHA-1 are adopted. The two
          algorithms can be identified using existing INTEG transform IDs of
          AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 respectively. In <xref
          target="I-D.ietf-bfd-hmac-sha"/>, it is specified that a BFD using
          the authentication mechanisms defined in <xref
          target="I-D.ietf-bfd-generic-crypto-auth"/> MUST support
          HMAC-SHA-256 which can be identified using existing INTEG transform
          IDs of AUTH_HMAC_SHA2_256_128 <xref target="RFC4868"/>.</t>

          <t>The BFD KeyID is sent in the SPI field of an IKEv2 proposal. Note
          that according to <xref target="RFC5880"/>, the length of KeyID is 8
          bits.</t>

          <t>Because in BFD the transport key is the same as the protocol
          master key, no KDF needs to be negotiated.</t>

          <t>The following figure shows the Transforms that can be negotiated
          for a BFD implementation.</t>

          <t><figure align="center" anchor="BFD-TRANSFORMs"
              title="Mandatory and Optional Transforms for BFD">
              <artwork><![CDATA[Protocol    Mandatory Types          Optional Types
---------------------------------------------------
BFD         BFD, INTEG                 D-H]]></artwork>
            </figure></t>
        </section>
      </section>

      <section title="Security Association Payload for RSVP-TE">
        <t>In order for IKEv2 to negotiate RSVP-TE authentication policy, a
        new Security Protocol Identifier needs to be defined in the IANA
        registry for "IKEv2 Security Protocol Identifiers" <xref
        target="IKEV2-PROTOCOL-IDS">Magic Numbers' for ISAKMP Protocol</xref>.
        This memo proposes adding a new Protocol Identifier to the table, with
        a Protocol Name of "RSVP-TE" and a value of 8.</t>

        <section title="Transforms Substructures for RSVP-TE Authentication">
          <t>In the authentication mechanism for RSVP-TE <xref
          target="RFC2747"/>, only HMAC-MD5 is mandated. Therefore, no INTG
          transform needs to be included in a RSVP-TE proposal.</t>

          <t>A RSVP-TE proposal requires a new type of transform, which
          indicates whether the integrity handshake (which is used to collect
          the latest sequence number associated with a key ID) is permitted.
          This memo proposes adding a new Transform Type in the IANA registry
          for "Transform Type Values" <xref
          target="IKEV2-TRANSFORM-TYPES"/><figure align="center"
              anchor="RSVP-TE-TRANSFORM"
              title="Transform Type 8 - RSVP-TE Transform IDs">
              <artwork><![CDATA[+-------+---------------------------------+
|Number |            Name                 |
+-------+---------------------------------+
|  0    |Not Allowed                      |
|  1    |Allowed                          |
+-------+---------------------------------+
]]></artwork>
            </figure></t>

          <t>The RSVP-TE KeyID is sent in the SPI field of an IKEv2
          proposal.</t>

          <t>The following figure shows the Transforms that can be negotiated
          for a RSVP-TE implementation.</t>

          <t><figure align="center" anchor="RSVP-TE-TRANSFORMS"
              title="Mandatory and Optional Transforms for BFD">
              <artwork><![CDATA[Protocol    Mandatory Types          Optional Types
---------------------------------------------------
RSVP-TE     RSVP-TE,               D-H]]></artwork>
            </figure></t>
        </section>
      </section>

      <section title="Notify and Delete Payloads">
        <t>A Notify Payload (<xref target="RFC7296">IKEv2 </xref> Section
        3.10) or Delete Payload (<xref target="RFC7296"> IKEv2 </xref> Section
        3.11) contains a Protocol ID field. The Protocol ID is set to TCP_AO
        (6) when a notify message is relevant to the TCP-AO KeyID value
        contained in the SPI field. Similarly, the Protocol ID is set to BFD
        (7) when a notify message is relevant to the BFD KeyID value contained
        in the SPI field, and the Protocol ID is set to RSVP-TE (8) when a
        notify message is relevant to the RSVP-TE KeyID value contained in the
        SPI field.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>In order for IKEv2 to negotiate TCP-AO authentication policies, a new
      Security Protocol Identifier needs to be defined in the IANA registry
      for "IKEv2 Security Protocol Identifiers" <xref
      target="IKEV2-PROTOCOL-IDS">Magic Numbers' for ISAKMP Protocol</xref>.
      IANA is requested to add a new Protocol Identifier to the table, with a
      Protocol Name of "TCP-AO" and a value of 6. A TCP-AO proposal also
      requires a new type of transform, which describes whether TCP options
      are to be protected by the integrity algorithm. This memo proposes
      adding a new Transform Type 6 for this transform in the IANA registry
      for "Transform Type Values".</t>

      <t>In order for IKEv2 to negotiate BFD authentication policies, a new
      Security Protocol Identifier needs to be defined in the IANA registry
      for "IKEv2 Security Protocol Identifiers" <xref
      target="IKEV2-PROTOCOL-IDS">Magic Numbers' for ISAKMP Protocol</xref>.
      IANA is requested to add a new Protocol Identifier to the table, with a
      Protocol Name of "BFD" and a value of 7. A BFD proposal also requires a
      new type of transform, which identifies the type of BFD authentication
      mechanism. This memo proposes adding a new Transform Type 7 in the IANA
      registry for "Transform Type Values".</t>

      <t>In order for IKEv2 to negotiate RSVP-TE authentication policies, a
      new Security Protocol Identifier needs to be defined in the IANA
      registry for "IKEv2 Security Protocol Identifiers" <xref
      target="IKEV2-PROTOCOL-IDS">Magic Numbers' for ISAKMP Protocol</xref>.
      IANA is requested to add a new Protocol Identifier to the table, with a
      Protocol Name of "RSVP-TE" and a value of 8. A RSVP-TE proposal requires
      a new type of transform, which indicates whether the integrity handshake
      (which is used to collect the latest sequence number associated with a
      key ID) is permitted. This memo proposes adding a new Transform Type 8
      in the IANA registry for "Transform Type Values".</t>

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>During the development of TCP-AO, Gregory Lebovitz noted that a
      protocol based on an IKEv2 exchange would be a good automated key
      management method for deriving a TCP-AO master key.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>

      <?rfc include='reference.RFC.2747'?>

      <?rfc include='reference.RFC.4868'?>

      <?rfc include='reference.RFC.5880'?>

      <?rfc include='reference.RFC.5925'?>

      <?rfc include='reference.RFC.5926'?>

      <?rfc include='reference.RFC.7296'?>
    </references>

    <references title="Informative References">
      <reference anchor="IKEV2-PARAMS"
                 target="http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml">
        <front>
          <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>

          <author fullname="Internet Assigned Numbers Authority">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="DH">
        <front>
          <title>New Directions in Cryptography</title>

          <author fullname="Whitfield Diffie" initials="W.D." surname="Diffie">
            <organization>D</organization>
          </author>

          <author fullname="Martin Hellman" initials="M.H." surname="Hellman">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <date month="June" year="1977"/>
        </front>

        <seriesInfo name="IEEE Transactions on Information Theory,"
                    value="V.IT-22 n. 6"/>
      </reference>

      <?rfc include='reference.RFC.6952'?>

      <?rfc include='reference.RFC.7210'?>

      <?rfc include='reference.I-D.ietf-bfd-generic-crypto-auth'?>

      <?rfc include='reference.I-D.ietf-bfd-hmac-sha'?>

      <?rfc include='reference.I-D.chunduri-karp-using-ikev2-with-tcp-ao'?>

      <reference anchor="IKEV2-PROTOCOL-IDS"
                 target="http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-18">
        <front>
          <title>'Magic Numbers' for ISAKMP Protocol</title>

          <author fullname="" surname="">
            <organization/>
          </author>

          <date month="" year=""/>
        </front>
      </reference>

      <reference anchor="IKEV2-TRANSFORM-TYPES"
                 target="http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-3">
        <front>
          <title>'Magic Numbers' for ISAKMP Protocol</title>

          <author fullname="" surname="">
            <organization/>
          </author>

          <date month="" year=""/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
