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