From e4cbe4a2d47d568986bd8732c6c420bf71e10993 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Fri, 12 Feb 2021 14:53:00 -0800 Subject: [PATCH] russ's revisons --- draft-ietf-lsvr-l3dl-signing.xml | 167 +++++++++++++++++-------------- 1 file changed, 92 insertions(+), 75 deletions(-) diff --git a/draft-ietf-lsvr-l3dl-signing.xml b/draft-ietf-lsvr-l3dl-signing.xml index 4815497..5ada8d4 100644 --- a/draft-ietf-lsvr-l3dl-signing.xml +++ b/draft-ietf-lsvr-l3dl-signing.xml @@ -31,7 +31,6 @@ - Arrcus, Inc. @@ -59,11 +57,11 @@ The Layer-3 Discovery and Liveness protocol OPEN PDU may contain - a key and a certificate, which can be used to verify signatures on - subsequent PDUs. This document describes two mechanisms based on + a public key and a certificate, 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. + that uses a trust anchor signture over the public key to provide + authentication as well as session integrity. @@ -72,7 +70,7 @@ 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, + BCP 14 when, and only when, they appear in all capitals, as shown here. @@ -83,14 +81,9 @@
- This draft is being published without incorporating changes from - an excellent security review. This is being done so a couple of - other drafts can reference it. While all comments will, of course, - be appreciated, readers may want to wait for the -01 version. - The Layer-3 Discovery and Liveness protocol OPEN PDU contains an algorithm - identifier, a key, and a certificate, which can be used to verify + identifier, a key, and a L3DL certificate, 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 @@ -98,17 +91,16 @@ 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 + device sending the OPEN PDU may use one key for all links, a different key for each link, or some mix(es) thereof. In the TOFU method the key sent in the OPEN PDU is generated on the sending device, is believed without question by the receiver, and used to verify all subsequent PDUs from the same sender with the - same Key Type and Algorithm. + same public key and algorithm. - With the PKI-mechanism, an enrollment step is performed. The - public key is put into a certificate , which - is signed by the the operational environment's trust anchor. In + With the PKI method, an enrollment step is performed. The public + key is signed by the the operational environment's trust anchor. In this way, the relying party can be confident that the public key is under control of the identified L3DL protocol entity. @@ -121,12 +113,32 @@ PKI-based keys may be verified against the trust anchor when the OPEN PDU is received. - In the PKI method the OPEN key MUST be verified against the trust - anchor for the operational domain. The OPEN key is then used to - verify all subsequent PDUs in the session. + In the PKI method the public key in the OPEN PDU MUST be verified + against the trust anchor for the operational domain. The OPEN PDU + public key is then used to verify all subsequent PDUs in the + session. A mechanism for 'rolling' from the current public key + to a fresh one is described in .
+
+ + To avoid the creation of yet another IANA registry for + digital signature algorithm identifiers, this specification makes + use of the existing IANA registry for "DNS Security Algorithm Numbers" + . In this registry, each signature algorithm is + identified by an 8-bit value. The entries in this registry with "Y" + in the "Zone Signing" column are appropriate for use with this + protocol. + + For interoperability, all implementations of this protocol + MUST support the RSASHA256 algorithm (identified by the value 8). + Implementation MAY support any other registered "Zone Signing" + signature algorithms. + +
+ +
There are three parts to using a key: signing PDUs, verifying @@ -149,13 +161,13 @@ - Generate the signature as specified for the chosen signature - suite, using the private member of the asymmetric key pair. - In general this will involve first hashing the "message to - be signed" then signing the hash, but the precise details - may vary with the specific algorithm. The result will be a - sequence of octets, the length of which MUST be equal to the - setting of the "Signature Length" field. + Generate the signature as specified for the chosen algorithm, + using the private key of the asymmetric key pair. In general, + this will involve first hashing the "message to be signed" then + signing the hash, but the precise details may vary with the + specific signature algorithm. The result will be a sequence of + octets, the length of which MUST be equal to the value in the + "Signature Length" field. @@ -284,12 +296,12 @@
- Using a PKI, , is almost the same as using - TOFU, but with one additional step: during verification of an OPEN - PDU, after extracting the Key field from the PDU but before - attempting to use it to verify the PDU's signature, the receiver - MUST verify the received key against the PKI to confirm that it's - an authorized key. + Using a PKI is almost the same as using TOFU, but with one + additional step: during verification of an OPEN PDU, after + extracting the Key field from the PDU but before attempting to use + it to verify the OPEN PDU signature, the receiver MUST verify the + received key against the PKI to confirm that it's an authorized + key. @@ -303,17 +315,18 @@ Verifying an OPEN PDU using the PKI method requires the public key of the trust anchor, which the receiver uses to verify the - certificate, thereby demonstrating that the supplied is + certificate, thereby demonstrating that the supplied public key represents an authorized L3DL speaker in this administrative domain. - We use the term "certificate" here in the generic sense. These - are not X.509 certificates: X.509 is much more complicated than - we need for L3DL. The certificates used here are just - signatures of one key (the session key supplied in the Key field - of the OPEN PDU) by another key (the trust anchor). + We use the term "certificate" here in the generic sense, not as + defined in . X.509 certificates are not + used here; X.509 certificates are more complicated than needed + for L3DL. The L3DL certificates are just signatures of one key + (the public key supplied in the Key field of the OPEN PDU) that + can be verified by another trusted public key (the trust anchor).
@@ -372,17 +385,17 @@ Require TOFU: sender MUST supply key and receiver MUST - check, certificate not needed and ignored if sent. + check, but L3DL certificates not needed and ignored if sent. - Allow TOFU: sender must supply key and receiver MUST check, + Allow TOFU: sender MUST supply key and receiver MUST check, receiver SHOULD check certificate if supplyed by sender. - Require PKI: sender MUST supply key and certificate, - receiver MUST check both. + Require PKI: sender MUST supply key and L3DL certificate, + receiver MUST check signature and verify the L3DL certificate. @@ -395,9 +408,13 @@ 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 may cause a withdraw - of previously announced encapsulations. Therefore, a gentler - rekeying is needed. + cause serious churn in topology as a new OPEN PDU may cause a + withdraw of previously announced encapsulations. Therefore, a + gentler rekeying is needed. + + Prior to 'rolling' to a new key or new algorithm, a new public/private + key pair is generated. If PKI is being used, then the trust anchor + also signs the new public key to create a new L3DL certificate.