Layer 3 Discovery and Liveness TOFU SecurityArrcus & IIJ5147 Crystal SpringsBainbridge IslandWA98110United States of Americarandy@psg.comVigil Security, LLC918 Spring Knoll DriveHerndonVA20170USAhousley@vigilsec.comArrcus, Inc.sra@hactrn.netThe 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.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 when,
and only when, they appear in all capitals, as shown here.The Layer 3 Discovery and Liveness protocol [old ref because new
draft not yet pushed] 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.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.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.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.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.
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The New Auth Type, New Key Length, and New Key fields declare the
replacement algorithm suite and key.The NEWKEY PDU is signed using the current (soon to be old)
algorithm suite and key.The sender and the receiver should be cautious of algorithm suite
downgrade attacks.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.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.The REKEY PDU is open to abuse to create an algorithm suite
downgrade attack.This document requests the IANA create a new entry in the L3DL PDU
Type registry as follows:
PDU
Code PDU Name
---- -------------------
8 NEWKEY
This document requests the IANA add a registry entry for "TOFU -
Trust On Frst Use" to the L3DL-Signature-Type registry as follows:
Number Name
------ -------------------
1 TOFU - Trust On First Use