One document matched: draft-mahesh-karp-rkmp-01.xml
<?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-01" ipr="trust200902">
<front>
<title abbrev="RKMP">Key Management for Pairwise Routing Protocol</title>
<author fullname="Mahesh Jethanandani" initials="M.J."
surname="Jethanandani">
<organization>Independent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>mjethanandani@gmail.com</email>
<uri></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></facsimile>
<email>bew@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Keyur Patel" initials="K.P." surname="Patel">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (408) 526-7183</phone>
<facsimile></facsimile>
<email>keyupate@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Dacheng Zhang" initials="D.Z." surname="Zhang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>zhangdacheng@huawei.com</email>
<uri></uri>
</address>
</author>
<author fullname="Sam Hartman" initials="S.H." surname="Hartman">
<organization>Painless Security</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>hartmans@painless-security.com</email>
<uri></uri>
</address>
</author>
<date day="08" month="March" year="2012" />
<abstract>
<t>When running routing protocols such as BGP or RSVP-TE, two routers
need to exchange routing messages in a unicast (one-to-one) fashion. In
order to authenticate these messages using symmetric cryptography, a
secret key needs to be established. This document defines a Router Key
Management Protocol for establishing and managing such keys for routing
protocols.</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 communication model (e.g.,
BGP, LDP, RSVP-TE) have cryptographic authentication mechanisms that use
a key shared between the routers on the both sides of the model to
protect routing message exchanges between the routers. Unicast key
management today is limited to statically configuring master keys in
individual routers. This document defines a Router Key Management
Protocol (RKMP) that largely makes use of currently defined IKEv2 <xref
target="RFC5996"></xref> protocol and extends it to allow network
devices to automatically exchange key material related information
between the network devices.</t>
<t>RKMP assumes that routers need to be provisioned with some
credentials for a one-to-one authentication protocol. Pre-shared keys or
asymmetric keys and an authorization list are expected to be common
deployments.</t>
<t>If two routers running a routing protocol have not authenticated each
other yet, and before sending out any routing protocol packets the two
routers need to perform mutual authentication using their provisioned
credentials. If successful, two routers negotiate the key material to
secure the routing protocol execution.</t>
<section title="Terminology">
<t>Here are some terms that we will be using throughout the
document.</t>
<t>SKEYSEED: When a TCP-AO transform is chosen, keying material for
the TCP-AO master key is generated as follows, where Ni and Nr are
unique to this exchange. The value SK_d is defined in Section 1.2 of
<xref target="RFC5996"> IKEv2 </xref>, and refers to the value derived
from SKEYSEED (defined in Section 2.14 of <xref target="RFC5996">
IKEv2 </xref>). SK_d is used to derive new keys (e.g., for TCP-AO) as
follows:</t>
<t><TCP-AO master key> = prf+(SK_d, Ni | Nr)</t>
</section>
<section title="Acronyms and Abbreviations">
<t>The following acronyms and abbreviations are used throughout this
document.</t>
<t><list counter="" hangIndent="6" style="hanging">
<t hangText="IKE">Internet Key Exchange Protocol</t>
<t hangText="IKEv2">Internet Key Exchange Protocol Version 2</t>
<t hangText="RP">Routing Protocol</t>
<t hangText="SA">Security Association</t>
</list></t>
</section>
</section>
<section title="Overview">
<t><figure align="center" anchor="state-machine" title="State Diagram">
<preamble></preamble>
<artwork><![CDATA[
-----------------------
=======> | Not Authenticated |==========
|| | No RP Keys | ||
|| ----------------------- IKE_SA_INIT
|| ||
|| ||
|| ||
INFORMATIONAL VV
|| --------------------------
|| | Privacy Keys Exchanged |
|| | No RP Keys |
|| --------------------------
|| ||
|| |-------------------- IKE_AUTH
=========| Authenticated | <============
| RP Keys Derived | ====
-------------------- ||
^^ ||
|| CREATE_CHILD_SA
|| ||
=============== ]]></artwork>
</figure></t>
<section title="Types of Keys">
<t>The keys adopted in RKMP are listed as follows:</t>
<t><list style="symbols">
<t>PSK (Pre-Shared Key) : PSKs are pair-wise unique keys used for
authenticating one router to the other one during the initial
exchange. These keys are configured by some mechanism such as
manual configuration or a management application outside of the
scope of RKMP.</t>
<t>Seed key: Refers to value derived from SKEYSEED that is used to
derive new keys (e.g., for TCP-AO).</t>
<t>Protocol master key: A protocol master key is the key exported
by RKMP for use by a routing protocol such as BGP. This is the key
that is shared in the key table between the routing protocol and
RKMP.</t>
<t>Transport key: A transport key is the key used to integrity
protect routing messages in a protocol such as BGP. In today's
routing protocol cryptographic authentication mechanisms the
transport key can be the same as the protocol master key.</t>
</list></t>
</section>
</section>
<section title="Protocol Exchanges">
<t>The exchange of private keying material between two network devices
using a dedicated key management protocol is a requirement as
articulated in <xref
target="I-D.ietf-karp-routing-tcp-analysis"></xref>. 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>In the following figures, the notations contained in the 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></t>
<section title="IKE_SA_INIT">
<t>The IKE_SA_INIT exchange defined in <xref target="RFC5996">Internet
Key Exchange Protocol Version 2 </xref> is used in RKMP. The
IKE_SA_INIT exchange is a two-message exchange that allows the network
devices to negotiate cryptographic algorithms, exchange nonces, and do
a <xref target="DH"> Diffe-Hellman (DH) </xref> exchange, for their
routing protocols, after which protocols on these network devices can
communicate privately. Note that at this point the network devices
have not identified their peer. For the details of this exchange,
refer to IKE_SA_INIT in <xref target="RFC5996">Internet Key Exchange
Protocol Version 2 </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>
</section>
<section title="IKE_AUTH ">
<t>Next, the network devices perform an IKE_AUTH exchange defined in
RFC 5996. However, the SA payloads contain the routing protocol
specific security policies rather than IPsec policies (SAi2, SAr2
defined in RFC 5996), and the TS payloads contains routing protocol
specific traffic selectors. Policy definitions for routing protocols
is described in Section 3; for the details of the rest of the exchange
please refer to IKE_AUTH in RFC 5996.</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 one routing protocol in the SAi2. 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 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 the further use. 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 policy and keying material for another routing protocol. Either
case will require the use of the IKEv2 CREATE_CHILD_SA exchange as
defined in RFC 5996.</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 key material for a newly executed routing
protocol based on an existing SA</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 RFC 5996.</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="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="Security Association Payload">
<t>The Security Association (SA) payload contains a list of Proposals,
which describe one or more sets of policy that a router 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 section), each of which contains a single set of policy that can
b 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="RFC5996">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>
<t>This memo defines new Proposal substructure definitions, which
allow protocol participants to exchange proposals for routing protocol
policy. <xref target="protocol-ids"></xref> defines new Protocol IDs
that can be negotiated within an IKEv2 SA payload.<figure
align="center" anchor="protocol-ids" title="Protocol IDs">
<preamble></preamble>
<artwork><![CDATA[Protocol Protocol ID Reference
----------------------------------------------
TCP-AO TBD-1 RFC 5925
LDP Discovery Key TBD-2
]]></artwork>
<postamble></postamble>
</figure></t>
<t>The following section describes the SA Payload Transforms
Substructures that are to be used with these Protocol IDs.</t>
<section title="Transforms Substructures">
<t>Each Proposal has a list of Transform (T) substructures, each of
which describe a particular set of cryptographic policy choices.
This is useful for an initiator to propose multiple cryptographic
choices for the same policy described in its associated Proposal
payload.</t>
<section title="TCP-AO">
<t>The <xref target="RFC5925">TCP-AO</xref> transform payload is
specified to negotiate the TCP-AO policies and contains the
following fields.</t>
<t><figure align="center" anchor="tcp-ao-trans"
title="TCP-AO Transforms">
<artwork><![CDATA[ 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SendID |Auth Alg | KDF | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>o 0 (last) or 3 (more) (1 octet) - Specifies whether this is
the last Transform Substructure in the Proposal.</t>
<t>o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
receipt.</t>
<t>o Transform Length (2 octets) - The length (in octets) of the
Transform Substructure including Header and Attributes.</t>
<t>o SendID (1 octet) - The TCP-AO KeyID that the sender will use
to represent this Transform. The KeyID will be used to generate
the keys independently on each network device at the end of the
exchange.</t>
<t>o Auth Alg (1 octet) - The Authentication algorithm defined as
a part of this Transform. Initial values are defined in <xref
target="RFC5926">Cryptographic Algorithms for the TCP
Authentication Option</xref>. Parenthetical names in <xref
target="tcp-ao-algs"></xref> refer to the values assigned in the
Cryptographic Algorithms for TCP-AO Registration <xref
target="TCP-AO-REG"></xref>.</t>
<figure align="center" anchor="tcp-ao-algs"
title="TCP-AO Authentication Algorithm">
<preamble></preamble>
<artwork><![CDATA[Auth Alg ID
------------------------------
Reserved 0
HMAC-SHA-1-96 (SHA1) 1
AES-128-CMAC-96 (AES128) 2
Standards Action 3-140
Private Use 241-255]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>o KDF (1 octet) - The KDF defined as a part of this Transform.
Values are defined in <xref target="RFC5926">Cryptographic
Algorithms for the TCP Authentication Option</xref>.</t>
<figure align="center" anchor="tcp-ao-kdf"
title="TCP-AO Key Derivation Functions">
<preamble></preamble>
<artwork><![CDATA[KDF ID
------------------------------
Reserved 0
KDF_HMAC_SHA1 1
KDF_AES_128_CMAC 2
Standards Action 3-240
Private Use 241-255]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>o Flags (1 octet) - Indicates specific options for TCP-AO. The
bits are as follows:</t>
<figure align="center">
<preamble></preamble>
<artwork><![CDATA[+-+-+-+-+-+-+-+-+
|O|X|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>In the description below, a bit being 'set' means its value is
'1', while 'cleared' means its value is '0'. 'X' bits MUST be
cleared when sending and MUST be ignored on receipt.</t>
<t><list style="symbols">
<t>O (Options) - This bit indicates whether or not TCP Options
are to be included in the bytes protected by the
authentication calculation. This bit is set to indicate that
TCP Options are to be ignored and cleared to indicate that TCP
Options are protected.</t>
</list></t>
<t>When a TCP-AO transform is chosen, keying material for the
TCP-AO master key is generated as follows, where Ni and Nr are
unique to this exchange. The value SK_D is defined in RFC 5996,
and refers to the value derived from SKEYSEED that is used to
derive new keys (e.g., for TCP-AO).</t>
<t><figure align="center">
<artwork><![CDATA[<TCP-AO master key> = prf+(SK_d, Ni | Nr)]]></artwork>
</figure></t>
</section>
<section title="LDP Discovery Key">
<t>TBD</t>
</section>
</section>
</section>
<section title="Traffic Selector Payload">
<t>The Traffic Selector (TS) payload allows an RP peer to identify
packet flows that are to be protected with the policy in the SA
payload. Unlike IPsec, routing protocols have well-defined flows, and
there is no need to specify them to the specificity of IPsec policy.
The document defines a new TS type for routing protocols as shown in
<xref target="ts-payload"></xref>. The TS payload defined in this
document includes only the routing protocol identifier that is to be
protected.</t>
<t><figure anchor="ts-payload">
<artwork align="center"
name="Traffic Selector for Routing Protocol"><![CDATA[ 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type | Rtg. Prot. ID | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>o TS Type (1 octet) - TBD-3 for all routing protocols</t>
<t>o Rtg. Prot. ID (1 octet) - Specifies the routing protocol
identifier for the current negotiation.</t>
<t><figure align="center" anchor="rtg-prot-IDs"
title="Routing Protocol IDs">
<preamble></preamble>
<artwork><![CDATA[Routing (RT) Protocol Protocol ID Reference
-----------------------------------------------
Reserved 0
BGP 1 RFC 4271
LDP 2 RFC 5036
MSDP 3 RFC 3618
PIM PORT 4
PCEP 5 RFC 5440
Unassigned 6-240
Private Use 240-255
]]></artwork>
</figure>Exchanges including traffic selectors (i.e., IKE_AUTH,
CREATE_CHILD_SA) include two TS payloads, one for the initiator policy
and one for the responder policy. In the case of RPs the policy is
symmetric and both payloads contain the same routing protocol ID
value.</t>
</section>
</section>
<section title="Operation Details">
<section title="General">
<t>RKMP is used to dynamically derive key 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 RKMP to execute when it needs key
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 key material would allow the network
devices to then independently generate the same key and establish a
RKMP neighbor adjacency between them. This is typically done by the
Initiator (RKMP speaker) initiating a RKMP RP_INIT exchange mentioned
in the section 2.1 towards its RKMP peer. As part of RP_INIT exchange,
RKMP will send a message to the RKMP peer's IKEv2 port. The format of
the message is explained in section 3. The procedure to exchange key
information is explained in section 3. Once the key material
information is successfully exchanged by both the RKMP speaker, the
RKMP neighbor adjacency may be torn down or kept around as explained
in section 3.</t>
<t>The master key data received from RKMP peers are stored in the
separate Key Management Database known as KMDB. KMDB follows the
guidelines in<xref target="I-D.ietf-karp-crypto-key-table"> 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 RKMP Peer. KMDB is also used to notify the routing
protocols about the key updates. Typically key 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. Key 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 RKMP 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
RKMP initiates RKMP peering with the neighbor and starts initial RKMP
RP_INIT exchange explained in section 2.1 followed by the RP_AUTH
exchanged explained in section 2.2. 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>The procedure for key selection and rollover exchange has been
described in Section 3 of <xref
target="I-D.ietf-karp-crypto-key-table">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.</t>
</section>
</section>
<section title="Key Management Database (KMDB)">
<t>Protocol interaction between RKMP and its client routing protocols is
typically done using KMDB. Routing protocols update KMDB by installing a
new Key related information or purging an existing Key specific
information. As part of the KMDB update, RKMP initiates peering
connections with its appropriate RKMP peers to announce the updated key
related information. RKMP may also receive an updated key related
information from its peers which gets installed in KMDB. Whenever RKMP
updates KMDB with updated key information from its peers, it notifies
client routing protocols of its updates.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>New Protocol-IDs (as described in <xref
target="protocol-ids"></xref>) are to be allocated in the IKEv2 Security
Protocol Identifiers registry.</t>
<t>A new Traffic Selector Type (as described in <xref
target="rtg-prot-IDs"></xref>) is to be allocated in the IKEv2 Traffic
Selector Types registry.</t>
<t>Several new registries are to be defined as part of a new RKMP
Protocol Registry. These are described in <xref
target="tcp-ao-algs"></xref>, <xref target="tcp-ao-kdf"></xref>, and
<xref target="rtg-prot-IDs"></xref>.</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.5925'?>
<?rfc include='reference.RFC.5926'?>
<?rfc include='reference.RFC.5996'?>
<?rfc include='reference.RFC.5226'?>
</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></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></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></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.I-D.draft-ietf-karp-crypto-key-table-02'?>
<?rfc include='reference.I-D.draft-ietf-karp-routing-tcp-analysis-00'?>
<reference anchor="TCP-AO-REG"
target="http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xml">
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author fullname="Internet Assigned Numbers Authority">
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:16:28 |