idnits 2.17.1 draft-ietf-acme-dtnnodeid-01.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2021) is 1145 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1000000' on line 875 -- Looks like a reference, but probably isn't: '0' on line 914 -- Looks like a reference, but probably isn't: '1' on line 913 -- Looks like a reference, but probably isn't: '1030000' on line 914 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-26 == Outdated reference: A later version (-14) exists of draft-ietf-acme-email-smime-13 == Outdated reference: A later version (-28) exists of draft-ietf-dtn-tcpclv4-24 == Outdated reference: A later version (-07) exists of draft-bsipos-dtn-bpsec-cose-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Automated Certificate Management Environment B. Sipos 3 Internet-Draft RKF Engineering 4 Intended status: Experimental 7 March 2021 5 Expires: 8 September 2021 7 Automated Certificate Management Environment (ACME) Delay-Tolerant 8 Networking (DTN) Node ID Validation Extension 9 draft-ietf-acme-dtnnodeid-01 11 Abstract 13 This document specifies an extension to the Automated Certificate 14 Management Environment (ACME) protocol which allows an ACME server to 15 validate the Delay-Tolerant Networking (DTN) Node ID for an ACME 16 client. The DTN Node ID is encoded as a certificate Subject 17 Alternative Name (SAN) of type Uniform Resource Identifier (URI) and 18 ACME Identifier type "uri". 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 8 September 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Authorization Strategy . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 5 58 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 6 59 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 8 60 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 9 61 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 9 62 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 10 63 3.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 11 64 4. Certificate Request Profile . . . . . . . . . . . . . . . . . 12 65 4.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 12 66 4.2. Generating Encryption-only or Signing-only Bundle Security 67 Certificates . . . . . . . . . . . . . . . . . . . . . . 13 68 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 6.1. Threat: Passive Leak of Validation Data . . . . . . . . . 14 71 6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 14 72 6.3. Threat: Denial of Service . . . . . . . . . . . . . . . . 14 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 7.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 15 75 7.2. ACME Validation Method . . . . . . . . . . . . . . . . . 15 76 7.3. BP Bundle Administrative Record Types . . . . . . . . . . 15 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 9.2. Informative References . . . . . . . . . . . . . . . . . 18 81 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 19 82 Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 19 83 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 19 84 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 Although the original purpose of the Automatic Certificate Management 90 Environment (ACME) [RFC8555] was to allow Public Key Infrastructure 91 Using X.509 (PKIX) certificate authorities to validate network domain 92 names of clients, the same mechanism can be used to validate any of 93 the subject claims supported by the PKIX profile [RFC5280]. 95 In the case of this specification, the claim being validated is a 96 Subject Alternative Name (SAN) of type Uniform Resource Identifier 97 (URI) used to represent the Node ID of a Delay-Tolerant Networking 98 (DTN) Node. A DTN Node ID is a URI with a specific set of allowed 99 schemes, and determines how bundles are routed within a DTN. 100 Currently the schemes "dtn" and "ipn" as defined in 101 [I-D.ietf-dtn-bpbis] are valid for a Node ID. 103 Once an ACME server validates a Node ID, either as a pre- 104 authorization of the "uri" or as one of the authorizations of an 105 order containing a "uri", the client can finalize the order using an 106 associated certificate signing request. Because a single order can 107 contain multiple identifiers of multiple types, there can be 108 operational issues for a client attempting to, and possibly failing 109 to, validate those multiple identifiers as described in Section 4.1. 110 Once a certificate is issued for a Node ID, how the ACME client 111 configures the BP agent with the new certificate is an implementation 112 matter. 114 The scope and behavior of this validation mechanism is similar to 115 that of secured email validation of [I-D.ietf-acme-email-smime]. For 116 that reason some token splitting terminology in this document is 117 taken from the email specification. 119 1.1. Authorization Strategy 121 The basic unit of data exchange in a DTN is a Bundle 122 [I-D.ietf-dtn-bpbis], which consists of a data payload with 123 accompanying metadata. An Endpoint ID is used as the destination of 124 a Bundle and can indicate both a unicast or a multicast destination. 125 A Node ID is used to identify the source of a Bundle and is used for 126 routing through intermediate nodes, including the final node(s) used 127 to deliver a Bundle to its destination endpoint. A Node ID can also 128 be used as an endpoint for administrative bundles. More detailed 129 descriptions of the rationale and capabilities of these networks can 130 be found in "Delay-Tolerant Network Architecture" [RFC4838]. 132 When a ACME client requests a pre-authorization or an order with a 133 "uri" which could be used as a DTN Node ID, the ACME server offers a 134 challenge type to validate that Node ID. If the ACME client attempts 135 the authorization challenge to validate a Node ID, the ACME server 136 sends an ACME Node ID Validation Challenge Bundle with a destination 137 of the Node ID being validated. The BP agent on that node receives 138 the Challenge Bundle, generates an ACME signature, and sends an ACME 139 Node ID Validation Response Bundle with the signature. Finally, the 140 ACME server receives the Response Bundle and checks that the 141 signature came from the client account key associated with the 142 original request. 144 Because the DTN Node ID is used both for routing bundles between BP 145 agents and for multiplexing services within a BP agent, there is no 146 possibility to separate the ACME validation of a Node ID from normal 147 bundle handling on that same Node ID. This leaves Bundle 148 administrative records as a way to leave the Node ID unchanged while 149 disambiguating from normal service data bundles. 151 1.2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 In this document, several terms are shortened for the sake of 160 terseness. These terms are: 162 Challenge Request: This is a shortened form of the full "DTN Node ID 163 Challenge Request Object". It is a JSON object created by the 164 ACME server for challenge type "dtn-nodeid-01". 166 Challenge Response: This is a shortened form of the full "DTN Node 167 ID Challenge Response Object". It is a JSON object created by the 168 ACME client to authorize a challenge type "dtn-nodeid-01". 170 Challenge Bundle: This is a shortened form of the full "ACME Node ID 171 Validation Challenge Bundle". It is a Bundle created by the ACME 172 server to challenge a Node ID claim. 174 Response Bundle: This is a shortened form of the full "ACME Node ID 175 Validation Response Bundle". It is a Bundle created by the BP 176 agent managed by the ACME client to validate a Node ID claim. 178 1.3. Use of CDDL 180 This document defines CBOR structure using the Concise Data 181 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure 182 can be extracted from the XML version of this document using the 183 XPath expression: 185 '//sourcecode[@type="cddl"]' 187 The following initial fragment defines the top-level symbols of this 188 document's CDDL, which includes the example CBOR content. 190 start = acme-record / bundle / tstr 192 2. URI ACME Identifier 194 This specification is the first to make use of a URI to identify a 195 service for a certificate request in ACME. The URI-type identifier 196 is general purpose, and validating ownership of a URI requires a 197 specific purpose related to its "scheme" component. In this 198 document, the only purpose for which a URI ACME identifier is 199 validated is as a DTN Node ID (see Section 3), but other 200 specifications can define challenge types for other URI uses. 202 Identifiers of type "uri" MUST appear in an extensionRequest 203 attribute [RFC2985] requesting a subjectAltName extension of type 204 uniformResourceIdentifier having a value consistent with the 205 requirements of [RFC3986]. 207 Any identifier of type "uri" in a newOrder request MUST NOT have a 208 wildcard ("*") character in its value. 210 If an ACME server wishes to request proof that a user controls a URI, 211 it SHALL create an authorization with the identifier type "uri". The 212 value field of the identifier SHALL contain the textual form of the 213 URI as defined in Section 3 of [RFC3986]. The ACME server SHALL NOT 214 decode or attempt to dereference the URI value on its own. It is the 215 responsibility of a validation method to ensure the URI ownership via 216 scheme-specific means authorized by the ACME client. 218 An identifier for the Node ID of "dtn://example/" would be formatted 219 as: 221 {"type": "uri", "value": "dtn://example/"} 223 3. DTN Node ID Validation 225 The DTN Node ID validation method proves control over a Node ID by 226 requiring the ACME client to configure a BP agent to respond to 227 specific Challenge Bundles sent from the ACME server. The ACME 228 server validates control of the Node ID URI by verifying that 229 received Response Bundles correspond with the BP Node and client 230 account key being validated. 232 Similar to the ACME use case for validating email address ownership 233 [I-D.ietf-acme-email-smime], this challenge splits the token into two 234 parts. Each part reaches the client through a different channel: one 235 via the ACME channel in the challenge object, the other via the DTN 236 channel within the Challenge Bundle. The Key Authorization result 237 requires that the ACME client have access to the results of each 238 channel to get both parts of the token. 240 The DTN Node ID Challenge SHALL only be allowed for URIs usable as a 241 DTN Node ID, which are currently the schemes "dtn" and "ipn" as 242 defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node 243 ID validation, the ACME server SHALL define a challenge object in 244 accordance with Section 3.1. Once this challenge object is defined, 245 the ACME client may begin the validation. 247 To initiate a Node ID validation, the ACME client performs the 248 following steps: 250 1. The ACME client POSTs a newOrder or newAuthz request including 251 the identifier of type "uri" for the desired Node ID. From 252 either of these entry points an authorization for the "uri" type 253 is indicated by the ACME server. See Section 7.4 of [RFC8555] 254 for more details. 256 2. The ACME client obtains the challenge source Node ID and from the challenge object in accordance with Section 3.1. 259 3. The ACME client indicates to the BP agent the source and 260 challenge which is authorized for use. 262 4. The ACME client POSTs a challenge response to the challenge URL 263 on the ACME server accordance with Section 7.5.1 of [RFC8555]. 264 The payload object is constructed in accordance with Section 3.2. 266 5. The ACME client waits for indication from the BP agent that a 267 Challenge Bundle has been received, including its 268 payload. 270 6. The ACME client concatenates with (as 271 text strings) and computes the Key Authorization in accordance 272 with Section 8.1 of [RFC8555] using the full token and client 273 account key digest. 275 7. The ACME client indicates to the BP agent the SHA-256 digest of 276 the Key Authorization result, which results in a Response Bundle 277 being sent back to the ACME server in accordance with 278 Section 3.4. 280 8. The ACME client waits for the authorization to be finalized on 281 the ACME server in accordance with Section 7.5.1 of [RFC8555]. 283 9. Once the challenge is completed (successfully or not), the ACME 284 client indicates to the BP agent that the validation source and 285 is no longer usable. 287 The ACME server verifies the client's control over a Node ID by 288 performing the following steps: 290 1. The ACME server receives a newOrder or newAuthz request including 291 the identifier of type "uri", where the URI value is a Node ID. 293 2. The ACME server generates an authorization for the Node ID with 294 challenge type "dtn-nodeid-01" and a . 296 3. The ACME server sends one or more Challenge Bundles in accordance 297 with Section 3.3. Each challenge bundle SHALL contain a distinct 298 to be able to correlate with a response bundle. 299 Computing an expected Key Authorization digest is not necessary 300 until a response is received. 302 4. The ACME server waits for Response Bundle(s) for a limited 303 interval of time. A default response interval, used when the 304 challenge does not contain an RTT, SHOULD be a configurable 305 parameter of the ACME server. If the ACME client indicated an 306 RTT value in the challenge object, the response interval SHOULD 307 be twice the RTT (with limiting logic applied as described 308 below). The lower limit on response waiting time is network- 309 specific, but SHOULD NOT be shorter than one second. The upper 310 limit on response waiting time is network-specific, but SHOULD 311 NOT be longer than one minute (60 seconds) for a terrestrial-only 312 DTN. Responses are encoded in accordance with Section 3.4. 314 5. Once received and decoded, the ACME server checks the contents of 315 each Response Bundle in accordance with Section 3.5. After all 316 Challenge Bundles have either been responded to or timed-out, the 317 validation procedure is successful only if all responses are 318 successful. 320 An ACME server MAY send multiple challenges from different origins in 321 the DTN network to avoid possible on-path attacks, as recommended in 322 Section 10.2 of [RFC8555]. If responses are received from multiple 323 challenges, any response failure SHALL cause a failure of the overall 324 validation. Each response failure MAY be indicated to the ACME 325 client as a validation subproblem. 327 When responding to a Challenge Bundle, a BP agent SHALL send a single 328 Response Bundle in accordance with Section 3.4. A BP agent SHALL 329 respond to ACME challenges only within the interval of time, only for 330 the Node ID, and only for the validation token indicated by the ACME 331 client. A BP agent SHALL respond to multiple challenges with the 332 same parameters. These correspond with the ACME server validating 333 via multiple routing paths. 335 3.1. DTN Node ID Challenge Request Object 337 The DTN Node ID Challenge request object is defined by the ACME 338 server when it supports validating Node IDs. 340 The DTN Node ID Challenge request object has the following content: 342 type (required, string): The string "dtn-nodeid-01". 344 source (required, string): The source Node ID of bundles originating 345 at the ACME server as a text URI. 347 token-part2 (required, string): A random value that uniquely 348 identifies the challenge. This value MUST have at least 128 bits 349 of entropy. It MUST NOT contain any characters outside the 350 base64url alphabet as described in Section 5 of [RFC4648]. 351 Trailing '=' padding characters MUST be stripped. See [RFC4086] 352 for additional information on randomness requirements. 354 { 355 "type": "dtn-nodeid-01", 356 "url": "https://example.com/acme/chall/prV_B7yEyA4", 357 "source": "dtn://example-acme-server/", 358 "token-part2": "tPUZNY4ONIk6LxErRFEjVw" 359 } 360 The only over-the-wire data required by ACME for a Challenge Bundle 361 is a nonce token, split into two parts, but the response data needs a 362 client account key to generate the Key Authorization and its digest. 363 The client account key is kept within the ACME client, the BP agent 364 needs only the derived key thumbprint for its Response Bundle. 366 3.2. DTN Node ID Challenge Response Object 368 The DTN Node ID Challenge response object is defined by the ACME 369 client when it authorizes validation of a Node ID. Because a DTN has 370 the potential for significantly longer delays than a non-DTN network, 371 the ACME client is able to inform the ACME server if a particular 372 validation round-trip is expected to take longer than normal network 373 delays (on the order of seconds). 375 The DTN Node ID Challenge response object has the following content: 377 rtt (optional, number): An expected round-trip time (RTT), in 378 seconds, between sending a Challenge Bundle and receiving a 379 Response Bundle. This value is a hint to the ACME server for how 380 long to wait for responses but is not authoritative. The minimum 381 RTT value SHALL be zero. There is no special significance to 382 zero-value RTT, it simply indicates the response is expected in 383 less than the least significant unit used by the ACME client. 385 { 386 "rtt": 300.0 387 } 389 A challenge response is not sent until the BP agent has been 390 configured to properly respond to the challenge, so the RTT value is 391 meant to indicate any node-specific path delays expected to 392 encountered from the ACME server. Because there is no requirement on 393 the path (or paths) which bundles may traverse between the ACME 394 server and the BP agent, and the ACME server can attempt some path 395 diversity, the RTT value SHOULD be pessimistic. 397 3.3. ACME Node ID Validation Challenge Bundles 399 Each ACME Node ID Validation Challenge Bundle has parameters as 400 listed here: 402 Bundle Processing Control Flags: The primary block flags SHALL 403 indicate that the payload is an administrative record. The 404 primary block flags SHALL indicate that user application 405 acknowledgement is requested; this flag distinguishes the 406 Challenge Bundle from the Response Bundle. The primary block 407 flags MAY indicate that status reports are requested; such status 408 can be helpful to troubleshoot routing issues. 410 Destination EID: The Destination EID SHALL be identical to the Node 411 ID being validated. The ACME server SHOULD NOT perform URI 412 normalization on the Node ID given by the ACME client. 414 Source Node ID: The Source Node ID SHALL indicate the Node ID of the 415 ACME server performing the challenge. 417 Report-to Node ID: The Report-to Node ID SHALL indicate the Node ID 418 of the ACME server performing the challenge if status reports are 419 requested. 421 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 422 to the time at which the challenge was generated. The Lifetime 423 SHALL indicate the response interval for which ACME server will 424 accept responses to this challenge. 426 Administrative Record Type Code: Set to the ACME Node ID Validation 427 type code defined in Section 7.3. 429 Administrative Record Content: The Challenge Bundle administrative 430 record content SHALL consist of a CBOR map containing one pair. 431 The pair SHALL consist of key 1 with value of ACME challenge 432 token-part1, represented as a CBOR byte string. The token-part1 433 is a random value that uniquely identifies the challenge. This 434 value MUST have at least 128 bits of entropy. See [RFC4086] for 435 additional information on randomness requirements. 437 An example full Challenge Bundle is included in Appendix B.1 439 Challenge Bundles SHOULD be BIB-signed in accordance with 440 [I-D.ietf-dtn-bpsec] if the ACME server is capable of signing 441 bundles. BP agents SHALL refuse to respond to a Challenge Bundle 442 which is signed by a known ACME server but has an invalid signature. 443 Challenge Bundles SHOULD NOT be directly encrypted (by BCB or any 444 other method). 446 3.4. ACME Node ID Validation Response Bundles 448 Each ACME Node ID Validation Response Bundle has parameters as listed 449 here: 451 Bundle Processing Control Flags: The primary block flags SHALL 452 indicate that the payload is an administrative record. The 453 primary block flags SHALL NOT indicate that user application 454 acknowledgement is requested; this flag distinguishes the Response 455 Bundle from the Challenge Bundle. The primary block flags MAY 456 indicate that status reports are requested; such status can be 457 helpful to troubleshoot routing issues. 459 Destination EID: The Destination EID SHALL be identical to the 460 Source Node ID of the Challenge Bundle to which this response 461 corresponds. 463 Source Node ID: The Source Node ID SHALL be identical to the the 464 Destination EID of the Challenge Bundle to which this response 465 corresponds. 467 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 468 to the time at which the response was generated. The response 469 Lifetime SHALL indicate the response interval remaining if the 470 Challenge Bundle indicated a limited Lifetime. 472 Administrative Record Type Code: Set to the ACME Node ID Validation 473 type code defined in Section 7.3. 475 Administrative Record Content: The Response Bundle administrative 476 record content SHALL consist of a CBOR map containing two pairs. 477 One pair SHALL consist of key 1 with value of ACME challenge 478 token-part1, copied from the Request Bundle, represented as a CBOR 479 byte string. One pair SHALL consist of key 2 with value of the 480 SHA-256 digest [FIPS180-4] of the ACME Key Authorization in 481 accordance with Section 8.1 of [RFC8555], represented as a CBOR 482 byte string. 484 An example full Response Bundle is included in Appendix B.2 486 Response Bundles MAY be BIB-signed in accordance with 487 [I-D.ietf-dtn-bpsec] if the BP agent is capable of signing bundles. 488 A BIB on the bundle gives no more security than the Key Authorization 489 itself. Response Bundles SHOULD NOT be directly encrypted (by BCB or 490 any other method). 492 3.5. Response Bundle Checks 494 A proper Response Bundle meets all of the following criteria: 496 * The Response Bundle was received within the time interval allowed 497 for the challenge. 499 * The Response Bundle Source Node ID is identical to the Node ID 500 being validated. The comparison of Node IDs SHALL use the 501 comparison logic of [RFC3986] and scheme-based normalization of 502 those schemes specified in [I-D.ietf-dtn-bpbis]. 504 * The response payload contains the as sent in the 505 Challenge Bundle. The response payload contains the expected Key 506 Authorization digest computed by the ACME server. Because 507 multiple Challenge Bundles can be sent to validate the same Node 508 ID, the in the response is needed to correlate with 509 the expected Key Authorization digest. 511 Any of the failures above SHALL cause the validation to fail. Any of 512 the failures above SHOULD be indicated as subproblems to the ACME 513 client. 515 4. Certificate Request Profile 517 The ultimate purpose of this ACME validation is to allow a CA to 518 issue certificates following the profiles of Section 4.4.2 of 519 [I-D.ietf-dtn-tcpclv4] and [I-D.bsipos-dtn-bpsec-cose]. These 520 purposes are referred to here as bundle security certificates. 522 One common behavior of bundle security certificates are the use of 523 the Extended Key Usage key purpose "id-kp-bundleSecurity". Any CA 524 implementing the validation method defined in this document SHOULD 525 also support issuing certificates with the bundle security Extended 526 Key Usage. 528 4.1. Multiple Identity Claims 530 A single bundle security certificate request MAY contain a mixed set 531 of SAN claims, including combinations of "ip", "dns", and "uri" 532 claims. There is no restriction on how a certificate combines these 533 claims, but each claim MUST be validated by an ACME server to issue 534 such a certificate as part of an associated ACME order. This is no 535 different than the existing behavior of [RFC8555] but is mentioned 536 here to make sure that CA policy handles such situations; especially 537 related to validation failure of an identifier in the presence of 538 multiple identifiers. The specific use case of 539 [I-D.ietf-dtn-tcpclv4] allows, and for some network policies 540 requires, that a certificate authenticate both the DNS name of an 541 entity as well as the Node ID of the entity. 543 4.2. Generating Encryption-only or Signing-only Bundle Security 544 Certificates 546 ACME extensions specified in this document can be used to request 547 encryption-only or signing-only bundle security certificates. 549 In order to request signing only S/MIME certificate, the CSR MUST 550 include the key usage extension with digitalSignature and/or 551 nonRepudiation bits set and no other bits set. 553 In order to request encryption only S/MIME certificate, the CSR MUST 554 include the key usage extension with keyEncipherment or keyAgreement 555 bits set and no other bits set. 557 Presence of both of the above sets of key usage bits in the CSR, as 558 well as absence of key usage extension in the CSR, signals to ACME 559 server to issue an S/MIME certificate suitable for both signing and 560 encryption. 562 5. Implementation Status 564 [NOTE to the RFC Editor: please remove this section before 565 publication, as well as the reference to [RFC7942] and 566 [github-acme-dtnnodeid].] 568 This section records the status of known implementations of the 569 protocol defined by this specification at the time of posting of this 570 Internet-Draft, and is based on a proposal described in [RFC7942]. 571 The description of implementations in this section is intended to 572 assist the IETF in its decision processes in progressing drafts to 573 RFCs. Please note that the listing of any individual implementation 574 here does not imply endorsement by the IETF. Furthermore, no effort 575 has been spent to verify the information presented here that was 576 supplied by IETF contributors. This is not intended as, and must not 577 be construed to be, a catalog of available implementations or their 578 features. Readers are advised to note that other implementations can 579 exist. 581 An example implementation of the this draft of ACME has been created 582 as a GitHub project [github-acme-dtnnodeid] and is intended to use as 583 a proof-of-concept and as a possible source of interoperability 584 testing. This example implementation only constructs encoded bundles 585 and does not attempt to provide a full BP Agent interface. 587 6. Security Considerations 589 This section separates security considerations into threat categories 590 based on guidance of BCP 72 [RFC3552]. 592 6.1. Threat: Passive Leak of Validation Data 594 Because this challenge mechanism is used to bootstrap security 595 between DTN Nodes, the challenge and its response are likely to be 596 transferred in plaintext. The ACME data itself is a random token 597 (nonce) and a cryptographic signature, so there is no sensitive data 598 to be leaked within the Node ID Validation bundle exchange. 600 Under certain circumstances, when BPSEC key material is available to 601 the BP agent managed by the ACME client, the use of a BCB for the 602 Request Bundle and/or Response Bundle can give additional 603 confidentiality to the bundle metadata. This is not expected to be a 604 general use case, as the whole point of ACME is to validate 605 identifiers of untrusted client services. 607 6.2. Threat: BP Node Impersonation 609 As described in Section 8.1 of [RFC8555], it is possible for an 610 active attacker to alter data on both ACME client channel and the DTN 611 validation channel. 613 One way to mitigate single-path on-path attacks is to attempt 614 validation of the same Node ID via multiple bundle routing paths, as 615 recommended in Section 3. It is not a trivial task to guarantee 616 bundle routing though, so more advanced techniques such as onion 617 routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) 618 could be employed. 620 Under certain circumstances, when BPSEC key material is available to 621 the BP agent managed by the ACME client, the use of a BIB signature 622 on the Response Bundle can give additional assurance that the 623 response is coming from a valid BP agent. 625 6.3. Threat: Denial of Service 627 The behaviors described in this section all amount to a potential 628 denial-of-service to a BP agent. 630 A malicious entity can continually send ACME Node ID challenges to a 631 BP agent. The victim BP agent can ignore ACME challenges which do 632 not conform to the specific time interval and challenge token for 633 which the ACME client has informed the BP agent that challenges are 634 expected. The victim BP agent can require all Challenge Bundles to 635 be BIB-signed to ensure authenticity of the challenge. 637 Similar to other validation methods, an ACME server validating a DTN 638 Node ID could be used as a denial of service amplifier. For this 639 reason any ACME server can rate-limit validation activities for 640 individual clients and individual certificate requests. 642 7. IANA Considerations 644 This specification adds to the ACME registry and BP registry for this 645 behavior. 647 7.1. ACME Identifier Type 649 Within the "Automated Certificate Management Environment (ACME) 650 Protocol" registry [IANA-ACME], the following entry has been added to 651 the "ACME Identifier Types" sub-registry. 653 +=======+==================================+ 654 | Label | Reference | 655 +=======+==================================+ 656 | uri | This specification and [RFC3986] | 657 +-------+----------------------------------+ 659 Table 1 661 7.2. ACME Validation Method 663 Within the "Automated Certificate Management Environment (ACME) 664 Protocol" registry [IANA-ACME], the following entry has been added to 665 the "ACME Validation Methods" sub-registry. 667 +===============+=================+======+====================+ 668 | Label | Identifier Type | ACME | Reference | 669 +===============+=================+======+====================+ 670 | dtn-nodeid-01 | uri | Y | This specification | 671 +---------------+-----------------+------+--------------------+ 673 Table 2 675 7.3. BP Bundle Administrative Record Types 677 Within the "Bundle Protocol" registry [IANA-BP], the following entry 678 has been added to the "Bundle Administrative Record Types" sub- 679 registry. [NOTE to the RFC Editor: For RFC5050 compatibility this 680 value needs to be no larger than 15, but such compatibility is not 681 needed. BPbis has no upper limit on this code point value.] 682 +=======+=========================+====================+ 683 | Value | Description | Reference | 684 +=======+=========================+====================+ 685 | TBD | ACME Node ID Validation | This specification | 686 +-------+-------------------------+--------------------+ 688 Table 3 690 8. Acknowledgments 692 This specification is based on DTN use cases related to PKIX 693 certificate generation. 695 9. References 697 9.1. Normative References 699 [FIPS180-4] 700 National Institute of Standards and Technology, "Secure 701 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 702 . 705 [IANA-ACME] 706 IANA, "Automated Certificate Management Environment (ACME) 707 Protocol", . 709 [IANA-BP] IANA, "Bundle Protocol", 710 . 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, 714 DOI 10.17487/RFC2119, March 1997, 715 . 717 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 718 Classes and Attribute Types Version 2.0", RFC 2985, 719 DOI 10.17487/RFC2985, November 2000, 720 . 722 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 723 Text on Security Considerations", BCP 72, RFC 3552, 724 DOI 10.17487/RFC3552, July 2003, 725 . 727 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 728 Resource Identifier (URI): Generic Syntax", STD 66, 729 RFC 3986, DOI 10.17487/RFC3986, January 2005, 730 . 732 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 733 "Randomness Requirements for Security", BCP 106, RFC 4086, 734 DOI 10.17487/RFC4086, June 2005, 735 . 737 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 738 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 739 . 741 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 742 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 743 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 744 April 2007, . 746 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 747 Housley, R., and W. Polk, "Internet X.509 Public Key 748 Infrastructure Certificate and Certificate Revocation List 749 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 750 . 752 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 753 Code: The Implementation Status Section", BCP 205, 754 RFC 7942, DOI 10.17487/RFC7942, July 2016, 755 . 757 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 758 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 759 May 2017, . 761 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 762 Kasten, "Automatic Certificate Management Environment 763 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 764 . 766 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 767 Definition Language (CDDL): A Notational Convention to 768 Express Concise Binary Object Representation (CBOR) and 769 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 770 June 2019, . 772 [I-D.ietf-dtn-bpbis] 773 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 774 Version 7", Work in Progress, Internet-Draft, draft-ietf- 775 dtn-bpbis-31, 25 January 2021, 776 . 778 [I-D.ietf-dtn-bpsec] 779 Birrane, E. and K. McKeever, "Bundle Protocol Security 780 Specification", Work in Progress, Internet-Draft, draft- 781 ietf-dtn-bpsec-26, 8 January 2021, 782 . 784 9.2. Informative References 786 [I-D.ietf-acme-email-smime] 787 Melnikov, A., "Extensions to Automatic Certificate 788 Management Environment for end-user S/MIME certificates", 789 Work in Progress, Internet-Draft, draft-ietf-acme-email- 790 smime-13, 20 November 2020, . 793 [I-D.ietf-dtn-bibect] 794 Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in 795 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 796 February 2020, 797 . 799 [I-D.ietf-dtn-tcpclv4] 800 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 801 Tolerant Networking TCP Convergence Layer Protocol Version 802 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 803 tcpclv4-24, 7 December 2020, 804 . 806 [I-D.bsipos-dtn-bpsec-cose] 807 Sipos, B., "DTN Bundle Protocol Security COSE Security 808 Contexts", Work in Progress, Internet-Draft, draft-bsipos- 809 dtn-bpsec-cose-04, 22 December 2020, 810 . 813 [github-acme-dtnnodeid] 814 Sipos, B., "ACME Node ID Example Implementation", 815 . 817 Appendix A. Administrative Record Types CDDL 819 [NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the 820 "ACME Node ID Validation" administrative record type code.] 822 The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles 823 is: 825 ; All ACME records have the same structure 826 $admin-record /= [0xFFFF, acme-record] 827 acme-record = { 828 token-part1, 829 ? key-auth-digest ; present for Response Bundles 830 } 831 token-part1 = (1 => bstr) 832 key-auth-digest = (2 => bstr) 834 Appendix B. Example Bundles 836 [NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced 837 by the "ACME Node ID Validation" administrative record type code.] 839 This example is a bundle exchange for the ACME server with Node ID 840 "dtn://acme-server/" performing a verification for ACME client Node 841 ID "dtn://acme-client/". The example bundles use no block CRC or 842 BPSec integrity, which is for simplicity and is not recommended for 843 normal use. The provided figures are extended diagnostic notation 844 [RFC8610]. 846 For this example the ACME client key thumbprint has the base64url 847 encoded value of: 849 "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 851 And the ACME-server generated token-part2 (transported to the ACME 852 client via HTTPS) has the base64url-encoded value of: 854 "tPUZNY4ONIk6LxErRFEjVw" 856 B.1. Challenge Bundle 858 For the single challenge bundle in this example, the token-part1 859 (transported as byte string via BP) has the base64url-encoded value 860 of: 862 "p3yRYFU4KxwQaHQjJ2RdiQ" 863 The minimal-but-valid Challenge Bundle is shown in Figure 1. This 864 challenge requires that the ACME client respond within a 60 second 865 time window. 867 [ 868 [ 869 7, / BP version / 870 0x22, / flags: user-app-ack, payload-is-an-admin-record / 871 0, / CRC type: none / 872 [1, "//acme-client/"], / destination / 873 [1, "//acme-server/"], / source / 874 [1, "//acme-server/"], / report-to / 875 [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 / 876 60000 / lifetime: 60s / 877 ], 878 [ 879 1, / block type code / 880 1, / block number / 881 0, / flags / 882 0, / CRC type: none / 883 <<[ / type-specific data / 884 0xFFFF, / record-type-code / 885 { / record-content / 886 1: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-part1 / 887 } 888 ]>> 889 ] 890 ] 892 Figure 1: Example Challenge Bundle 894 B.2. Response Bundle 896 When the tokens are combined with the key fingerprint, the full Key 897 Authorization value (a single string split across lines for 898 readability) is: 900 "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 902 The minimal-but-valid Response Bundle is shown in Figure 2. This 903 response indicates that there is 30 seconds remaining in the response 904 time window. 906 [ 907 [ 908 7, / BP version / 909 0x02, / flags: payload-is-an-admin-record / 910 0, / CRC type: none / 911 [1, "//acme-server/"], / destination / 912 [1, "//acme-client/"], / source / 913 [1, 0], / report-to: none / 914 [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 / 915 30000 / lifetime: 30s / 916 ], 917 [ 918 1, / block type code / 919 1, / block number / 920 0, / flags / 921 0, / CRC type: none / 922 <<[ / type-specific data / 923 0xFFFF, / record-type-code / 924 { / record-content / 925 1: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-part1 / 926 2: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' / key auth. digest / 927 } 928 ]>> 929 ] 930 ] 932 Figure 2: Example Response Bundle 934 Author's Address 936 Brian Sipos 937 RKF Engineering Solutions, LLC 938 7500 Old Georgetown Road 939 Suite 1275 940 Bethesda, MD 20814-6198 941 United States of America 943 Email: BSipos@rkf-eng.com