diff --git a/draft-ietf-lsvr-l3dl-signing.xml b/draft-ietf-lsvr-l3dl-signing.xml new file mode 100644 index 0000000..a39b307 --- /dev/null +++ b/draft-ietf-lsvr-l3dl-signing.xml @@ -0,0 +1,531 @@ + + + + + + + + + + + + + + + + + + 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 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 + 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. + + + + + + + +
+ + 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 + 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. + + 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 mix(s) 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 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 + this way, the relying party can be confident that the public key is + under control of the identified L3DL protocol entity. + + To the receiver verifying signatures on PDUs, the two methods are + indistinguishable; the key provided in the OPEN PDU is used to + verify the signatures of subsequent PDUs. The difference that + 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. + +
+ +
+ + There are three parts to using a key: signing PDUs, verifying + the OPEN PDU, and verifying subsequent PDUs. + +
+ + All signed PDUs are generated in the same way: + + + + + + Compose the PDU, with all fields including "Sig Algo" and + "Signature Length" set, but omitting the trailing + "Signature" field itself. The Certificate Length should + be zero and the Certificate field should be empty. This + is the "message to be signed" for purposes of the + signature algorithm. + + + + 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. + + + + Construct the complete message by appending the signature + octets to the otherwise complete message composed above. + + + + + + + In the case of the OPEN PDU, the message to be signed will + include the public member of the asymmetric keypair, but as + far as the signature algorithm is concerned that's just + payload, no different from any other PDU content. + + +
+ +
+ + + The process for verifying an OPEN PDU is slightly different + from the process for verifying other PDU types, because the + OPEN PDU also establishes the session key. + + + + + + + Verify that the PDU is syntactically correct, and extract + the Auth Type, Key, Sig Type, and Signature fields. + + + + Verify that Auth Type and Sig Type refer to the same + algorithm suite, and that said algorithm suite is one that + the implementation understands. + + + + Construct the "message to be verified" by truncating the PDU + to remove the Signature field (in practice this should not + require copying any data, just subtract the signature length + from the PDU length). + + + + Verify the message constructed above against the public key + using the rules for the specific signature suite. + + + + Record Auth Type and Key as this sessions's authentication + type and session key, for use in verifying subseuqent PDUs. + + + + + + + If any of the above verification steps fail, generate an error + using error code 2 ("Authorization failure in OPEN"). + + + + +
+ +
+ + + The process for verifying non-OPEN PDUs is slightly simpler, + but follows the same basic pattern as for OPEN PDUs. + + + + + + + Verify that the PDU is syntactically correct, and extract + the Sig Type and Signature fields. + + + + Verify that Sig Type refers to the same algorithm suite as + the Auth Type recorded during verification of the OPEN PDU. + + + + Construct the "message to be verified" by truncating the PDU + to remove the Signature field. + + + + Verify the message constructed above against the recorded + session key using the rules for the specific signature + suite. + + + + + + + If any of the above verification steps fail, generate an error + using error code 3 ("Signature failure in PDU"). + + + + +
+ +
+ +
+ + + 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. + + + + Generating an OPEN PDU using the PKI method requires a + certificate, which must be supplied via out of band + configuration. The certificate is a signature of the public key + to be sent in the Key field of the OPEN PDU, signed by the trust + anchor private key. + + + + 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 + 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). + + +
+ + + Generating and signing the OPEN PDU with the PKI method is + almost the same as in . The + only difference is that the PKI method MUST supply the + appropriate certificate in the Certificate field. + + + + Note that the Auth Type field applies to both the Key and + Certificate fields. That is: the certificate uses the same + certificate suite as the session keys, L3DL does not support + cross-algorithm-suite certification. + + +
+ +
+ + + Verifying the OPEN PDU with PKI is similar to verifying with + TOFU as described in , but + includes one critical extra step: + + + + After extracting the Key field from the PDU but before + verifying the Signature, extract the Certificate field and + verfiy that the Certificate is a valid signature of the Key + field, according to the rules for the signature suite + specified by Auth Type. If this step fails, handle as in + . + + +
+ +
+ +
+ + + Whether to use TOFU, PKI, or no signatures at all is a matter of + local policy, to be decided by the operator. The useful + policy combinations for Key and Certificate are probably: + + + + + + + Not signing: sender need not sign, receiver does not check. + + + + Require TOFU: sender MUST supply key and receiver MUST + check, certificate not needed and ignored if sent. + + + + 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. + + + + + +
+ +
+ + 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. + + + +
+ + 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 Algor | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| New Key Length | New Key ... | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | New Cert Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| New Certificate ... | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Old Sig Type | Old Signature Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| Old Signature ... | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + The New Key Type, New Key Length, New Key, New Cert Length, and + New Certificate field declare the replacement algorithm suite, + key, and certificate. + + 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 rekeying operation changes the session key and algorithm + suite described in . The + NEWKEY PDU itself is verified using the old algorithm and + session key, subsequent PDUs are verified with the new algorithm + and session key recorded after the NEWKEY PDU has been accepted. + + +
+ +
+ + 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 + covering the payload. + + 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 network'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 certificates are 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 registry entries for "TOFU - + Trust On First Use" and "PKI" to the L3DL-Signature-Type registry as + follows: +
+ + Number Name + ------ ------------------- + 1 TOFU - Trust On First Use + 2 PKI + +
+ +
+ +
+ + The authors thank Russ Housley for advice and reviews. + +
+ + + + + + + + + + + + + + + +