Layer 3 Discovery and Liveness Signing Arrcus & IIJ
5147 Crystal Springs Bainbridge Island WA 98110 United States of America randy@psg.com
Arrcus, Inc.
sra@hactrn.net
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 mechanisms based on digital signatures, one that is Trust On First Use (TOFU), and one that uses certificates to provide authentication as well as session integrity. 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 an algorithm specifier and 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, Trust On First Use (TOFU) and a PKI-based mechanism to provide authentication as well as session integrity. 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. In the TOFU method the OPEN key is believed without question and is used to verify all subsequent PDUs from the same peer with the same Key Type. With the PKI-mechanism, an enrollment step is performed. The public key and an identifier of the subject are put into a certificate, which is signed by the trust anchor. In this way, the relying party can be confident that the public key is under control of the identified L3DL protocol entity. In the PKI method the OPEN key MUST be verified against the trust anchor for the operational domain. It is then used to verify all subsequent PDUs from the same peer with the same Key Type. The Key in the OPEN PDU SHOULD be the public key of an asymmetric key pair. The sender signs with the private key, of course. The device sending the OPEN may use one key for all links, a different key for each link, or some aggregation(s) thereof.
Modern key management allows for agility in 'rolling' to a new key or even algorithm in case of key expiry, 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 Key Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Key Length | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ~ New Key ... | Old Sig Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old Signature Length | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ~ Old Signature ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The New Key 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 TOFU method requires a leap of faith to accept the key in the OPEN PDU, as it can not be verified against any authority. Hence it is jokingly referred to as Married On First Date. The assurance it does provide is that subsequent signed PDUs are from the same peer. And data integrity is a positive side effect of the signature. The PKI-based method offers assurance that the certificate, and hence the keying material, provided in the OPEN PDU are authorized by a central authority, e.g. the Clos's network security team. The onward assurance of talking to the same peer and data integrity are the same as in the TOFU method. With the PKI-based method, automated device provisioning could restrict which subsidiary certificates were allowed from which peers on a per interface basis. This would complicate key rolls. Where one draws the line between rigidity, flexibility, and security varies. 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 First Use" to the L3DL-Signature-Type registry as follows:
Number Name ------ ------------------- 1 TOFU - Trust On First Use 2 PKI
The authors than Russ Housley for advice and review.