rename
This commit is contained in:
parent
914e19bb4f
commit
38e89f3543
1 changed files with 207 additions and 0 deletions
207
draft-ymbk-lsvr-l3dl-signing.xml
Normal file
207
draft-ymbk-lsvr-l3dl-signing.xml
Normal file
|
|
@ -0,0 +1,207 @@
|
||||||
|
<?xml version="1.0" encoding="utf-8"?>
|
||||||
|
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
|
||||||
|
<?rfc comments="yes"?>
|
||||||
|
<?rfc compact="yes"?>
|
||||||
|
<?rfc subcompact="no"?>
|
||||||
|
<?rfc inline="yes"?>
|
||||||
|
<?rfc sortrefs="yes"?>
|
||||||
|
<?rfc symrefs="yes"?>
|
||||||
|
<?rfc toc="yes"?>
|
||||||
|
<?rfc tocdepth="6"?>
|
||||||
|
<?rfc tocindent="yes"?>
|
||||||
|
<?rfc tocompact="yes"?>
|
||||||
|
|
||||||
|
<rfc category="std" docName="draft-ymbk-lsvr-l3dl-signing-00" ipr="trust200902">
|
||||||
|
|
||||||
|
<front>
|
||||||
|
|
||||||
|
<title>Layer 3 Discovery and Liveness TOFU Security</title>
|
||||||
|
|
||||||
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
||||||
|
<organization>Arrcus & IIJ</organization>
|
||||||
|
<address>
|
||||||
|
<postal>
|
||||||
|
<street>5147 Crystal Springs</street>
|
||||||
|
<city>Bainbridge Island</city>
|
||||||
|
<region>WA</region>
|
||||||
|
<code>98110</code>
|
||||||
|
<country>United States of America</country>
|
||||||
|
</postal>
|
||||||
|
<email>randy@psg.com</email>
|
||||||
|
</address>
|
||||||
|
</author>
|
||||||
|
|
||||||
|
<author fullname="Russ Housley" initials="R" surname="Housley">
|
||||||
|
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
|
||||||
|
<address>
|
||||||
|
<postal>
|
||||||
|
<street>918 Spring Knoll Drive</street>
|
||||||
|
<city>Herndon</city>
|
||||||
|
<region>VA</region>
|
||||||
|
<code>20170</code>
|
||||||
|
<country>USA</country>
|
||||||
|
</postal>
|
||||||
|
<email>housley@vigilsec.com</email>
|
||||||
|
</address>
|
||||||
|
</author>
|
||||||
|
|
||||||
|
<author initials="R." surname="Austein" fullname="Rob Austein">
|
||||||
|
<organization abbrev="Arrcus">Arrcus, Inc.</organization>
|
||||||
|
<address>
|
||||||
|
<email>sra@hactrn.net</email>
|
||||||
|
</address>
|
||||||
|
</author>
|
||||||
|
|
||||||
|
<date />
|
||||||
|
|
||||||
|
<abstract>
|
||||||
|
|
||||||
|
<t>The Layer 3 Discovery and Liveness protocol provides for the OPEN
|
||||||
|
PDU to contain a key which can be used to verify signatures on
|
||||||
|
subsequent PDUs. This document describes two methods of key
|
||||||
|
generation and signing for use by L3DL when 'trust on first use'
|
||||||
|
authentication and integrity are sufficient.</t>
|
||||||
|
|
||||||
|
</abstract>
|
||||||
|
|
||||||
|
<note title="Requirements Language">
|
||||||
|
|
||||||
|
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||||
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
||||||
|
"OPTIONAL" in this document are to be interpreted as described in
|
||||||
|
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
|
||||||
|
and only when, they appear in all capitals, as shown here.</t>
|
||||||
|
|
||||||
|
</note>
|
||||||
|
|
||||||
|
</front>
|
||||||
|
|
||||||
|
<middle>
|
||||||
|
|
||||||
|
<section anchor="intro" title="Introduction">
|
||||||
|
|
||||||
|
<t>The Layer 3 Discovery and Liveness protocol [old ref because new
|
||||||
|
draft not yet pushed] <xref target="I-D.ietf-lsvr-lsoe"/> provides
|
||||||
|
for the OPEN PDU to contain a key which can be used to verify
|
||||||
|
signatures on subsequent PDUs. This document describes two methods
|
||||||
|
of key generation and signing for use by L3DL when 'trust on first
|
||||||
|
use,' TOFU, authentication and integrity are sufficient.</t>
|
||||||
|
|
||||||
|
<t>To the receiver, the two methods are indistinguishable, the key
|
||||||
|
provided in the OPEN PDU is used to verify the signatures on the
|
||||||
|
subsequent PDUs. The difference is how that key is generated.</t>
|
||||||
|
|
||||||
|
<t>The simple method is that the OPEN key is a 64-bit random. The
|
||||||
|
device sending the OPEN may use one key for all links, a different
|
||||||
|
key for each link, or some aggregation(s) thereof.</t>
|
||||||
|
|
||||||
|
<t>If one is concerned about a Monkey In The Middle, then the OPEN
|
||||||
|
key can be the public half of an asymmetric key pair. The sender
|
||||||
|
signs with the private key, of course. To reduce key generation
|
||||||
|
load on the sending device, the key pair could be generated once per
|
||||||
|
device.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section anchor="roll" title="NEWKEY, Key Roll">
|
||||||
|
|
||||||
|
<t>Modern key management allows for agility in 'rolling' to a new
|
||||||
|
key or even algorithm in case of key compromise or merely prudence.
|
||||||
|
Declaring a new key with an L3DL OPEN PDU would cause serious churn
|
||||||
|
in topology as a new OPEN causes a withdraw of previously announced
|
||||||
|
encapsulations. Therefore, a gentler rekeying is needed.</t>
|
||||||
|
|
||||||
|
<!--
|
||||||
|
protocol "Type = 8:8,Payload Length:16,New Auth Type:8,New Key Length:16,New Key ...:40,Old Sig Type:8,Old Signature Length:16,Old Signature ...:40"
|
||||||
|
-->
|
||||||
|
|
||||||
|
<figure>
|
||||||
|
<artwork>
|
||||||
|
0 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
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
| Type = 8 | Payload Length | New Auth Type |
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
| New Key Length | ~
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
||||||
|
~ New Key ... | Old Sig Type |
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
| Old Signature Length | ~
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
||||||
|
~ Old Signature ... |
|
||||||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||||
|
</artwork>
|
||||||
|
</figure>
|
||||||
|
|
||||||
|
<t>The New Auth Type, New Key Length, and New Key fields declare the
|
||||||
|
replacement algorithm suite and key.</t>
|
||||||
|
|
||||||
|
<t>The NEWKEY PDU is signed using the current (soon to be old)
|
||||||
|
algorithm suite and key.</t>
|
||||||
|
|
||||||
|
<t>The sender and the receiver should be cautious of algorithm suite
|
||||||
|
downgrade attacks.</t>
|
||||||
|
|
||||||
|
<t>To avoid possible race conditions, the receiver SHOULD accept
|
||||||
|
signatures using either the new or old key for a configurable time
|
||||||
|
(default 30 seconds). This is intended to accommodate situations
|
||||||
|
such as senders with high peer out-degree and a single per-device
|
||||||
|
asymmetric key.</t>
|
||||||
|
|
||||||
|
<t>If the sender does not receive an ACK in the normal window,
|
||||||
|
including retransmission, then the sender MAY choose to allow a
|
||||||
|
session reset by either issuing a new OPEN or by letting the
|
||||||
|
receiver eventually have a signature failure (error code 3) on a
|
||||||
|
PDU.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section anchor="security" title="Security Considerations">
|
||||||
|
|
||||||
|
<t>The REKEY PDU is open to abuse to create an algorithm suite
|
||||||
|
downgrade attack.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section anchor="iana" title="IANA Considerations">
|
||||||
|
|
||||||
|
<t>This document requests the IANA create a new entry in the L3DL PDU
|
||||||
|
Type registry as follows:</t>
|
||||||
|
<figure>
|
||||||
|
<artwork>
|
||||||
|
PDU
|
||||||
|
Code PDU Name
|
||||||
|
---- -------------------
|
||||||
|
8 NEWKEY
|
||||||
|
</artwork>
|
||||||
|
</figure>
|
||||||
|
|
||||||
|
<t>This document requests the IANA add a registry entry for "TOFU -
|
||||||
|
Trust On Frst Use" to the L3DL-Signature-Type registry as follows:</t>
|
||||||
|
<figure>
|
||||||
|
<artwork>
|
||||||
|
Number Name
|
||||||
|
------ -------------------
|
||||||
|
1 TOFU - Trust On First Use
|
||||||
|
</artwork>
|
||||||
|
</figure>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
|
||||||
|
</middle>
|
||||||
|
|
||||||
|
<back>
|
||||||
|
|
||||||
|
<references title="Normative References">
|
||||||
|
<?rfc include="reference.RFC.2119"?>
|
||||||
|
<?rfc include="reference.RFC.8174"?>
|
||||||
|
<?rfc include="reference.I-D.ietf-lsvr-lsoe"?>
|
||||||
|
</references>
|
||||||
|
<!--
|
||||||
|
<references title="Informative References">
|
||||||
|
</references>
|
||||||
|
-->
|
||||||
|
|
||||||
|
</back>
|
||||||
|
|
||||||
|
</rfc>
|
||||||
Loading…
Add table
Add a link
Reference in a new issue