idnits 2.17.1 draft-ietf-lsvr-l3dl-signing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 October 2021) is 918 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-lsvr-l3dl-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-lsvr-l3dl (ref. 'I-D.ietf-lsvr-l3dl') -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Arrcus & IIJ 4 Intended status: Standards Track R. Housley 5 Expires: 17 April 2022 Vigil Security 6 R. Austein 7 Arrcus 8 14 October 2021 10 Layer-3 Discovery and Liveness Signing 11 draft-ietf-lsvr-l3dl-signing-03 13 Abstract 15 The Layer-3 Discovery and Liveness protocol OPEN PDU may contain a 16 public key and a certificate, which can be used to verify signatures 17 on subsequent PDUs. This document describes two mechanisms based on 18 digital signatures, one that is Trust On First Use (TOFU), and one 19 that uses a trust anchor signture over the public key to provide 20 authentication as well as session integrity. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 17 April 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Signature Algorithm Identifiers . . . . . . . . . . . . . . . 3 65 3. Trust On First Use Method . . . . . . . . . . . . . . . . . . 3 66 3.1. Signing a PDU . . . . . . . . . . . . . . . . . . . . . . 3 67 3.2. Verifying the OPEN PDU . . . . . . . . . . . . . . . . . 4 68 3.3. Verifying Other PDUs . . . . . . . . . . . . . . . . . . 5 69 4. Public Key Infrastructure Method . . . . . . . . . . . . . . 5 70 4.1. Signing OPEN PDU with PKI . . . . . . . . . . . . . . . . 6 71 4.2. Verifying OPEN PDU with PKI . . . . . . . . . . . . . . . 6 72 5. Local Policy . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. NEWKEY, Key Roll . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 9.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 The Layer-3 Discovery and Liveness protocol [I-D.ietf-lsvr-l3dl] OPEN 84 PDU contains an algorithm identifier, a key, and a L3DL certificate, 85 which can be used to verify signatures on subsequent PDUs. This 86 document describes two methods of key generation and signing for use 87 by L3DL, Trust On First Use (TOFU) and a PKI-based mechanism to 88 provide authentication as well as session integrity. 90 The Key in the OPEN PDU SHOULD be the public key of an asymmetric key 91 pair. The sender signs with the private key, of course. The device 92 sending the OPEN PDU may use one key for all links, a different key 93 for each link, or some mix(es) thereof. 95 In the TOFU method the key sent in the OPEN PDU is generated on the 96 sending device, is believed without question by the receiver, and 97 used to verify all subsequent PDUs from the same sender with the same 98 public key and algorithm. 100 With the PKI method, an enrollment step is performed. The public key 101 is signed by the the operational environment's trust anchor. In this 102 way, the relying party can be confident that the public key is under 103 control of the identified L3DL protocol entity. 105 As part of enrollment or before hand, all relying parties must have 106 received the trust anchor in an authentic manner. 108 To the receiver verifying signatures on PDUs, the two methods are 109 indistinguishable; the key provided in the OPEN PDU is used to verify 110 the signatures of subsequent PDUs. The difference that PKI-based 111 keys may be verified against the trust anchor when the OPEN PDU is 112 received. 114 In the PKI method the public key in the OPEN PDU MUST be verified 115 against the trust anchor for the operational domain. The OPEN PDU 116 public key is then used to verify all subsequent PDUs in the session. 117 A mechanism for 'rolling' from the current public key to a fresh one 118 is described in Section 6. 120 2. Signature Algorithm Identifiers 122 To avoid the creation of yet another IANA registry for digital 123 signature algorithm identifiers, this specification makes use of the 124 existing IANA registry for "DNS Security Algorithm Numbers" [IANA]. 125 In this registry, each signature algorithm is identified by an 8-bit 126 value. The entries in this registry with "Y" in the "Zone Signing" 127 column are appropriate for use with this protocol. 129 For interoperability, all implementations of this protocol MUST 130 support the RSASHA256 algorithm (identified by the value 0x08). 131 Implementation MAY support any other registered "Zone Signing" 132 signature algorithms. 134 3. Trust On First Use Method 136 There are three parts to using a key: signing PDUs, verifying the 137 OPEN PDU, and verifying subsequent PDUs. 139 3.1. Signing a PDU 141 All signed PDUs are generated in the same way: 143 * Compose the PDU, with all fields including "Sig Algo" and 144 "Signature Length" set, but omitting the trailing "Signature" 145 field itself. The Certificate Length should be zero and the 146 Certificate field should be empty. This is the "message to be 147 signed" for purposes of the signature algorithm. 149 * Generate the signature as specified for the chosen algorithm, 150 using the private key of the asymmetric key pair. In general, 151 this will involve first hashing the "message to be signed" then 152 signing the hash, but the precise details may vary with the 153 specific signature algorithm. The result will be a sequence of 154 octets, the length of which MUST be equal to the value in the 155 "Signature Length" field. 157 * Construct the complete message by appending the signature octets 158 to the otherwise complete message composed above. 160 In the case of the OPEN PDU, the message to be signed will include 161 the public member of the asymmetric keypair, but as far as the 162 signature algorithm is concerned that's just payload, no different 163 from any other PDU content. 165 3.2. Verifying the OPEN PDU 167 The process for verifying an OPEN PDU is slightly different from the 168 process for verifying other PDU types, because the OPEN PDU also 169 establishes the session key. 171 * Verify that the PDU is syntactically correct, and extract the Auth 172 Type, Key, Sig Type, and Signature fields. 174 * Verify that Auth Type and Sig Type refer to the same algorithm 175 suite, and that said algorithm suite is one that the 176 implementation understands. 178 * Construct the "message to be verified" by truncating the PDU to 179 remove the Signature field (in practice this should not require 180 copying any data, just subtract the signature length from the PDU 181 length). 183 * Verify the message constructed above against the public key using 184 the rules for the specific signature suite. 186 * Record Auth Type and Key as this sessions's authentication type 187 and session key, for use in verifying subseuqent PDUs. 189 If any of the above verification steps fail, generate an error using 190 error code 2 ("Authorization failure in OPEN"). 192 3.3. Verifying Other PDUs 194 The process for verifying non-OPEN PDUs is slightly simpler, but 195 follows the same basic pattern as for OPEN PDUs. 197 * Verify that the PDU is syntactically correct, and extract the Sig 198 Type and Signature fields. 200 * Verify that Sig Type refers to the same algorithm suite as the 201 Auth Type recorded during verification of the OPEN PDU. 203 * Construct the "message to be verified" by truncating the PDU to 204 remove the Signature field. 206 * Verify the message constructed above against the recorded session 207 key using the rules for the specific signature suite. 209 If any of the above verification steps fail, generate an error using 210 error code 3 ("Signature failure in PDU"). 212 4. Public Key Infrastructure Method 214 Using a PKI is almost the same as using TOFU, but with one additional 215 step: during verification of an OPEN PDU, after extracting the Key 216 field from the PDU but before attempting to use it to verify the OPEN 217 PDU signature, the receiver MUST verify the received key against the 218 PKI to confirm that it's an authorized key. 220 Generating an OPEN PDU using the PKI method requires a certificate, 221 which must be supplied via out of band configuration. The 222 certificate is a signature of the public key to be sent in the Key 223 field of the OPEN PDU, signed by the trust anchor private key. 225 Verifying an OPEN PDU using the PKI method requires the public key of 226 the trust anchor, which the receiver uses to verify the certificate, 227 thereby demonstrating that the supplied public key represents an 228 authorized L3DL speaker in this administrative domain. 230 We use the term "certificate" here in the generic sense, not as 231 defined in [RFC5280]. X.509 certificates are not used here; X.509 232 certificates are more complicated than needed for L3DL. The L3DL 233 certificates are just signatures of one key (the public key supplied 234 in the Key field of the OPEN PDU) that can be verified by another 235 trusted public key (the trust anchor). 237 4.1. Signing OPEN PDU with PKI 239 Generating and signing the OPEN PDU with the PKI method is almost the 240 same as in Section 3.1. The only difference is that the PKI method 241 MUST supply the appropriate certificate in the Certificate field. 243 Note that the Auth Type field applies to both the Key and Certificate 244 fields. That is: the certificate uses the same certificate suite as 245 the session keys, L3DL does not support cross-algorithm-suite 246 certification. 248 4.2. Verifying OPEN PDU with PKI 250 Verifying the OPEN PDU with PKI is similar to verifying with TOFU as 251 described in Section 3.2, but includes one critical extra step: 253 After extracting the Key field from the PDU but before verifying the 254 Signature, extract the Certificate field and verfiy that the 255 Certificate is a valid signature of the Key field, according to the 256 rules for the signature suite specified by Auth Type. If this step 257 fails, handle as in Section 3.2. 259 5. Local Policy 261 Whether to use TOFU, PKI, or no signatures at all is a matter of 262 local policy, to be decided by the operator. The useful policy 263 combinations for Key and Certificate are probably: 265 * Not signing: sender need not sign, receiver does not check. 267 * Require TOFU: sender MUST supply key and receiver MUST check, but 268 L3DL certificates not needed and ignored if sent. 270 * Allow TOFU: sender MUST supply key and receiver MUST check, 271 receiver SHOULD check certificate if supplyed by sender. 273 * Require PKI: sender MUST supply key and L3DL certificate, receiver 274 MUST check signature and verify the L3DL certificate. 276 6. NEWKEY, Key Roll 278 Modern key management allows for agility in 'rolling' to a new key or 279 even algorithm in case of key expiry, key compromise, or merely 280 prudence. Declaring a new key with an L3DL OPEN PDU would cause 281 serious churn in topology as a new OPEN PDU may cause a withdraw of 282 previously announced encapsulations. Therefore, a gentler rekeying 283 is needed. 285 Prior to 'rolling' to a new key or new algorithm, a new public/ 286 private key pair is generated. If PKI is being used, then the trust 287 anchor also signs the new public key to create a new L3DL 288 certificate. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type = 8 | Payload Length | New Key Type | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | New Key Length | New Key ... | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | New Cert Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | New Certificate ... | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Old Key Type | Old Signature Length | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 303 | Old Signature ... | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 The New Key Type, New Key Length, New Key, New Cert Length, and New 307 Certificate fields declare the replacement algorithm, key, and L3DL 308 certificate. 310 The NEWKEY PDU is signed using the current (soon to be old) algorithm 311 and key. 313 The sender and the receiver should be cautious of signature algorithm 314 downgrade attacks. 316 To avoid possible race conditions, the receiver SHOULD accept 317 signatures using either the new or old key for a configurable time 318 (default 30 seconds). This is intended to accommodate situations 319 such as senders with high peer out-degree and a single per-device 320 asymmetric key. 322 If the sender does not receive an ACK in the normal window, including 323 retransmission, then the sender MAY choose to allow a session reset 324 by either issuing a new OPEN PDU or by letting the receiver 325 eventually have a signature failure (error code 3) on a PDU. 327 The rekeying operation changes the session key and the associated 328 algorithm described in Section 3.3. The NEWKEY PDU itself is 329 verified using the old algorithm and session key. After the NEWKEY 330 PDU has been accepted, subsequent PDUs are verified with the new 331 algorithm and the new session key. 333 7. Security Considerations 335 The TOFU method requires a leap of faith to accept the key in the 336 OPEN PDU, as it can not be verified against any authority. Hence it 337 is jokingly referred to as Married On First Date. The assurance it 338 does provide is that subsequent signed PDUs are from the same peer. 339 And data integrity is a positive side effect of the signature 340 covering the payload. 342 The PKI method offers assurance that the L3DL certificate, and hence 343 the public key, provided in the OPEN PDU are authorized by a central 344 authority, e.g. the network's security team. The onward assurance of 345 talking to the same peer and data integrity are the same as in the 346 TOFU method. 348 With the PKI method, automated device provisioning could restrict 349 which L3DL certificates are allowed from which peers on a per 350 interface basis. This would complicate key rolls. Where one draws 351 the line between rigidity, flexibility, and security varies. 353 The REKEY PDU is open to abuse to create a signature algorithm 354 downgrade attack. 356 8. IANA Considerations 358 This document requests the IANA create a new entry in the L3DL PDU 359 Type registry as follows: 361 PDU 362 Code PDU Name 363 ---- ------------------- 364 8 NEWKEY 366 This document requests the IANA add registry entries for "TOFU - 367 Trust On First Use" and "PKI" to the L3DL-Signature-Type registry as 368 follows: 370 Number Name 371 ------ ------------------- 372 1 TOFU - Trust On First Use 373 2 PKI 375 9. References 377 9.1. Normative References 379 [I-D.ietf-lsvr-l3dl] 380 Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery 381 and Liveness", Work in Progress, Internet-Draft, draft- 382 ietf-lsvr-l3dl-07, 26 January 2021, 383 . 386 [IANA] "DNS Security Algorithm Numbers", 387 . 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 397 May 2017, . 399 9.2. Informative References 401 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 402 Housley, R., and W. Polk, "Internet X.509 Public Key 403 Infrastructure Certificate and Certificate Revocation List 404 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 405 . 407 Authors' Addresses 409 Randy Bush 410 Arrcus & IIJ 411 5147 Crystal Springs 412 Bainbridge Island, WA 98110 413 United States of America 415 Email: randy@psg.com 417 Russ Housley 418 Vigil Security, LLC 419 516 Dranesville Road 420 Herndon, VA 20170 421 United States of America 423 Email: housley@vigilsec.com 424 Rob Austein 425 Arrcus, Inc. 427 Email: sra@hactrn.net