From f6b7f750dd8ddd1223f36a9755a15f28f19b2789 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Thu, 7 May 2020 14:16:11 -0700 Subject: [PATCH] ref 5280 per russ --- draft-ymbk-lsvr-l3dl-signing.txt | 504 +++++++++++++++++++++++++++++++ draft-ymbk-lsvr-l3dl-signing.xml | 9 +- 2 files changed, 509 insertions(+), 4 deletions(-) create mode 100644 draft-ymbk-lsvr-l3dl-signing.txt diff --git a/draft-ymbk-lsvr-l3dl-signing.txt b/draft-ymbk-lsvr-l3dl-signing.txt new file mode 100644 index 0000000..57d07c4 --- /dev/null +++ b/draft-ymbk-lsvr-l3dl-signing.txt @@ -0,0 +1,504 @@ + + + + +Network Working Group R. Bush +Internet-Draft Arrcus & IIJ +Intended status: Standards Track R. Austein +Expires: November 8, 2020 Arrcus + May 7, 2020 + + + Layer 3 Discovery and Liveness Signing + draft-ymbk-lsvr-l3dl-signing-01 + +Abstract + + 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. + +Requirements Language + + 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 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on November 8, 2020. + + + + + + + + +Bush & Austein Expires November 8, 2020 [Page 1] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Trust On First Use Method . . . . . . . . . . . . . . . . . . 3 + 2.1. Signing a PDU . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Verifying the OPEN PDU . . . . . . . . . . . . . . . . . 4 + 2.3. Verifying Other PDUs . . . . . . . . . . . . . . . . . . 4 + 3. Public Key Infrastructure Method . . . . . . . . . . . . . . 5 + 3.1. Signing OPEN PDU with PKI . . . . . . . . . . . . . . . . 5 + 3.2. Verifying OPEN PDU with PKI . . . . . . . . . . . . . . . 5 + 4. Local Policy . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. NEWKEY, Key Roll . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 + +1. Introduction + + 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 [I-D.ietf-lsvr-l3dl] OPEN + PDU contains an algorithm specifier, 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. + + + + + +Bush & Austein Expires November 8, 2020 [Page 2] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + + 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. + + In the TOFU method the OPEN key is generated on the sending device, + believed without question by the receiver, and used to verify all + subsequent PDUs from the same sender with the same Key Type. + + With the PKI-mechanism, an enrollment step is performed. The public + key is put into a certificate [RFC5280], 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. It is then used to verify all + subsequent PDUs in the session. + +2. Trust On First Use Method + + There are three parts to using a key: signing PDUs, verifying the + OPEN PDU, and verifying subsequent PDUs. + +2.1. Signing a PDU + + All signed PDUs are generated in the same way: + + o Compose the PDU, with all fields including "Sig Type" 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. + + o 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. + + + + +Bush & Austein Expires November 8, 2020 [Page 3] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + + o 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. + +2.2. Verifying the OPEN PDU + + 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. + + o Verify that the PDU is syntactically correct, and extract the Auth + Type, Key, Sig Type, and Signature fields. + + o Verify that Auth Type and Sig Type refer to the same algorithm + suite, and that said algorithm suite is one that the + implementation understands. + + o 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). + + o Verify the message constructed above against the public key using + the rules for the specific signature suite. + + o 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"). + +2.3. Verifying Other PDUs + + The process for verifying non-OPEN PDUs is slightly simpler, but + follows the same basic pattern as for OPEN PDUs. + + o Verify that the PDU is syntactically correct, and extract the Sig + Type and Signature fields. + + o Verify that Sig Type refers to the same algorithm suite as the + Auth Type recorded during verification of the OPEN PDU. + + o Construct the "message to be verified" by truncating the PDU to + remove the Signature field. + + + +Bush & Austein Expires November 8, 2020 [Page 4] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + + o 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"). + +3. Public Key Infrastructure Method + + 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). + +3.1. Signing OPEN PDU with PKI + + Generating and signing the OPEN PDU with the PKI method is almost the + same as in Section 2.1. 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. + +3.2. Verifying OPEN PDU with PKI + + Verifying the OPEN PDU with PKI is similar to verifying with TOFU as + described in Section 2.2, 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 + + + +Bush & Austein Expires November 8, 2020 [Page 5] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + + 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 Section 2.2. + +4. Local Policy + + 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: + + o Not signing: sender need not sign, receiver does not check. + + o Require TOFU: sender MUST supply key and receiver MUST check, + certificate not needed and ignored if sent. + + o Allow TOFU: sender must supply key and receiver MUST check, + receiver SHOULD check certificate if supplyed by sender. + + o Require PKI: sender must supply key and certificate, receiver must + check both. + +5. NEWKEY, Key Roll + + 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 Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Key Length | New Key ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | New Cert Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Certificate ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old Sig Type | Old Signature Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | Old Signature ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Bush & Austein Expires November 8, 2020 [Page 6] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + + 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 Section 2.3. 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. + +6. Security Considerations + + 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. + + + + + +Bush & Austein Expires November 8, 2020 [Page 7] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + + The REKEY PDU is open to abuse to create an algorithm suite downgrade + attack. + +7. IANA Considerations + + 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 + +8. Acknowledgments + + The authors than Russ Housley for advice and review. + +9. Normative References + + [I-D.ietf-lsvr-l3dl] + Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery + and Liveness", draft-ietf-lsvr-l3dl-03 (work in progress), + November 2019. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + + + + +Bush & Austein Expires November 8, 2020 [Page 8] + +Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 + + +Authors' Addresses + + Randy Bush + Arrcus & IIJ + 5147 Crystal Springs + Bainbridge Island, WA 98110 + United States of America + + Email: randy@psg.com + + + Rob Austein + Arrcus, Inc. + + Email: sra@hactrn.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bush & Austein Expires November 8, 2020 [Page 9] diff --git a/draft-ymbk-lsvr-l3dl-signing.xml b/draft-ymbk-lsvr-l3dl-signing.xml index 1b765a7..34e482e 100644 --- a/draft-ymbk-lsvr-l3dl-signing.xml +++ b/draft-ymbk-lsvr-l3dl-signing.xml @@ -107,10 +107,10 @@ Type. 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. + 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 @@ -516,6 +516,7 @@ +