idnits 2.17.1 draft-ietf-acme-dtnnodeid-00.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 is 1 instance of too long lines in the document, the longest one being 2 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 (26 August 2020) is 1339 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 803 -- Looks like a reference, but probably isn't: '40' on line 803 == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-26 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-22 == Outdated reference: A later version (-14) exists of draft-ietf-acme-email-smime-08 == Outdated reference: A later version (-28) exists of draft-ietf-dtn-tcpclv4-21 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking B. Sipos 3 Internet-Draft RKF Engineering 4 Intended status: Experimental 26 August 2020 5 Expires: 27 February 2021 7 Automated Certificate Management Environment (ACME) Delay-Tolerant 8 Networking (DTN) Node ID Validation Extension 9 draft-ietf-acme-dtnnodeid-00 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 27 February 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Authorization Strategy . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 4 57 4. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 5 58 4.1. DTN Node ID Challenge Request Object . . . . . . . . . . 7 59 4.2. DTN Node ID Challenge Response Object . . . . . . . . . . 8 60 4.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 8 61 4.4. ACME Node ID Validation Response Bundles . . . . . . . . 9 62 4.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 10 63 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 6.1. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 11 66 6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 12 67 6.3. Threat: Denial of Service . . . . . . . . . . . . . . . . 12 68 6.4. Multiple Certificate Claims . . . . . . . . . . . . . . . 12 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 13 71 7.2. ACME Validation Method . . . . . . . . . . . . . . . . . 13 72 7.3. BP Bundle Administrative Record Types . . . . . . . . . . 13 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 16 78 Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 17 79 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 17 80 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 17 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 Although the original purpose of the Automatic Certificate Management 86 Environment (ACME) [RFC8555] was to allow Public Key Infrastructure 87 Using X.509 (PKIX) certificate authorities to validate network domain 88 names of clients, the same mechanism can be used to validate any of 89 the subject claims supported by the PKIX profile [RFC5280]. 91 In the case of this specification, the claim being validated is a 92 Subject Alternative Name (SAN) of type Uniform Resource Identifier 93 (URI) used to represent the Node ID of a Delay-Tolerant Networking 94 (DTN) Node. A DTN Node ID is a URI with a specific set of allowed 95 schemes, and determines how bundles are routed within a DTN. 96 Currently the schemes "dtn" and "ipn" as defined in 97 [I-D.ietf-dtn-bpbis] are valid for a Node ID. 99 Once an ACME server validates a Node ID, either as a pre- 100 authorization of the "uri" or as one of the authorizations of an 101 order containing a "uri", the client can finalize the order using an 102 associated certificate signing request. Because a single order can 103 contain multiple identifiers of multiple types, there can be 104 operational issues for a client attempting to, and possibly failing 105 to, validate those multiple identifiers as described in Section 6.4. 106 Once a certificate is issued for a Node ID, how the ACME client 107 configures the BP agent with the new certificate is an implementation 108 matter. 110 The scope and behavior of this validation mechanism is similar to 111 that of secured email validation of [I-D.ietf-acme-email-smime]. For 112 that reason some token splitting terminology in this document is 113 taken from the email specification. 115 1.1. Authorization Strategy 117 The basic unit of data exchange in a DTN is a Bundle 118 [I-D.ietf-dtn-bpbis], which consists of a data payload with 119 accompanying metadata. A Node ID is used to identify the source and 120 destination of a Bundle and is used for routing through intermediate 121 nodes. More detailed descriptions of the rationale and capabilities 122 of these networks can be found in "Delay-Tolerant Network 123 Architecture" [RFC4838]. 125 When a ACME client requests a pre-authorization or an order with a 126 "uri" which could be used as a DTN Node ID, the ACME server offers a 127 challenge type to validate that Node ID. If the ACME client attempts 128 the authorization challenge to validate a Node ID, the ACME server 129 sends an ACME Node ID Validation Challenge Bundle with a destination 130 of the Node ID being validated. The BP agent on that node receives 131 the Challenge Bundle, generates an ACME signature, and sends an ACME 132 Node ID Validation Response Bundle with the signature. Finally, the 133 ACME server receives the Response Bundle and checks that the 134 signature came from the client account key associated with the 135 original request. 137 Because the DTN Node ID is used both for routing bundles between BP 138 agents and for multiplexing services within a BP agent, there is no 139 possibility to separate the ACME validation of a Node ID from normal 140 bundle handling on that same Node ID. This leaves Bundle 141 administrative records as a way to leave the Node ID unchanged while 142 disambiguating from normal service data bundles. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 In this document, several terms are shortened for the sake of 153 terseness. These terms are: 155 Challenge Request: This is a shortened form of the full "DTN Node ID 156 Challenge Request Object". It is a JSON object created by the 157 ACME server for challenge type "dtn-nodeid-01". 159 Challenge Response: This is a shortened form of the full "DTN Node 160 ID Challenge Response Object". It is a JSON object created by the 161 ACME client to authorize a challenge type "dtn-nodeid-01". 163 Challenge Bundle: This is a shortened form of the full "ACME Node ID 164 Validation Challenge Bundle". It is a Bundle created by the ACME 165 server to challenge a Node ID claim. 167 Response Bundle: This is a shortened form of the full "ACME Node ID 168 Validation Response Bundle". It is a Bundle created by the BP 169 agent managed by the ACME client to validate a Node ID claim. 171 3. URI ACME Identifier 173 This specification is the first to make use of a URI to identify a 174 service for a certificate request in ACME. The URI-type identifier 175 is general purpose, and validating ownership of a URI requires a 176 specific purpose related to its "scheme" component. In this 177 document, the only purpose for which a URI ACME identifier is 178 validated is as a DTN Node ID (see Section 4), but other 179 specifications can define challenge types for other URI uses. 181 Identifiers of type "uri" MUST appear in an extensionRequest 182 attribute [RFC2985] requesting a subjectAltName extension of type 183 uniformResourceIdentifier having a value consistent with the 184 requirements of [RFC3986]. 186 If an ACME server wishes to request proof that a user controls a URI, 187 it SHALL create an authorization with the identifier type "uri". The 188 value field of the identifier SHALL contain the textual form of the 189 URI as defined in Section 3 of [RFC3986]. The ACME server SHALL NOT 190 decode or attempt to dereference the URI value on its own. It is the 191 responsibility of a validation method to ensure the URI ownership via 192 scheme-specific means authorized by the ACME client. 194 An identifier for the URL "dtn://example/service" would be formatted 195 as: 197 {"type": "uri", "value": "dtn://example/service"} 199 4. DTN Node ID Validation 201 The DTN Node ID validation method proves control over a Node ID by 202 requiring the ACME client to configure a BP agent to respond to 203 specific Challenge Bundles sent from the ACME server. The ACME 204 server validates control of the Node ID URI by verifying that 205 received Response Bundles correspond with the BP Node and client 206 account key being validated. 208 Similar to the ACME use case for validating email address ownership 209 [I-D.ietf-acme-email-smime], this challenge splits the token into two 210 parts. Each part reaches the client through a different channel: one 211 via the ACME channel in the challenge object, the other via the DTN 212 channel within the Challenge Bundle. The Key Authorization result 213 requires that the ACME client have access to the results of each 214 channel to get both parts of the token. 216 The DTN Node ID Challenge SHALL only be allowed for URIs usable as a 217 DTN Node ID, which are currently the schemes "dtn" and "ipn" as 218 defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node 219 ID validation, the ACME server SHALL define a challenge object in 220 accordance with Section 4.1. Once this challenge object is defined, 221 the ACME client may begin the validation. 223 To initiate a Node ID validation, the ACME client performs the 224 following steps: 226 1. The ACME client obtains the challenge from the 227 challenge object in accordance with Section 4.1. 229 2. The ACME client indicates to the BP agent the challenge which is authorized for use. 232 3. The ACME client POSTs a challenge response to the challenge URL 233 on the ACME server accordance with Section 7.5.1 of [RFC8555]. 234 The payload object is constructed in accordance with Section 4.2. 236 4. The ACME client waits for indication from the BP agent that a 237 Challenge Bundle has been received, including its 238 payload. 240 5. The ACME client concatenates with and 241 computes the Key Authorization in accordance with Section 8.1 of 242 [RFC8555] using the full token and client account key. 244 6. The ACME client indicates to the BP agent the Key Authorization 245 result, which will result in a Response Bundle being sent back to 246 the ACME server. 248 7. The ACME client waits for the authorization to be finalized on 249 the ACME server in accordance with Section 7.5.1 of [RFC8555]. 251 8. Once the challenge is completed (successfully or not), the ACME 252 client indicates to the BP agent that the validation is no longer usable. 255 Upon receiving a challenge response from an ACME client, the ACME 256 server verifies the client's control over the Node ID by performing 257 the following steps: 259 1. The ACME server generates the two-part challenge token and 260 computes the expected Key Authorization in accordance with 261 Section 8.1 of [RFC8555] using the concatenated token and client 262 account key. 264 2. The ACME server sends one or more Challenge Bundles in accordance 265 with Section 4.3. 267 3. The ACME server waits for Response Bundle(s) for a limited 268 interval of time. A default response interval, used when the 269 challenge does not contain an RTT, SHOULD be a configurable 270 parameter of the ACME server. If the ACME client indicated an 271 RTT value in the challenge object, the response interval SHOULD 272 be twice the RTT (with limiting logic applied as described 273 below). The lower limit on response waiting time is network- 274 specific, but SHOULD NOT be shorter than one second. The upper 275 limit on response waiting time is network-specific, but SHOULD 276 NOT be longer than one minute (60 seconds) for a terrestrial-only 277 DTN. Responses are encoded in accordance with Section 4.4. 279 4. Once received and decoded, the ACME server checks the contents of 280 each Response Bundle in accordance with Section 4.5. After all 281 Challenge Bundles have either been responded to or timed-out, the 282 validation procedure is successful only if all responses are 283 successful. 285 An ACME server MAY send multiple challenges from different origins in 286 the DTN network to avoid possible man-in-the-middle (MitM) attacks, 287 as recommended in Section 10.2 of [RFC8555]. If responses are 288 received from multiple challenges, any response failure SHALL cause a 289 failure of the overall validation. Each response failure MAY be 290 indicated to the ACME client as a validation subproblem. 292 When responding to a Challenge Bundle, a BP agent SHALL send a single 293 Response Bundle in accordance with Section 4.4. A BP agent SHALL 294 respond to ACME challenges only within the interval of time, only for 295 the Node ID, and only for the validation token indicated by the ACME 296 client. A BP agent SHALL respond to multiple challenges with the 297 same parameters. These correspond with the ACME server validating 298 via multiple routing paths. 300 4.1. DTN Node ID Challenge Request Object 302 The DTN Node ID Challenge request object is defined by the ACME 303 server when it supports validating Node IDs. 305 The DTN Node ID Challenge request object has the following content: 307 type (required, string): The string "dtn-nodeid-01". 309 token-part2 (required, string): A random value that uniquely 310 identifies the challenge. This value MUST have at least 64 bits 311 of entropy. It MUST NOT contain any characters outside the 312 base64url alphabet as described in Section 5 of [RFC4648]. 313 Trailing '=' padding characters MUST be stripped. See [RFC4086] 314 for additional information on randomness requirements. 316 { 317 "type": "dtn-nodeid-01", 318 "url": "https://example.com/acme/chall/prV_B7yEyA4", 319 "status": "pending", 320 "token-part2": "qXjSp7npR2Y" 321 } 322 The only over-the-wire data required by ACME for a Challenge Bundle 323 is a nonce token, but the response data needs a client account key to 324 generate the Key Authorization. The client account key is kept 325 within the ACME client, the BP agent needs only the derived Key 326 Authorization for its Response Bundle. 328 4.2. DTN Node ID Challenge Response Object 330 The DTN Node ID Challenge response object is defined by the ACME 331 client when it authorizes validation of a Node ID. Because a DTN has 332 the potential for significantly longer delays than a non-DTN network, 333 the ACME client is able to inform the ACME server if a particular 334 validation round-trip is expected to take longer than normal network 335 delays (on the order of seconds). 337 The DTN Node ID Challenge response object has the following content: 339 rtt (optional, number): An expected round-trip time (RTT), in 340 seconds, between sending a Challenge Bundle and receiving a 341 Response Bundle. This value is a hint to the ACME server for how 342 long to wait for responses but is not authoritative. The minimum 343 RTT value SHALL be zero. There is no special significance to 344 zero-value RTT, it simply indicates the response is expected in 345 less than the least significant unit used by the ACME client. 347 { 348 "rtt": 300.0 349 } 351 A challenge response is not sent until the BP agent has been 352 configured to properly respond to the challenge, so the RTT value is 353 meant to indicate any node-specific path delays expected to 354 encountered from the ACME server. Because there is no requirement on 355 the path (or paths) which bundles may traverse between the ACME 356 server and the BP agent, and the ACME server is likely to attempt 357 some path diversity, the RTT value SHOULD be pessimistic. 359 4.3. ACME Node ID Validation Challenge Bundles 361 Each ACME Node ID Validation Challenge Bundle has parameters as 362 listed here: 364 Bundle Processing Control Flags: The payload SHALL be indicated as 365 an administrative record. 367 Destination EID: The Destination EID SHALL be identical to the Node 368 ID being validated. The ACME server SHOULD NOT perform URI 369 normalization on the Node ID given by the ACME client. 371 Source Node EID: The Source Node EID SHALL indicate the Endpoint ID 372 of the ACME server performing the challenge. 374 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 375 to the time at which the challenge was generated. The Lifetime 376 SHALL indicate the response interval for which ACME server will 377 accept responses to this challenge. 379 Administrative Record Type Code: Set to the ACME Node ID Validation 380 type code defined by this specification. 382 Administrative Record Content: The ACME challenge administrative 383 record content SHALL consist of a CBOR array with two elements. 384 The first element SHALL be a challenge indicator value 1, 385 represented as a CBOR unsigned integer. The second element SHALL 386 be the ACME challenge token-part1, represented as a CBOR text 387 string. The token-part1 is a random value that uniquely 388 identifies the challenge. This value MUST have at least 64 bits 389 of entropy. See [RFC4086] for additional information on 390 randomness requirements. 392 An ACME challenge administrative record would have CBOR diagnostic 393 notation as: 395 [ 396 1, / challenge indicator / 397 "LVMo24VdNAw" / token-part1 / 398 ] 400 Challenge Bundles SHOULD be BIB-signed in accordance with 401 [I-D.ietf-dtn-bpsec] if the ACME server is capable of signing 402 bundles. BP agents MAY refuse to respond to a Challenge Bundle which 403 is signed by a known ACME server but has an invalid signature. 404 Challenge Bundles SHOULD NOT be directly encrypted (by BCB or any 405 other method). 407 4.4. ACME Node ID Validation Response Bundles 409 Each ACME Node ID Validation Response Bundle has parameters as listed 410 here: 412 Bundle Processing Control Flags: The payload SHALL be indicated as 413 an administrative record. 415 Destination EID: The Destination EID SHALL be identical to the 416 Source Node EID of the Challenge Bundle to which this response 417 corresponds. 419 Source Node EID: The Source Node EID SHALL be identical to the the 420 Destination EID of the Challenge Bundle to which this response 421 corresponds. 423 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 424 to the time at which the response was generated. The response 425 Lifetime SHALL indicate the response interval remaining if the 426 Challenge Bundle indicated a limited Lifetime. 428 Administrative Record Type Code: Set to the ACME Node ID Validation 429 type code defined by this specification. 431 Administrative Record Content: The ACME response administrative 432 record content SHALL consist of a CBOR array with two elements. 433 The first element SHALL be a response indicator value 2, 434 represented as a CBOR unsigned integer. The second element SHALL 435 be the ACME Key Authorization in accordance with Section 8.1 of 436 [RFC8555], represented as a CBOR text string. 438 An ACME response administrative record would have CBOR diagnostic 439 notation (truncated for terseness) as: 441 [ 442 2, / response indicator / 443 "qXjSp7npR2YtUyjbhV00DA.9jg46WB3...fm21mqTI" / key authorization / 444 ] 446 Response Bundles MAY be BIB-signed in accordance with 447 [I-D.ietf-dtn-bpsec] if the BP agent is capable of signing bundles. 448 A BIB on the bundle gives no more security than the Key Authorization 449 itself. Response Bundles SHOULD NOT be directly encrypted (by BCB or 450 any other method). 452 4.5. Response Bundle Checks 454 A proper Response Bundle meets all of the following criteria: 456 * The Response Bundle was received within the time interval allowed 457 for the challenge. 459 * The Response Bundle Source Node ID is identical to the Node ID 460 being validated. The comparison of Node IDs SHALL use the 461 comparison logic of [RFC3986] and scheme-based normalization of 462 those schemes specified in [I-D.ietf-dtn-bpbis]. 464 * The response payload contains the expected Key Authorization 465 computed by the ACME server. 467 Any of the failures above SHALL cause the validation to fail. Any of 468 the failures above SHOULD be indicated as subproblems to the ACME 469 client. 471 5. Implementation Status 473 [NOTE to the RFC Editor: please remove this section before 474 publication, as well as the reference to [RFC7942] and 475 [github-acme-dtnnodeid].] 477 This section records the status of known implementations of the 478 protocol defined by this specification at the time of posting of this 479 Internet-Draft, and is based on a proposal described in [RFC7942]. 480 The description of implementations in this section is intended to 481 assist the IETF in its decision processes in progressing drafts to 482 RFCs. Please note that the listing of any individual implementation 483 here does not imply endorsement by the IETF. Furthermore, no effort 484 has been spent to verify the information presented here that was 485 supplied by IETF contributors. This is not intended as, and must not 486 be construed to be, a catalog of available implementations or their 487 features. Readers are advised to note that other implementations can 488 exist. 490 An example implementation of the this draft of ACME has been created 491 as a GitHub project [github-acme-dtnnodeid] and is intended to use as 492 a proof-of-concept and as a possible source of interoperability 493 testing. This example implementation only constructs encoded bundles 494 and does not attempt to provide a full BP Agent interface. 496 6. Security Considerations 498 This section separates security considerations into threat categories 499 based on guidance of BCP 72 [RFC3552]. 501 6.1. Threat: Passive Leak of Bundle Data 503 Because this challenge mechanism is used to bootstrap security 504 between DTN Nodes, the challenge and its response are likely to be 505 transferred in plaintext. The ACME data itself is a random token 506 (nonce) and a cryptographic signature, so there is no sensitive data 507 to be leaked within the Node ID Validation bundle exchange. 509 Under certain circumstances, when BPSEC key material is available to 510 the BP agent managed by the ACME client, the use of a BCB for the 511 Request Bundle and/or Response Bundle can give additional 512 confidentiality to the bundle metadata. This is not expected to be a 513 general use case, as the whole point of ACME is to validate 514 identifiers of untrusted client services. 516 6.2. Threat: BP Node Impersonation 518 As described in Section 8.1 of [RFC8555], it is possible for an 519 active attacker to alter data on both ACME client channel and the DTN 520 validation channel. 522 One way to mitigate single-path MitM attacks is to attempt validation 523 of the same Node ID via multiple bundle routing paths, as recommended 524 in Section 4. It is not a trivial task to guarantee bundle routing 525 though, so more advanced techniques such as onion routing (using 526 bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) could be 527 employed. 529 Under certain circumstances, when BPSEC key material is available to 530 the BP agent managed by the ACME client, the use of a BIB signature 531 on the Response Bundle can give additional assurance that the 532 response is coming from a valid BP agent. 534 6.3. Threat: Denial of Service 536 The behaviors described in this section all amount to a potential 537 denial-of-service to a BP agent. 539 A malicious entity can continually send ACME Node ID challenges to a 540 BP agent. The victim BP agent can ignore ACME challenges which do 541 not conform to the specific time interval and challenge token for 542 which the ACME client has informed the BP agent that challenges are 543 expected. The victim BP agent can require all Challenge Bundles to 544 be BIB-signed to ensure authenticity of the challenge. 546 Similar to other validation methods, an ACME server validating a DTN 547 Node ID could be used as a denial of service amplifier. For this 548 reason any ACME server can rate-limit validation activities for 549 individual clients and individual certificate requests. 551 6.4. Multiple Certificate Claims 553 A single certificate request can contain a mixed set of SAN claims, 554 including combinations of "dns" and "uri" claims. There is no 555 restriction on how a certificate combines these claims, but each 556 claim needs to be validated to issue such a certificate as part of an 557 associated ACME order. This is no different than the existing 558 behavior of [RFC8555] but is mentioned here to make sure that CA 559 policy handles such situations; especially related to validation 560 failure of an identifier in the presence of multiple identifiers. 561 The specific use case of [I-D.ietf-dtn-tcpclv4] allows, and for some 562 network policies requires, that a certificate authenticate both the 563 DNS name of an entity as well as the Node ID of the entity. 565 7. IANA Considerations 567 This specification adds to the ACME registry and BP registry for this 568 behavior. 570 7.1. ACME Identifier Type 572 Within the "Automated Certificate Management Environment (ACME) 573 Protocol" registry [IANA-ACME], the following entry has been added to 574 the "ACME Identifier Types" sub-registry. 576 +=======+====================+ 577 | Label | Reference | 578 +=======+====================+ 579 | uri | This specification | 580 +-------+--------------------+ 582 Table 1 584 7.2. ACME Validation Method 586 Within the "Automated Certificate Management Environment (ACME) 587 Protocol" registry [IANA-ACME], the following entry has been added to 588 the "ACME Validation Methods" sub-registry. 590 +===============+=================+======+====================+ 591 | Label | Identifier Type | ACME | Reference | 592 +===============+=================+======+====================+ 593 | dtn-nodeid-01 | uri | Y | This specification | 594 +---------------+-----------------+------+--------------------+ 596 Table 2 598 7.3. BP Bundle Administrative Record Types 600 Within the "Bundle Protocol" registry [IANA-BP], the following entry 601 has been added to the "Bundle Administrative Record Types" sub- 602 registry. [NOTE to the RFC Editor: For RFC5050 compatibility this 603 value needs to be no larger than 15, but such compatibility is not 604 needed. BPbis has no upper limit on this code point value.] 606 +=======+=========================+====================+ 607 | Value | Description | Reference | 608 +=======+=========================+====================+ 609 | TBD | ACME Node ID Validation | This specification | 610 +-------+-------------------------+--------------------+ 612 Table 3 614 8. Acknowledgments 616 This specification is based on DTN use cases related to PKIX 617 certificate generation. 619 9. References 621 9.1. Normative References 623 [IANA-ACME] 624 IANA, "Automated Certificate Management Environment (ACME) 625 Protocol", . 627 [IANA-BP] IANA, "Bundle Protocol", 628 . 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, 632 DOI 10.17487/RFC2119, March 1997, 633 . 635 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 636 Classes and Attribute Types Version 2.0", RFC 2985, 637 DOI 10.17487/RFC2985, November 2000, 638 . 640 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 641 Text on Security Considerations", BCP 72, RFC 3552, 642 DOI 10.17487/RFC3552, July 2003, 643 . 645 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 646 Resource Identifier (URI): Generic Syntax", STD 66, 647 RFC 3986, DOI 10.17487/RFC3986, January 2005, 648 . 650 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 651 "Randomness Requirements for Security", BCP 106, RFC 4086, 652 DOI 10.17487/RFC4086, June 2005, 653 . 655 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 656 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 657 . 659 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 660 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 661 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 662 April 2007, . 664 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 665 Housley, R., and W. Polk, "Internet X.509 Public Key 666 Infrastructure Certificate and Certificate Revocation List 667 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 668 . 670 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 671 Code: The Implementation Status Section", BCP 205, 672 RFC 7942, DOI 10.17487/RFC7942, July 2016, 673 . 675 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 676 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 677 May 2017, . 679 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 680 Kasten, "Automatic Certificate Management Environment 681 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 682 . 684 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 685 Definition Language (CDDL): A Notational Convention to 686 Express Concise Binary Object Representation (CBOR) and 687 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 688 June 2019, . 690 [I-D.ietf-dtn-bpbis] 691 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 692 Version 7", Work in Progress, Internet-Draft, draft-ietf- 693 dtn-bpbis-26, 28 July 2020, 694 . 696 [I-D.ietf-dtn-bpsec] 697 Birrane, E. and K. McKeever, "Bundle Protocol Security 698 Specification", Work in Progress, Internet-Draft, draft- 699 ietf-dtn-bpsec-22, 10 March 2020, 700 . 702 9.2. Informative References 704 [I-D.ietf-acme-email-smime] 705 Melnikov, A., "Extensions to Automatic Certificate 706 Management Environment for end user S/MIME certificates", 707 Work in Progress, Internet-Draft, draft-ietf-acme-email- 708 smime-08, 16 June 2020, . 711 [I-D.ietf-dtn-bibect] 712 Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in 713 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 714 February 2020, 715 . 717 [I-D.ietf-dtn-tcpclv4] 718 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 719 Tolerant Networking TCP Convergence Layer Protocol Version 720 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 721 tcpclv4-21, 12 June 2020, 722 . 724 [github-acme-dtnnodeid] 725 Sipos, B., "ACME Node ID Example Implementation", 726 . 728 Appendix A. Administrative Record Types CDDL 730 [NOTE to the RFC Editor: The "TBD" in this CDDL is replaced by the 731 "ACME Node ID Validation" administrative record type code.] 733 The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles 734 is: 736 ; All ACME records have the same structure 737 $admin-record /= [TBD, acme-record] 738 acme-record = $acme-record .within acme-record-structure 739 acme-record-structure = [ 740 type-code: uint, 741 acme-content: tstr 742 ] 743 ; The type code distinguishes the purpose 744 $acme-record /= [ 745 1, 746 token-part1: tstr 747 ] 748 $acme-record /= [ 749 2, 750 key-authorization: tstr 751 ] 753 Appendix B. Example Bundles 755 The provided figures are extended diagnostic notation [RFC8610]. 756 These examples use a placeholder administrative record type code of 757 0xFFFF in order to be valid CBOR encoding. The examples also use no 758 block CRC or integrity block, which is for simplicity and is not 759 recommended for normal use. 761 B.1. Challenge Bundle 763 An example of a Challenge Bundle sent to "dtn://acme-client/" is: 765 [ 766 [ 767 7, / BP version / 768 0x000002, / flags: payload-is-an-administrative-record / 769 0, / CRC type / 770 [1, "//acme-client/"], / destination / 771 [1, "//acme-server/"], / source / 772 [1, "//acme-server/"], / report-to / 773 [0, 40], / timestamp / 774 1000000 / lifetime / 775 ], 776 [ 777 1, / block type code / 778 1, / block number / 779 0, / flags / 780 0, / CRC type / 781 <<[ / type-specific data / 782 0xFFFF, / record-type-code / 783 [ / record-content / 784 1, / challenge indicator / 785 "LVMo24VdNAw" / token-part1 / 786 ] 787 ]>> 788 ] 789 ] 791 B.2. Response Bundle 793 An example of a Response Bundle sent to "dtn://acme-server/" is: 795 [ 796 [ 797 7, / BP version / 798 0x000002, / flags: payload-is-an-administrative-record / 799 0, / CRC type / 800 [1, "//acme-server/"], / destination / 801 [1, "//acme-client/"], / source / 802 [1, "//acme-client/"], / report-to / 803 [0, 40], / timestamp / 804 1000000 / lifetime / 805 ], 806 [ 807 1, / block type code / 808 1, / block number / 809 0, / flags / 810 0, / CRC type / 811 <<[ / type-specific data / 812 0xFFFF, / record-type-code / 813 [ / record-content / 814 2, / response indicator / 815 "qXjSp7npR2YtUyjbhV00DA.9jg46WB3...fm21mqTI" / key authorization / 816 ] 817 ]>> 818 ] 819 ] 821 Author's Address 823 Brian Sipos 824 RKF Engineering Solutions, LLC 825 7500 Old Georgetown Road 826 Suite 1275 827 Bethesda, MD 20814-6198 828 United States of America 830 Email: BSipos@rkf-eng.com