idnits 2.17.1 draft-ietf-acme-dtnnodeid-08.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 (10 January 2022) is 837 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1347 -- Looks like a reference, but probably isn't: '0' on line 1348 -- Looks like a reference, but probably isn't: '1000000' on line 1307 -- Looks like a reference, but probably isn't: '1030000' on line 1348 == Outdated reference: A later version (-07) exists of draft-bsipos-dtn-bpsec-cose-06 Summary: 0 errors (**), 0 flaws (~~), 2 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 10 January 2022 5 Expires: 14 July 2022 7 Automated Certificate Management Environment (ACME) Delay-Tolerant 8 Networking (DTN) Node ID Validation Extension 9 draft-ietf-acme-dtnnodeid-08 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 otherName with a name form of 18 BundleEID and as an ACME Identifier type "bundleEID". 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 14 July 2022. 37 Copyright Notice 39 Copyright (c) 2022 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 Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 4 56 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 8 59 2.1. Subsets of Endpoint ID . . . . . . . . . . . . . . . . . 8 60 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 9 61 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 12 62 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 13 63 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 13 64 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 15 65 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 15 66 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 16 67 3.5. Multi-Perspective Validation . . . . . . . . . . . . . . 17 68 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 17 69 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 18 70 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 18 71 5.2. Generating Encryption-only or Signing-only Bundle Security 72 Certificates . . . . . . . . . . . . . . . . . . . . . . 19 73 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 75 7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 20 76 7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 20 77 7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 21 78 7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 21 79 7.5. Inherited Security Considerations . . . . . . . . . . . . 22 80 7.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 22 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 8.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 22 83 8.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 23 84 8.3. Bundle Administrative Record Types . . . . . . . . . . . 23 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 87 9.2. Informative References . . . . . . . . . . . . . . . . . 25 88 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 27 89 Appendix B. Example Authorization . . . . . . . . . . . . . . . 28 90 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 28 91 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 29 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 95 1. Introduction 97 Although the original purpose of the Automatic Certificate Management 98 Environment (ACME) [RFC8555] was to allow Public Key Infrastructure 99 Using X.509 (PKIX) certificate authorities to validate network domain 100 names of clients, the same mechanism can be used to validate any of 101 the subject claims supported by the PKIX profile [RFC5280]. 103 In the case of this specification, the claim being validated is a 104 Subject Alternative Name (SAN) of type otherName with a name form of 105 BundleEID, which used to represent an Endpoint ID (EID) for a Delay- 106 Tolerant Networking (DTN) bundle. Currently the URI schemes "dtn" 107 and "ipn" as defined in [I-D.ietf-dtn-bpbis] are valid for an 108 Endpoint ID. A DTN Node ID is an Endpoint ID with scheme-specific 109 restrictions to identify it as such; currently the "dtn" scheme uses 110 an empty demux part and the "ipn" scheme uses service number zero. 112 Because the BundleEID claim is new to ACME, a new ACME Identifier 113 type "bundleEID" is needed to manage this claim within ACME 114 messaging. A "bundleEID" claim can be part of a pre-authorization or 115 as one of the authorizations of an order containing any number of 116 claims. 118 Once an ACME server validates a Node ID, either as a pre- 119 authorization of the "bundleEID" or as one of the authorizations of 120 an order containing a "bundleEID", the client can finalize the order 121 using an associated certificate signing request (CSR). Because a 122 single order can contain multiple identifiers of multiple types, 123 there can be operational issues for a client attempting to, and 124 possibly failing to, validate those multiple identifiers as described 125 in Section 5.1. Once a certificate is issued for a Node ID, how the 126 ACME client configures the Bundle Protocol (BP) agent with the new 127 certificate is an implementation matter. 129 The scope and behavior of this validation mechanism is similar to 130 that of secured email validation of [RFC8823]. 132 1.1. Scope 134 This document describes the ACME messages, BPv7 payloads, and BPSec 135 requirements needed to validate Node ID ownership. This document 136 does not address: 138 * Mechanisms for communication between ACME client or ACME server 139 and their associated BP agent(s). This document only describes 140 exchanges between ACME client--server pairs and between their BP 141 agents. 143 * Specific BP extension blocks or BPSec security contexts necessary 144 to fulfill the security requirements of this protocol. The exact 145 security context needed, and their parameters, are network- 146 specific. 148 * Policies or mechanisms for defining or configuring bundle 149 integrity gateways, or trusting integrity gateways on an 150 individual entity or across a network. 152 * Mechanisms for locating or identifying other bundle entities 153 (peers) within a network or across an internet. The mapping of 154 Node ID to potential convergence layer (CL) protocol and network 155 address is left to implementation and configuration of the BP 156 Agent and its various potential routing strategies. 158 * Logic for routing bundles along a path toward a bundle's endpoint. 159 This protocol is involved only in creating bundles at a source and 160 handling them at a destination. 162 * Logic for performing rate control and congestion control of bundle 163 transfers. The ACME server is responsible for rate control of 164 validation requests. 166 * Policies or mechanisms for provisioning, deploying, or accessing 167 certificates and private keys; deploying or accessing certificate 168 revocation lists (CRLs); or configuring security parameters on an 169 individual entity or across a network. 171 * Policies or mechanisms for an ACME server to handle mixed-use 172 certificate requests. This specification is focused only on 173 single-use DTN-specific PKIX profiles. 175 1.2. Authorization Strategy 177 The basic unit of data exchange in a DTN is a Bundle 178 [I-D.ietf-dtn-bpbis], which consists of a data payload with 179 accompanying metadata. An Endpoint ID is used as the destination of 180 a Bundle and can indicate both a unicast or a multicast destination. 181 A Node ID is used to identify the source of a Bundle and is used for 182 routing through intermediate nodes, including the final node(s) used 183 to deliver a Bundle to its destination endpoint. A Node ID can also 184 be used as an endpoint for administrative bundles. More detailed 185 descriptions of the rationale and capabilities of these networks can 186 be found in "Delay-Tolerant Network Architecture" [RFC4838]. 188 When an ACME client requests a pre-authorization or an order with a 189 "bundleEID" identifier type having a value consistent with a Node ID 190 (see Section 4.2.5 of [I-D.ietf-dtn-bpbis]), the ACME server offers a 191 "dtn-nodeid-01" challenge type to validate that Node ID. If the ACME 192 client attempts the authorization challenge to validate a Node ID, 193 the ACME server sends an ACME Node ID Validation Challenge Bundle 194 with a destination of the Node ID being validated. The BP agent on 195 that node receives the Challenge Bundle, generates an ACME key 196 authorization digest, and sends an ACME Node ID Validation Response 197 Bundle in reply. An Integrity Gateway on the client side of the DTN 198 can be used to attest to the source of the Response Bundle. Finally, 199 the ACME server receives the Response Bundle and checks that the 200 digest was generated for the associated ACME challenge and from the 201 client account key associated with the original request. This 202 workflow is shown in the diagram of Figure 1 and defined in 203 Section 3. 205 +------------+ +------------+ 206 | ACME |<===== HTTPS exchanges =====>| ACME | 207 | Client | | Server | 208 +------------+ +------------+ 209 | | ^ 210 (1) Enable or (6) disable (2) Send | | 211 validation from server Challenge | |(5) Indicate 212 | Non-DTN | | Response 213 ~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~ 214 V DTN V | 215 ++------------++ ++------------++ 216 || Admin Elem.|| || Admin Elem.||-+ 217 |+------------+| (3) Challenge |+------------+| | 218 | Client's |<------------- Bundle -----| Server's | | 219 | BP Agent | | BP Agent | | 220 +--------------+ +--------------+ | 221 | +----^---------+ 222 | +-------------+ | 223 | | Integrity | (4) Response | 224 +---->| Gateway |------ Bundle --------+ 225 +-------------+ 227 Figure 1: The relationships and flows between Node ID Validation 228 entities 230 Because the DTN Node ID is used both for routing bundles between BP 231 agents and for multiplexing administrative services within a BP 232 agent, there is no possibility to separate the ACME validation of a 233 Node ID from normal bundle handling for that same Node ID. This 234 leaves administrative record types as a way to leave the Node ID 235 unchanged while disambiguating from other service data bundles. 237 There is nothing in this protocol which requires network-topological 238 co-location of either the ACME client or ACME server with their 239 associated BP agent. While ACME requires a low-enough latency 240 network to perform HTTPS exchanges between ACME client and server, 241 the client's BP agent (the one being validated) could be on the far 242 side of a long-delay or multi-hop DTN network. The means by which 243 the ACME client or server communicates with its associated BP agent 244 is an implementation matter. 246 1.3. Use of CDDL 248 This document defines CBOR structure using the Concise Data 249 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure 250 can be extracted from the XML version of this document using the 251 XPath expression: 253 '//sourcecode[@type="cddl"]' 255 The following initial fragment defines the top-level symbols of this 256 document's CDDL, which includes the example CBOR content. 258 start = acme-record / bundle / tstr 260 1.4. Terminology 262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 264 "OPTIONAL" in this document are to be interpreted as described in BCP 265 14 [RFC2119] [RFC8174] when, and only when, they appear in all 266 capitals, as shown here. 268 Because this document combines two otherwise unrelated contexts, ACME 269 and DTN, when a protocol term applies to one of those areas and is 270 used in the other its name is prefixed with either "ACME" or "DTN" 271 respectively. Thus within the ACME context the term is "DTN Node ID" 272 while in the DTN context the name is just "Node ID". 274 In this document, several terms are shortened for the sake of 275 terseness. These terms are: 277 Challenge Request: This is a shortened form of the full "DTN Node ID 278 Challenge Request Object". It is a JSON object created by the 279 ACME server for challenge type "dtn-nodeid-01". 281 Challenge Response: This is a shortened form of the full "DTN Node 282 ID Challenge Response Object". It is a JSON object created by the 283 ACME client to authorize a challenge type "dtn-nodeid-01". 285 Challenge Bundle: This is a shortened form of the full "ACME Node ID 286 Validation Challenge Bundle". It is a Bundle created by the BP 287 agent managed by the ACME server to challenge a Node ID claim. 289 Response Bundle: This is a shortened form of the full "ACME Node ID 290 Validation Response Bundle". It is a Bundle created by the BP 291 agent managed by the ACME client to validate a Node ID claim. 293 Because this is an ACME document, the following DTN Bundle Protocol 294 terms are defined here to clarify how they are used by this ACME 295 identifier type and validation mechanism. 297 Endpoint ID: An Endpoint ID is an identifier for the ultimate 298 destination of a bundle, independent of any intermediate 299 forwarding needed to reach that destination. An endpoint can be a 300 singleton (unicast) or not (anycast or multicast) so an Endpoint 301 ID can also represent a single entity or a set of entities. This 302 is formally defined in Section 4.2.5.1 of [I-D.ietf-dtn-bpbis]. 304 Node ID: A Node ID is a (not guaranteed unique) identifier for a 305 specific node in a network in the form of a singleton Endpoint ID. 306 A single node can have any number of Node IDs but a typical (and 307 expected) form of Node ID is the Administrative Endpoint ID 308 (described below). This is formally defined in Section 4.2.5.2 of 309 [I-D.ietf-dtn-bpbis]. 311 Administrative Endpoint ID: An Administrative Endpoint ID is unique 312 for a node within a specific URI scheme. Although any Node ID can 313 be a valid bundle Source and Destination, the Administrative 314 Endpoint ID is a minimum required Node ID for any node operating 315 in a particular URI scheme. For the "dtn" scheme this is the 316 empty demux part and for the "ipn" scheme this is the service 317 number zero. These is formally defined under Section 4.2.5.1 of 318 [I-D.ietf-dtn-bpbis]. 320 2. Bundle Endpoint ID ACME Identifier 322 This specification is the first to make use of an Bundle Endpoint ID 323 to identify a claim for a certificate request in ACME. In this 324 document, the only purpose for which an Bundle Endpoint ID ACME 325 identifier is validated is as a DTN Node ID (see Section 3), but 326 other specifications can define challenge types for other Endpoint ID 327 uses. 329 Identifiers of type "bundleEID" in certificate requests SHALL appear 330 in an extensionRequest attribute [RFC2985] containing a 331 subjectAltName extension of type otherName with a name form of 332 BundleEID, identified by id-on-bundleEID of [IANA-SMI], consistent 333 with the requirements of Section 4.4.2.1 of [I-D.ietf-dtn-tcpclv4]. 334 Because the BundleEID is encoded as an IA5String it SHALL be treated 335 as being in the percent-encoded form of Section 2.1 of [RFC3986]. 336 Any "bundleEID" identifier which fails to properly percent-decode 337 SHALL be rejected with an ACME error type of "malformed". 339 The ACME server SHALL decode and normalize (based on scheme-specific 340 syntax) all received identifiers of type "bundleEID". Any 341 "bundleEID" identifier request which uses a scheme not handled by the 342 ACME server or for which the EID does not match the scheme-specific 343 syntax SHALL be rejected with an ACME error type of 344 "rejectedIdentifier". 346 When an ACME server needs to request proof that a client controls a 347 BundleEID, it SHALL create an authorization with the identifier type 348 "bundleEID". The ACME server SHALL NOT attempt to dereference the 349 EID value on its own. It is the responsibility of a validation 350 method to ensure the EID ownership via scheme-specific means 351 authorized by the ACME client. 353 An identifier for the Node ID of "dtn://example/" would be formatted 354 as: 356 { 357 "type": "bundleEID", 358 "value": "dtn://example/" 359 } 361 2.1. Subsets of Endpoint ID 363 While the PKIX other name form of BundleEID can hold any Endpoint ID 364 value, the certificate profile used by [I-D.ietf-dtn-tcpclv4] and 365 supported by this ACME validation method in Section 3 requires that 366 the value hold a Node ID. 368 In addition to the narrowing of that certificate profile, this 369 validation method requires that the client's BP agent responds to 370 administrative records sent to the Node ID being validated. This 371 typically is limited to an Administrative Endpoint ID, but there is 372 no prohibition on the administrative element of a BP node from 373 receiving administrative records for, and sending records from, other 374 Node IDs in order to support this validation method. 376 Neither that certificate profile nor this validation method support 377 operating on non-singleton Endpoint IDs, but other validation methods 378 could be defined to do so in order to support other certificate 379 profiles. 381 3. DTN Node ID Validation 383 The DTN Node ID validation method proves control over a Node ID by 384 requiring the ACME client to configure a BP agent to respond to 385 specific Challenge Bundles sent from the ACME server. The ACME 386 server validates control of the Node ID by verifying that received 387 Response Bundles correspond with the BP Node and client account key 388 being validated. 390 Similar to the ACME use case for validating email address ownership 391 [RFC8823], this challenge splits the token into several parts, each 392 being transported by a different channel, and the Key Authorization 393 result requires combining all parts of the token. A separate 394 challenge identifier is used as a filter by BP agents similarly to 395 the challenge "from" email address of [RFC8823]. 397 The token parts are: 399 token-chal: This token is unique to each ACME authorization. It is 400 contained in the Challenge Object of Section 3.1. Each 401 authorization can consist of multiple Challenge Bundles (e.g. 402 taking different routes), but they all share the same token-chal 403 value. This ensures that the Key Authorization is bound to the 404 specific ACME challenge (and parent ACME authorization). This 405 token does not appear on the BP channel so that any eavesdropper 406 knowing the client's account key thumbprint (e.g. from some other 407 validation method) is not able to impersonate the client. 409 token-bundle: This token is unique to each Challenge Bundle sent by 410 the ACME server. It is contained in the Challenge Bundle of 411 Section 3.3 and Response Bundle of Section 3.4. This ensures that 412 the Key Authorization is bound to the ability to receive the 413 Challenge Bundle and not just have access to the ACME Challenge 414 Object. This token is also accessible to DTN on-path 415 eavesdroppers. 417 Because multiple Challenge Bundles can be sent to validate the same 418 Node ID, the token-bundle in the response is needed to correlate with 419 the expected Key Authorization digest. 421 The DTN Node ID Challenge SHALL only be allowed for an EID usable as 422 a DTN Node ID, which is defined per-scheme in Section 4.2.5.1 of 423 [I-D.ietf-dtn-bpbis]. When an ACME server supports Node ID 424 validation, the ACME server SHALL define a challenge object in 425 accordance with Section 3.1. Once this challenge object is defined, 426 the ACME client may begin the validation. 428 To initiate a Node ID validation, the ACME client performs the 429 following steps: 431 1. The ACME client POSTs a newOrder or newAuthz request including 432 the identifier of type "bundleEID" for the desired Node ID. From 433 either of these entry points an authorization for the "bundleEID" 434 type is indicated by the ACME server. See Section 7.4 of 435 [RFC8555] for more details. 437 2. The ACME client obtains the id-chal and token-chal from the 438 challenge object in accordance with Section 3.1. 440 3. The ACME client indicates to the administrative element of its BP 441 agent the id-chal which is authorized for use along with the 442 associated token-chal and client account key thumbprint. The 443 ACME client SHALL wait, if necessary, until the agent is 444 configured before proceeding to the next step. 446 4. The ACME client POSTs a challenge response to the challenge URL 447 on the ACME server accordance with Section 7.5.1 of [RFC8555]. 448 The payload object is constructed in accordance with Section 3.2. 450 5. The administrative element waits for a Challenge Bundle to be 451 received with the authorized ACME parameters, including its id- 452 chal payload, in accordance with Section 3.3. 454 6. The administrative element concatenates token-bundle with token- 455 chal (each as base64url-encoded text strings) and computes the 456 Key Authorization in accordance with Section 8.1 of [RFC8555] 457 using the full token and client account key thumbprint. 459 7. The administrative element computes the SHA-256 digest of the Key 460 Authorization result and generates a Response Bundle to send back 461 to the ACME server in accordance with Section 3.4. 463 8. The ACME client waits for the authorization to be finalized on 464 the ACME server in accordance with Section 7.5.1 of [RFC8555]. 466 9. Once the challenge is completed (successfully or not), the ACME 467 client indicates to the BP agent that the id-chal is no longer 468 usable. If the authorization fails, the ACME client MAY retry 469 the challenge from Step 3. 471 The ACME server verifies the client's control over a Node ID by 472 performing the following steps: 474 1. The ACME server receives a newOrder or newAuthz request including 475 the identifier of type "bundleEID", where the URI value is a Node 476 ID. 478 2. The ACME server generates an authorization for the Node ID with 479 challenge type "dtn-nodeid-01" in accordance with Section 3.1. 481 3. The ACME server receives a POST to the challenge URL indicated 482 from the authorization object. The payload is handled in 483 accordance with Section 3.2. 485 4. The ACME server sends, via the administrative element of its BP 486 agent, one or more Challenge Bundles in accordance with 487 Section 3.3. Each challenge bundle SHALL contain a distinct 488 token-bundle to be able to correlate with a response bundle. 489 Computing an expected Key Authorization digest is not necessary 490 until a response is received. 492 5. The ACME server waits for Response Bundle(s) for a limited 493 interval of time (based on the challenge response object of 494 Section 3.2). Responses are encoded in accordance with 495 Section 3.4. 497 6. Once received and decoded, the ACME server checks the contents of 498 each Response Bundle in accordance with Section 3.4.1. After all 499 Challenge Bundles have either been responded to or timed-out, the 500 ACME server policy (see Section 3.5) determines whether the 501 validation is successful. If validation is not successful, a 502 client may retry the challenge which starts in Step 3. 504 When responding to a Challenge Bundle, a BP agent SHALL send a single 505 Response Bundle in accordance with Section 3.4. A BP agent SHALL 506 respond to ACME challenges only within the interval of time and only 507 for the id-chal indicated by the ACME client. A BP agent SHALL 508 respond to multiple Challenge Bundles with the same ACME parameters 509 but different bundle identities (source Node ID and timestamp); these 510 correspond with the ACME server validating via multiple routing 511 paths. 513 3.1. DTN Node ID Challenge Request Object 515 The DTN Node ID Challenge request object is defined by the ACME 516 server when it supports validating Node IDs. 518 The DTN Node ID Challenge request object has the following content: 520 type (required, string): The string "dtn-nodeid-01". 522 id-chal (required, string): This is a random value associated with a 523 challenge which allows a client to filter valid Challenge Bundles. 524 The same value is used for all Challenge Bundles associated with 525 an ACME challenge, including multi-perspective validation using 526 multiple sources as described in Section 3.5. This value SHALL 527 have at least 128 bits of entropy. It SHALL NOT contain any 528 characters outside the base64url alphabet as described in 529 Section 5 of [RFC4648]. Trailing '=' padding characters SHALL be 530 stripped. See [RFC4086] for additional information on randomness 531 requirements. 533 token-chal (required, string): This is a random value, used as part 534 of the Key Authorization algorithm, which is communicated to the 535 ACME client only over the ACME channel. This value SHALL have at 536 least 128 bits of entropy. It SHALL NOT contain any characters 537 outside the base64url alphabet as described in Section 5 of 538 [RFC4648]. Trailing '=' padding characters SHALL be stripped. 539 See [RFC4086] for additional information on randomness 540 requirements. 542 { 543 "type": "dtn-nodeid-01", 544 "url": "https://example.com/acme/chall/prV_B7yEyA4", 545 "id-chal": "dDtaviYTPUWFS3NK37YWfQ", 546 "token-chal": "tPUZNY4ONIk6LxErRFEjVw" 547 } 549 The token-chal value included in this object applies to the entire 550 challenge, and may correspond with multiple separate token-bundle 551 values when multiple Challenge Bundles are sent for a single 552 validation. 554 3.2. DTN Node ID Challenge Response Object 556 The DTN Node ID Challenge response object is defined by the ACME 557 client when it authorizes validation of a Node ID. Because a DTN has 558 the potential for significantly longer delays than a non-DTN network, 559 the ACME client is able to inform the ACME server if a particular 560 validation round-trip is expected to take longer than normal network 561 delays (on the order of seconds). 563 The DTN Node ID Challenge response object has the following content: 565 rtt (optional, number): An expected round-trip time (RTT), in 566 seconds, between sending a Challenge Bundle and receiving a 567 Response Bundle. This value is a hint to the ACME server for how 568 long to wait for responses but is not authoritative. The minimum 569 RTT value SHALL be zero. There is no special significance to 570 zero-value RTT, it simply indicates the response is expected in 571 less than the least significant unit used by the ACME client. 573 { 574 "rtt": 300.0 575 } 577 A challenge response is not sent until the BP agent has been 578 configured to properly respond to the challenge, so the RTT value is 579 meant to indicate any node-specific path delays expected to 580 encountered from the ACME server. Because there is no requirement on 581 the path (or paths) which bundles may traverse between the ACME 582 server and the BP agent, and the ACME server can attempt some path 583 diversity, the RTT value SHOULD be pessimistic. 585 A default bundle response interval, used when the object does not 586 contain an RTT, SHOULD be a configurable parameter of the ACME 587 server. If the ACME client indicated an RTT value in the object, the 588 response interval SHOULD be twice the RTT (with limiting logic 589 applied as described below). The lower limit on response interval is 590 network-specific, but SHOULD NOT be shorter than one second. The 591 upper limit on response interval is network-specific, but SHOULD NOT 592 be longer than one minute (60 seconds) for a terrestrial-only DTN. 594 3.3. ACME Node ID Validation Challenge Bundles 596 Each ACME Node ID Validation Challenge Bundle SHALL be structured and 597 encoded in accordance with [I-D.ietf-dtn-bpbis]. 599 Each Challenge Bundle has parameters as listed here: 601 Bundle Processing Control Flags: The primary block flags SHALL 602 indicate that the payload is an administrative record. The 603 primary block flags SHALL indicate that user application 604 acknowledgement is requested; this flag distinguishes the 605 Challenge Bundle from the Response Bundle. 607 Destination EID: The Destination EID SHALL be the ACME-server- 608 normalized Node ID being validated. 610 Source Node ID: The Source Node ID SHALL indicate the Node ID of a 611 BP agent of the ACME server performing the challenge. 613 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 614 to the time at which the challenge was generated. The Lifetime 615 SHALL indicate the response interval (of Section 3.2) for which 616 ACME server will accept responses to this challenge. 618 Administrative Record Type Code: Set to the ACME Node ID Validation 619 type code defined in Section 8.3. 621 Administrative Record Content: The Challenge Bundle administrative 622 record content SHALL consist of a CBOR map containing two pairs: 624 * One pair SHALL consist of key 1 with value of ACME challenge 625 id-chal, copied from the challenge object, represented as a 626 CBOR byte string. 628 * One pair SHALL consist of key 2 with value of ACME challenge 629 token-bundle, represented as a CBOR byte string. The token- 630 bundle is a random value that uniquely identifies the challenge 631 bundle. This value SHALL have at least 128 bits of entropy. 632 See [RFC4086] for additional information on randomness 633 requirements. 635 This structure is part of the extension CDDL in Appendix A. An 636 example full Challenge Bundle is included in Appendix B.1 638 If the BP agent generating a Challenge Bundle does not have a well- 639 synchronized clock or the agent responding to the challenge is 640 expected to not have a well-synchronized clock, the bundle SHALL 641 include a Bundle Age extension block. 643 Challenge Bundles SHALL include a Block Integrity Block (BIB) in 644 accordance with Section 4 or with a Security Source identical to the 645 bundle Source Node. Challenge Bundles SHALL NOT be directly 646 encrypted by Block Confidentiality Block (BCB) or any other method 647 (see Section 7.1). 649 3.3.1. Challenge Bundle Checks 651 A proper Challenge Bundle meets all of the following criteria: 653 * The Challenge Bundle was received within the time interval allowed 654 for the challenge. The allowed interval starts at the Creation 655 Timestamp and extends for the Lifetime of the Challenge Bundle. 657 * The Challenge Bundle contains a BIB which covers at least the 658 primary block and payload. That BIB has a security source which 659 is trusted and passes security-context-specific validation (i.e. 660 MAC or signature verification). 662 * The challenge payload contains the id-chal as indicated in the 663 ACME challenge object. The challenge payload contains a token- 664 bundle meeting the definition in Section 3.3. 666 Any of the failures above SHALL cause the challenge bundle to be 667 deleted and otherwise ignored by the BP agent. 669 3.4. ACME Node ID Validation Response Bundles 671 Each ACME Node ID Validation Response Bundle SHALL be structured and 672 encoded in accordance with [I-D.ietf-dtn-bpbis]. 674 Each Response Bundle has parameters as listed here: 676 Bundle Processing Control Flags: The primary block flags SHALL 677 indicate that the payload is an administrative record. The 678 primary block flags SHALL NOT indicate that user application 679 acknowledgement is requested; this flag distinguishes the Response 680 Bundle from the Challenge Bundle. 682 Destination EID: The Destination EID SHALL be identical to the 683 Source Node ID of the Challenge Bundle to which this response 684 corresponds. 686 Source Node ID: The Source Node ID SHALL be identical to the 687 Destination EID of the Challenge Bundle to which this response 688 corresponds. 690 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 691 to the time at which the response was generated. The response 692 Lifetime SHALL indicate the response interval remaining if the 693 Challenge Bundle indicated a limited Lifetime. 695 Administrative Record Type Code: Set to the ACME Node ID Validation 696 type code defined in Section 8.3. 698 Administrative Record Content: The Response Bundle administrative 699 record content SHALL consist of a CBOR map containing three pairs: 701 * One pair SHALL consist of key 1 with value of ACME challenge 702 id-chal, copied from the Request Bundle, represented as a CBOR 703 byte string. 705 * One pair SHALL consist of key 2 with value of ACME challenge 706 token-bundle, copied from the Request Bundle, represented as a 707 CBOR byte string. 709 * One pair SHALL consist of key 3 with value of the SHA-256 710 digest [FIPS180-4] of the ACME Key Authorization in accordance 711 with Section 8.1 of [RFC8555], represented as a CBOR byte 712 string. 714 This structure is part of the extension CDDL in Appendix A. An 715 example full Response Bundle is included in Appendix B.2 717 If the BP agent responding to a Challenge Bundle does not have a 718 well-synchronized clock, it SHALL use any information about last-hop 719 delays and (if present) Bundle Age extension data to infer the age of 720 the Challenge Bundle and lifetime of the Response Bundle. 722 Response Bundles SHALL include a BIB in accordance with Section 4. 723 Response Bundles SHALL NOT be directly encrypted by BCB or any other 724 method (see Section 7.1 for explanation). 726 3.4.1. Response Bundle Checks 728 A proper Response Bundle meets all of the following criteria: 730 * The Response Bundle was received within the time interval allowed 731 for the challenge. The allowed interval starts at the Creation 732 Timestamp and extends for the Lifetime of the associated Challenge 733 Bundle. The interval of the Challenge Bundle is used here because 734 the interval of the Response Bundle could be made to disagree with 735 the Challenge Bundle. 737 * The Response Bundle Source Node ID is identical to the Node ID 738 being validated. The comparison of Node IDs SHALL use the 739 comparison logic of the NODE-ID from Section 4.4.1 of 740 [I-D.ietf-dtn-tcpclv4]. 742 * The Response Bundle contains a BIB which covers at least the 743 primary block and payload. That BIB has a security source which 744 is trusted and passes security-context-specific validation. 746 * The response payload contains the same id-chal and token-bundle as 747 sent in the Challenge Bundle (this is also how the two bundles are 748 correlated). The response payload contains the expected Key 749 Authorization digest computed by the ACME server. 751 Any of the failures above SHALL cause that single-perspective 752 validation to fail. Any of the failures above SHOULD be 753 distinguished as subproblems to the ACME client. The lack of a 754 response within the expected response interval, as defined in 755 Section 3.2, SHALL also be treated as a validation failure. 757 3.5. Multi-Perspective Validation 759 To avoid possible on-path attacks in certain networks, an ACME server 760 can perform a single validation using multiple challenge bundle 761 sources or via multiple routing paths. This technique is called 762 multi-perspective validation as recommended in Section 10.2 of 763 [RFC8555] and an implementation used by Let's Encrypt is described in 764 [LE-multi-perspective]. 766 When required by policy, an ACME server SHALL send multiple challenge 767 bundles from different sources in the DTN network. When multiple 768 Challenge Bundles are sent for a single validation, it is a matter of 769 ACME server policy to determine whether or not the validation as a 770 whole is successful. The result of each single-source validation is 771 defined as success or failure in Section 3.4.1. 773 A RECOMMENDED validation policy is to succeed if the challenge from a 774 primary bundle source is successful and if there are no more than one 775 failure from a secondary source. The determination of which 776 perspectives are considered primary or secondary is an implementation 777 matter. 779 Regardless of whether a validation is single- or multi-perspective, a 780 validation failure SHALL be indicated by an ACME error type of 781 "incorrectResponse". Each specific perspective failure SHOULD be 782 indicated to the ACME client as a validation subproblem. 784 4. Bundle Integrity Gateway 786 This section defines a BIB use which closely resembles the function 787 of DKIM email signing [RFC6376]. In this mechanism a routing node in 788 a DTN sub-network attests to the origination of a bundle by adding a 789 BIB before forwarding it. The bundle receiver then need not trust 790 the source of the bundle, but only trust this security source node. 791 The receiver needs policy configuration to know which security 792 sources are permitted to attest for which bundle sources. 794 An integrity gateway SHALL validate the Source Node ID of a bundle, 795 using local-network-specific means, before adding a BIB to the 796 bundle. The exact means by which an integrity gateway validates a 797 bundle's source is network-specific, but could use physical-layer, 798 network-layer or BP-convergence-layer authentication. The bundle 799 source could also add its own BIB with a local-network-specific 800 security context or local-network-specific key material (i.e. a group 801 key shared within the local network). 803 When an integrity gateway adds a BIB it SHALL be in accordance with 804 [I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload 805 block and the primary block (either directly as a target or as 806 additional authenticated data for the payload block MAC/signature). 807 The Security Source of this BIB SHALL be either the bundle source 808 Node ID itself or a routing node trusted by the destination node (see 809 Section 7.2). 811 5. Certificate Request Profile 813 The ultimate purpose of this ACME validation is to allow a CA to 814 issue certificates following the profiles of Section 4.4.2 of 815 [I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and 816 [I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as 817 bundle security certificates. 819 One defining aspect of bundle security certificates is the Extended 820 Key Usage key purpose id-kp-bundleSecurity of [IANA-SMI]. When 821 requesting a certificate which includes a Node ID SAN, the CSR SHOULD 822 include an Extended Key Usage of id-kp-bundleSecurity. When a bundle 823 security certificate is issued based on a validated Node ID SAN, the 824 certificate SHALL include an Extended Key Usage of id-kp- 825 bundleSecurity. 827 5.1. Multiple Identity Claims 829 A single bundle security CSR MAY contain a mixed set of SAN claims, 830 including combinations of "ip", "dns", and "bundleEID" claims. There 831 is no restriction on how a certificate combines these claims, but 832 each claim SHALL be validated by an ACME server to issue such a 833 certificate as part of an associated ACME order. This is no 834 different than the existing behavior of [RFC8555] but is mentioned 835 here to make sure that CA policy handles such situations; especially 836 related to validation failure of an identifier in the presence of 837 multiple identifiers. The initial "ip" validations are defined in 838 [RFC8738] and initial "dns" validations are defined in [RFC8555] and 839 [RFC8737]. The specific use case of [I-D.ietf-dtn-tcpclv4] allows, 840 and for some network policies requires, that a certificate 841 authenticate both the DNS name of an entity as well as the Node ID of 842 the entity. 844 5.2. Generating Encryption-only or Signing-only Bundle Security 845 Certificates 847 ACME extensions specified in this document can be used to request 848 encryption-only or signing-only bundle security certificates. 850 In order to request signing only bundle security certificate, the CSR 851 SHALL include the key usage extension with digitalSignature and/or 852 nonRepudiation bits set and no other bits set. 854 In order to request encryption only bundle security certificate, the 855 CSR SHALL include the key usage extension with keyEncipherment or 856 keyAgreement bits set and no other bits set. 858 Presence of both of the above sets of key usage bits in the CSR, as 859 well as absence of key usage extension in the CSR, signals to ACME 860 server to issue a bundle security certificate suitable for both 861 signing and encryption. 863 6. Implementation Status 865 This section is to be removed before publishing as an RFC. 867 [NOTE to the RFC Editor: please remove this section before 868 publication, as well as the reference to [RFC7942] and 869 [github-dtn-demo-agent] and [github-dtn-wireshark].] 871 This section records the status of known implementations of the 872 protocol defined by this specification at the time of posting of this 873 Internet-Draft, and is based on a proposal described in [RFC7942]. 874 The description of implementations in this section is intended to 875 assist the IETF in its decision processes in progressing drafts to 876 RFCs. Please note that the listing of any individual implementation 877 here does not imply endorsement by the IETF. Furthermore, no effort 878 has been spent to verify the information presented here that was 879 supplied by IETF contributors. This is not intended as, and must not 880 be construed to be, a catalog of available implementations or their 881 features. Readers are advised to note that other implementations can 882 exist. 884 An example implementation of the this draft of ACME Node ID 885 Validation has been created as a GitHub project 886 [github-dtn-demo-agent] and is intended to use as a proof-of-concept 887 and as a possible source of interoperability testing. 889 A Wireshark dissector for of the this draft of ACME Node ID 890 Validation has been created as a GitHub project 891 [github-dtn-wireshark] and is intended to be used to inspect and 892 troubleshoot implementations. 894 7. Security Considerations 896 This section separates security considerations into threat categories 897 based on guidance of BCP 72 [RFC3552]. 899 7.1. Threat: Passive Leak of Validation Data 901 Because this challenge mechanism is used to bootstrap security 902 between DTN Nodes, the challenge and its response are likely to be 903 transferred in plaintext. The only ACME data present on-the-wire is 904 a random token and a cryptographic digest, so there is no sensitive 905 data to be leaked within the Node ID Validation bundle exchange. 906 Because each challenge uses a separate token pair, there is no value 907 in an on-path attacker seeing the tokens from past challenges and/or 908 responses. 910 It is possible for intermediate BP nodes to encapsulate-and-encrypt 911 Challenge and/or Response Bundles while they traverse untrusted 912 networks, but that is a DTN configuration matter outside of the scope 913 of this document. 915 7.2. Threat: BP Node Impersonation 917 As described in Section 8.1 of [RFC8555], it is possible for an 918 active attacker to alter data on both ACME client channel and the DTN 919 validation channel. 921 The primary mitigation is to delegate bundle integrity sourcing to a 922 trusted routing node near, in the sense of bundle routing topology, 923 to the bundle source node as defined in Section 4. This is 924 functionally similar to DKIM signing of [RFC6376] and provides some 925 level of bundle origination. 927 Another way to mitigate single-path on-path attacks is to attempt 928 validation of the same Node ID from multiple sources or via multiple 929 bundle routing paths, as defined in Section 3.5. It is not a trivial 930 task to guarantee bundle routing though, so more advanced techniques 931 such as onion routing (using bundle-in-bundle encapsulation 932 [I-D.ietf-dtn-bibect]) could be employed. 934 7.3. Threat: Bundle Replay 936 It is possible for an on-path attacker to replay both Challenge 937 Bundles or Response Bundles. Even in a properly-configured DTN it is 938 possible that intermediate bundle routers to use multicast forwarding 939 of a unicast-destination bundle. 941 Ultimately, the point of the ACME bundle exchange is to derive a Key 942 Authorization and its cryptographic digest and communicate it back to 943 the ACME server for validation, so the uniqueness of the Key 944 Authorization directly determines the scope of replay validity. The 945 uniqueness of each token-bundle to each challenge bundle ensures that 946 the Key Authorization is unique to the challenge bundle. The 947 uniqueness of each token-chal to the ACME challenge ensures that the 948 Key Authorization is unique to that ACME challenge and not based 949 solely on values visible to on-path eavesdroppers. 951 Having each bundle's primary block and payload block covered by a BIB 952 from a trusted security source (see Section 4) ensures that a 953 replayed bundle cannot be altered in the blocks used by ACME. All 954 together, these properties mean that there is no degraded security 955 caused by replay of either a Challenge Bundle or a Response Bundle 956 even in the case where the primary or payload block is not covered by 957 a BIB. The worst that can come of bundle replay is the waste of 958 network resources as described in Section 7.4. 960 7.4. Threat: Denial of Service 962 The behaviors described in this section all amount to a potential 963 denial-of-service to a BP agent. 965 A malicious entity can continually send Challenge Bundles to a BP 966 agent. The victim BP agent can ignore Challenge Bundles which do not 967 conform to the specific time interval and challenge token for which 968 the ACME client has informed the BP agent that challenges are 969 expected. The victim BP agent can require all Challenge Bundles to 970 be BIB-signed to ensure authenticity of the challenge. 972 A malicious entity can continually send Response Bundles to a BP 973 agent. The victim BP agent can ignore Response Bundles which do not 974 conform to the specific time interval or Source Node ID or challenge 975 token for an active Node ID validation. 977 Similar to other validation methods, an ACME server validating a DTN 978 Node ID could be used as a denial of service amplifier. For this 979 reason any ACME server can rate-limit validation activities for 980 individual clients and individual certificate requests. 982 7.5. Inherited Security Considerations 984 Because this protocol relies on ACME for part of its operation, the 985 security considerations of [RFC8555] apply to all ACME client--server 986 exchanges during Node ID validation. 988 Because this protocol relies on BPv7 for part of its operation, the 989 security considerations of [I-D.ietf-dtn-bpbis] and 990 [I-D.ietf-dtn-bpsec] apply to all BP messaging during Node ID 991 validation. 993 7.6. Out-of-Scope BP Agent Communication 995 Although messaging between an ACME client or ACME server an its 996 associated BP agent are out-of-scope for this document, both of those 997 channels are critical to Node ID validation security. Either channel 998 can potentially leak data or provide attack vectors if not properly 999 secured. These channels need to protect against spoofing of 1000 messaging in both directions to avoid interruption of normal 1001 validation sequencing and to prevent false validations from 1002 succeeding. 1004 The ACME server and its BP agent exchange the outgoing id-chal, 1005 token-bundle, and Key Authorization digest but these values do not 1006 need to be confidential (they are also in plaintext over the BP 1007 channel). 1009 Depending on implementation details, the ACME client might transmit 1010 the client account key thumbprint to its BP agent to allow computing 1011 the Key Authorization digest on the BP agent. If an ACME client does 1012 transmit its client account key thumbprint to a BP agent, it is 1013 important that this data is kept confidential because it provides the 1014 binding of the client account key to the Node ID validation (as well 1015 as for all other types of ACME validation). Avoiding this 1016 transmission would require a full round-trip between BP agent and 1017 ACME client, which can be undesirable if the two are separated by a 1018 long-delay network. 1020 8. IANA Considerations 1022 This specification adds to the ACME registry and BP registry for this 1023 behavior. 1025 8.1. ACME Identifier Types 1027 Within the "Automated Certificate Management Environment (ACME) 1028 Protocol" registry [IANA-ACME], the following entry has been added to 1029 the "ACME Identifier Types" sub-registry. 1031 +===========+==================================+ 1032 | Label | Reference | 1033 +===========+==================================+ 1034 | bundleEID | This specification and [RFC3986] | 1035 +-----------+----------------------------------+ 1037 Table 1 1039 8.2. ACME Validation Methods 1041 Within the "Automated Certificate Management Environment (ACME) 1042 Protocol" registry [IANA-ACME], the following entry has been added to 1043 the "ACME Validation Methods" sub-registry. 1045 +===============+=================+======+====================+ 1046 | Label | Identifier Type | ACME | Reference | 1047 +===============+=================+======+====================+ 1048 | dtn-nodeid-01 | bundleEID | Y | This specification | 1049 +---------------+-----------------+------+--------------------+ 1051 Table 2 1053 8.3. Bundle Administrative Record Types 1055 Within the "Bundle Protocol" registry [IANA-BP], the following 1056 entries have been added to the "Bundle Administrative Record Types" 1057 sub-registry. 1059 [NOTE to the RFC Editor: For [RFC5050] compatibility the AR-TBD value 1060 needs to be no larger than 15, but such compatibility is not needed. 1061 For BPbis the AR-TBD value needs to be no larger than 65535 as 1062 defined by [I-D.sipos-bpv7-admin-iana].] 1064 +=========================+========+==============+===============+ 1065 | Bundle Protocol Version | Value | Description | Reference | 1066 +=========================+========+==============+===============+ 1067 | 7 | AR-TBD | ACME Node ID | This | 1068 | | | Validation | specification | 1069 +-------------------------+--------+--------------+---------------+ 1071 Table 3 1073 9. References 1075 9.1. Normative References 1077 [FIPS180-4] 1078 National Institute of Standards and Technology, "Secure 1079 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 1080 . 1083 [IANA-ACME] 1084 IANA, "Automated Certificate Management Environment (ACME) 1085 Protocol", . 1087 [IANA-BP] IANA, "Bundle Protocol", 1088 . 1090 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", 1091 . 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, 1095 DOI 10.17487/RFC2119, March 1997, 1096 . 1098 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1099 Classes and Attribute Types Version 2.0", RFC 2985, 1100 DOI 10.17487/RFC2985, November 2000, 1101 . 1103 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1104 Text on Security Considerations", BCP 72, RFC 3552, 1105 DOI 10.17487/RFC3552, July 2003, 1106 . 1108 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1109 Resource Identifier (URI): Generic Syntax", STD 66, 1110 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1111 . 1113 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1114 "Randomness Requirements for Security", BCP 106, RFC 4086, 1115 DOI 10.17487/RFC4086, June 2005, 1116 . 1118 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1119 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1120 . 1122 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1123 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1124 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1125 April 2007, . 1127 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1128 Housley, R., and W. Polk, "Internet X.509 Public Key 1129 Infrastructure Certificate and Certificate Revocation List 1130 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1131 . 1133 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1134 Code: The Implementation Status Section", BCP 205, 1135 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1136 . 1138 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1139 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1140 May 2017, . 1142 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1143 Kasten, "Automatic Certificate Management Environment 1144 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1145 . 1147 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1148 Definition Language (CDDL): A Notational Convention to 1149 Express Concise Binary Object Representation (CBOR) and 1150 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1151 June 2019, . 1153 [I-D.ietf-dtn-bpbis] 1154 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle 1155 Protocol Version 7", Work in Progress, Internet-Draft, 1156 draft-ietf-dtn-bpbis-31, 25 January 2021, 1157 . 1160 [I-D.ietf-dtn-bpsec] 1161 III, E. J. B. and K. McKeever, "Bundle Protocol Security 1162 Specification", Work in Progress, Internet-Draft, draft- 1163 ietf-dtn-bpsec-27, 16 February 2021, 1164 . 1167 9.2. Informative References 1169 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1170 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1171 2007, . 1173 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1174 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1175 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1176 . 1178 [RFC8737] Shoemaker, R.B., "Automated Certificate Management 1179 Environment (ACME) TLS Application-Layer Protocol 1180 Negotiation (ALPN) Challenge Extension", RFC 8737, 1181 DOI 10.17487/RFC8737, February 2020, 1182 . 1184 [RFC8738] Shoemaker, R.B., "Automated Certificate Management 1185 Environment (ACME) IP Identifier Validation Extension", 1186 RFC 8738, DOI 10.17487/RFC8738, February 2020, 1187 . 1189 [RFC8823] Melnikov, A., "Extensions to Automatic Certificate 1190 Management Environment for End-User S/MIME Certificates", 1191 RFC 8823, DOI 10.17487/RFC8823, April 2021, 1192 . 1194 [I-D.ietf-dtn-bibect] 1195 Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in 1196 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 1197 February 2020, . 1200 [I-D.ietf-dtn-tcpclv4] 1201 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 1202 Tolerant Networking TCP Convergence Layer Protocol Version 1203 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 1204 tcpclv4-28, 6 October 2021, 1205 . 1208 [I-D.sipos-dtn-udpcl] 1209 Sipos, B., "Delay-Tolerant Networking UDP Convergence 1210 Layer Protocol", Work in Progress, Internet-Draft, draft- 1211 sipos-dtn-udpcl-01, 26 March 2021, 1212 . 1215 [I-D.sipos-bpv7-admin-iana] 1216 Sipos, B., "Bundle Protocol Version 7 Administrative 1217 Record Types Registry", Work in Progress, Internet-Draft, 1218 draft-sipos-bpv7-admin-iana-00, 13 October 2021, 1219 . 1222 [I-D.bsipos-dtn-bpsec-cose] 1223 Sipos, B., "DTN Bundle Protocol Security COSE Security 1224 Context", Work in Progress, Internet-Draft, draft-bsipos- 1225 dtn-bpsec-cose-06, 3 June 2021, 1226 . 1229 [github-dtn-demo-agent] 1230 Sipos, B., "Python implementation of basic BPv7-related 1231 protocols", 1232 . 1234 [github-dtn-wireshark] 1235 Sipos, B., "Wireshark Dissectors for BPv7-related 1236 Protocols", 1237 . 1239 [LE-multi-perspective] 1240 Aas, J., McCarney, D., and R. Shoemaker, "Multi- 1241 Perspective Validation Improves Domain Validation 1242 Security", 19 February 2020, 1243 . 1246 Appendix A. Administrative Record Types CDDL 1248 [NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the 1249 "ACME Node ID Validation" administrative record type code.] 1251 The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles 1252 is: 1254 ; All ACME records have the same structure 1255 $admin-record /= [0xFFFF, acme-record] 1256 acme-record = { 1257 id-chal, 1258 token-bundle, 1259 ? key-auth-digest ; present for Response Bundles 1260 } 1261 id-chal = (1 => bstr) 1262 token-bundle = (2 => bstr) 1263 key-auth-digest = (3 => bstr) 1265 Appendix B. Example Authorization 1267 [NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced 1268 by the "ACME Node ID Validation" administrative record type code.] 1270 This example is a bundle exchange for the ACME server with Node ID 1271 "dtn://acme-server/" performing a verification for ACME client Node 1272 ID "dtn://acme-client/". The example bundles use no block CRC or 1273 BPSec integrity, which is for simplicity and is not recommended for 1274 normal use. The provided figures are extended diagnostic notation 1275 [RFC8610]. 1277 For this example the ACME client key thumbprint has the base64url 1278 encoded value of: 1280 "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 1282 And the ACME-server generated token-chal has the base64url-encoded 1283 value of: 1285 "tPUZNY4ONIk6LxErRFEjVw" 1287 B.1. Challenge Bundle 1289 For the single challenge bundle in this example, the token-bundle 1290 (transported as byte string via BP) has the base64url-encoded value 1291 of: 1293 "p3yRYFU4KxwQaHQjJ2RdiQ" 1295 The minimal-but-valid Challenge Bundle is shown in Figure 2. This 1296 challenge requires that the ACME client respond within a 60 second 1297 time window. 1299 [_ 1300 [ 1301 7, / BP version / 1302 0x22, / flags: user-app-ack, payload-is-an-admin-record / 1303 0, / CRC type: none / 1304 [1, "//acme-client/"], / destination / 1305 [1, "//acme-server/"], / source / 1306 [1, 0], / report-to: none / 1307 [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 / 1308 60000 / lifetime: 60s / 1309 ], 1310 [ 1311 1, / block type code / 1312 1, / block number / 1313 0, / flags / 1314 0, / CRC type: none / 1315 <<[ / type-specific data / 1316 0xFFFF, / record-type-code / 1317 { / record-content / 1318 1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal / 1319 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 1320 } 1321 ]>> 1322 ] 1323 ] 1325 Figure 2: Example Challenge Bundle 1327 B.2. Response Bundle 1329 When the tokens are combined with the key thumbprint, the full Key 1330 Authorization value (a single string split across lines for 1331 readability) is: 1333 "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw." 1334 "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 1336 The minimal-but-valid Response Bundle is shown in Figure 3. This 1337 response indicates that there is 30 seconds remaining in the response 1338 time window. 1340 [_ 1341 [ 1342 7, / BP version / 1343 0x02, / flags: payload-is-an-admin-record / 1344 0, / CRC type: none / 1345 [1, "//acme-server/"], / destination / 1346 [1, "//acme-client/"], / source / 1347 [1, 0], / report-to: none / 1348 [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 / 1349 30000 / lifetime: 30s / 1350 ], 1351 [ 1352 1, / block type code / 1353 1, / block number / 1354 0, / flags / 1355 0, / CRC type: none / 1356 <<[ / block-type-specific data / 1357 0xFFFF, / record-type-code / 1358 { / record-content / 1359 1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal / 1360 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle / 1361 3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' 1362 / key auth. digest / 1363 } 1364 ]>> 1365 ] 1366 ] 1368 Figure 3: Example Response Bundle 1370 Acknowledgments 1372 This specification is based on DTN use cases related to PKIX 1373 certificate issuance. 1375 The workflow and terminology of this validation method was originally 1376 copied from the work of Alexey Melnikov in [RFC8823]. 1378 Author's Address 1380 Brian Sipos 1381 RKF Engineering Solutions, LLC 1382 7500 Old Georgetown Road 1383 Suite 1275 1384 Bethesda, MD 20814-6198 1385 United States of America 1387 Email: brian.sipos+ietf@gmail.com