idnits 2.17.1 draft-ietf-acme-dtnnodeid-05.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 (22 September 2021) is 944 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1000000' on line 1253 -- Looks like a reference, but probably isn't: '0' on line 1294 -- Looks like a reference, but probably isn't: '1' on line 1293 -- Looks like a reference, but probably isn't: '1030000' on line 1294 == Outdated reference: A later version (-28) exists of draft-ietf-dtn-tcpclv4-26 == Outdated reference: A later version (-07) exists of draft-bsipos-dtn-bpsec-cose-06 Summary: 0 errors (**), 0 flaws (~~), 3 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 Updates: -ietf-dtn-bpbis (if approved) 22 September 2021 5 Intended status: Experimental 6 Expires: 26 March 2022 8 Automated Certificate Management Environment (ACME) Delay-Tolerant 9 Networking (DTN) Node ID Validation Extension 10 draft-ietf-acme-dtnnodeid-05 12 Abstract 14 This document specifies an extension to the Automated Certificate 15 Management Environment (ACME) protocol which allows an ACME server to 16 validate the Delay-Tolerant Networking (DTN) Node ID for an ACME 17 client. The DTN Node ID is encoded as a certificate Subject 18 Alternative Name (SAN) of type otherName with a name form of 19 "bundleEID" and as an ACME Identifier type "bundleEID". 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 26 March 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 5 57 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6 58 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 59 2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 7 60 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 8 61 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 11 62 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 12 63 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 13 64 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 14 65 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 14 66 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 16 67 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 16 68 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 17 69 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 17 70 5.2. Generating Encryption-only or Signing-only Bundle Security 71 Certificates . . . . . . . . . . . . . . . . . . . . . . 17 72 6. Bundle Protocol Administrative Record Types Registry . . . . 18 73 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 8.1. Threat: Passive Leak of Validation Data . . . . . . . . . 19 76 8.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 19 77 8.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 20 78 8.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 20 79 8.5. Inherited Security Considerations . . . . . . . . . . . . 21 80 8.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 21 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 9.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 22 83 9.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 22 84 9.3. Bundle Administrative Record Types . . . . . . . . . . . 22 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 88 11.2. Informative References . . . . . . . . . . . . . . . . . 25 89 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 27 90 Appendix B. Example Authorization . . . . . . . . . . . . . . . 27 91 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 28 92 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 28 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 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 106 Delay-Tolerant Networking (DTN) bundle. Currently the URI schemes 107 "dtn" 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 SAN URI claim is new to ACME, a new ACME Identifier type 113 "bundleEID" is needed to manage this claim within ACME messaging. A 114 "bundleEID" claim can be part of a pre-authorization or as one of the 115 authorizations of an order containing any number of 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 This document also updates BPv7 to explicitly use the IANA 132 administrative record type registry in Section 6. 134 1.1. Scope 136 This document describes the ACME messages, BPv7 payloads, and BPSec 137 requirements needed to validate Node ID ownership. This document 138 does not address: 140 * Mechanisms for communication between ACME client or ACME server 141 and their associated BP agent(s). This document only describes 142 exchanges between ACME client--server pairs and between their BP 143 agents. 145 * Specific BP extension blocks or BPSec security contexts necessary 146 to fulfill the security requirements of this protocol. The exact 147 security context needed, and their parameters, are network- 148 specific. 150 * Policies or mechanisms for defining or configuring bundle 151 integrity gateways, or trusting integrity gateways on an 152 individual entity or across a network. 154 * Mechanisms for locating or identifying other bundle entities 155 (peers) within a network or across an internet. The mapping of 156 Node ID to potential convergence layer (CL) protocol and network 157 address is left to implementation and configuration of the BP 158 Agent and its various potential routing strategies. 160 * Logic for routing bundles along a path toward a bundle's endpoint. 161 This protocol is involved only in creating bundles at a source and 162 handling them at a destination. 164 * Logic for performing rate control and congestion control of bundle 165 transfers. The ACME server is responsible for rate control of 166 validation requests. 168 * Policies or mechanisms for provisioning, deploying, or accessing 169 certificates and private keys; deploying or accessing certificate 170 revocation lists (CRLs); or configuring security parameters on an 171 individual entity or across a network. 173 * Policies or mechanisms for an ACME server to handle mixed-use 174 certificate requests. This specification is focused only on 175 single-use DTN-specific PKIX profiles. 177 1.2. Authorization Strategy 179 The basic unit of data exchange in a DTN is a Bundle 180 [I-D.ietf-dtn-bpbis], which consists of a data payload with 181 accompanying metadata. An Endpoint ID is used as the destination of 182 a Bundle and can indicate both a unicast or a multicast destination. 183 A Node ID is used to identify the source of a Bundle and is used for 184 routing through intermediate nodes, including the final node(s) used 185 to deliver a Bundle to its destination endpoint. A Node ID can also 186 be used as an endpoint for administrative bundles. More detailed 187 descriptions of the rationale and capabilities of these networks can 188 be found in "Delay-Tolerant Network Architecture" [RFC4838]. 190 When an ACME client requests a pre-authorization or an order with a 191 "bundleEID" identifier type having a value consistent with a Node ID 192 (see Section 4.2.5 of [I-D.ietf-dtn-bpbis]), the ACME server offers a 193 "dtn-nodeid-01" challenge type to validate that Node ID. If the ACME 194 client attempts the authorization challenge to validate a Node ID, 195 the ACME server sends an ACME Node ID Validation Challenge Bundle 196 with a destination of the Node ID being validated. The BP agent on 197 that node receives the Challenge Bundle, generates an ACME key 198 authorization digest, and sends an ACME Node ID Validation Response 199 Bundle in reply. An Integrity Gateway on the client side of the DTN 200 can be used to attest to the source of the Response Bundle. Finally, 201 the ACME server receives the Response Bundle and checks that the 202 digest was generated for the associated ACME challenge and from the 203 client account key associated with the original request. This 204 workflow is shown in the diagram of Figure 1 and defined in 205 Section 3. 207 +------------+ +------------+ 208 | ACME |<===== HTTPS exchanges =====>| ACME | 209 | Client | | Server | 210 +------------+ +------------+ 211 | | ^ 212 (1) Enable or (6) disable (2) Send | | 213 validation from server Challenge | |(5) Indicate 214 | Non-DTN | | Response 215 ~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~ 216 V DTN V | 217 ++------------++ ++------------++ 218 || Admin Elem.|| || Admin Elem.|| 219 |+------------+| (3) Challenge |+------------+| 220 | Client's |<------------- Bundle -----| Server's | 221 | BP Agent | | BP Agent | 222 +--------------+ +--------------+ 223 | ^ 224 | +-------------+ | 225 | | Integrity | (4) Response | 226 +---->| Gateway |------ Bundle --------+ 227 +-------------+ 229 Figure 1: The relationships and flows between Node ID Validation 230 entities 232 Because the DTN Node ID is used both for routing bundles between BP 233 agents and for multiplexing administrative services within a BP 234 agent, there is no possibility to separate the ACME validation of a 235 Node ID from normal bundle handling for that same Node ID. This 236 leaves administrative record types as a way to leave the Node ID 237 unchanged while disambiguating from other service data bundles. 239 There is nothing in this protocol which requires network-topological 240 co-location of either the ACME client or ACME server with their 241 associated BP agent. While ACME requires a low-enough latency 242 network to perform HTTPS exchanges between ACME client and server, 243 the client's BP agent (the one being validated) could be on the far 244 side of a long-delay or multi-hop DTN network. The means by which 245 the ACME client or server communicates with its associated BP agent 246 is an implementation matter. 248 1.3. Use of CDDL 250 This document defines CBOR structure using the Concise Data 251 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure 252 can be extracted from the XML version of this document using the 253 XPath expression: 255 '//sourcecode[@type="cddl"]' 257 The following initial fragment defines the top-level symbols of this 258 document's CDDL, which includes the example CBOR content. 260 start = acme-record / bundle / tstr 262 1.4. Terminology 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 266 "OPTIONAL" in this document are to be interpreted as described in BCP 267 14 [RFC2119] [RFC8174] when, and only when, they appear in all 268 capitals, as shown here. 270 In this document, several terms are shortened for the sake of 271 terseness. These terms are: 273 Challenge Request: This is a shortened form of the full "DTN Node ID 274 Challenge Request Object". It is a JSON object created by the 275 ACME server for challenge type "dtn-nodeid-01". 277 Challenge Response: This is a shortened form of the full "DTN Node 278 ID Challenge Response Object". It is a JSON object created by the 279 ACME client to authorize a challenge type "dtn-nodeid-01". 281 Challenge Bundle: This is a shortened form of the full "ACME Node ID 282 Validation Challenge Bundle". It is a Bundle created by the BP 283 agent managed by the ACME server to challenge a Node ID claim. 285 Response Bundle: This is a shortened form of the full "ACME Node ID 286 Validation Response Bundle". It is a Bundle created by the BP 287 agent managed by the ACME client to validate a Node ID claim. 289 2. Bundle Endpoint ID ACME Identifier 291 This specification is the first to make use of an Bundle Endpoint ID 292 to identify a claim for a certificate request in ACME. In this 293 document, the only purpose for which an Bundle Endpoint ID ACME 294 identifier is validated is as a DTN Node ID (see Section 3), but 295 other specifications can define challenge types for other Endpoint ID 296 uses. 298 Identifiers of type "bundleEID" in certificate requests MUST appear 299 in an extensionRequest attribute [RFC2985] containing a 300 subjectAltName extension of type otherName with a name form of 301 "bundleEID" consistent with the requirements of Section 4.4.2.1 of 302 [I-D.ietf-dtn-tcpclv4]. Because the bundleEID is encoded as an 303 IA5String it SHALL be treated as being in the percent-encoded form of 304 Section 2.1 of [RFC3986]. Any "bundleEID" identifier which fails to 305 properly percent-decode SHALL be rejected with an ACME error type of 306 "malformed". 308 The ACME server SHALL decode and normalize (based on scheme-specific 309 syntax) all received identifiers of type "bundleEID". Any 310 "bundleEID" identifier request which uses a scheme not handled by the 311 ACME server or for which the URI does not match the scheme-specific 312 syntax SHALL be rejected with an ACME error type of 313 "rejectedIdentifier". 315 When an ACME server needs to request proof that a client controls a 316 URI, it SHALL create an authorization with the identifier type 317 "bundleEID". The ACME server SHALL NOT attempt to dereference the 318 Endpoint ID value on its own. It is the responsibility of a 319 validation method to ensure the URI ownership via scheme-specific 320 means authorized by the ACME client. 322 An identifier for the Node ID of "dtn://example/" would be formatted 323 as: 325 {"type": "bundleEID", "value": "dtn://example/"} 327 3. DTN Node ID Validation 329 The DTN Node ID validation method proves control over a Node ID by 330 requiring the ACME client to configure a BP agent to respond to 331 specific Challenge Bundles sent from the ACME server. The ACME 332 server validates control of the Node ID URI by verifying that 333 received Response Bundles correspond with the BP Node and client 334 account key being validated. 336 Similar to the ACME use case for validating email address ownership 337 [RFC8823], this challenge splits the token into several parts, each 338 being transported by a different channel, and the Key Authorization 339 result requires combining all parts of the token. The token parts 340 are: 342 "token-chal" This token is unique to, and constant for, each ACME 343 authorization. It is contained in the Challenge Object of 344 Section 3.1 as well as the Challenge Bundle of Section 3.3 and 345 Response Bundle of Section 3.4. Each authorization can consist of 346 multiple Challenge Bundles (e.g. taking different routes), but 347 they all share the same "token-chal" value. This ensures that the 348 Key Authorization is bound to the specific ACME challenge (and 349 parent ACME authorization) and also allows the ACME client's BP 350 agent to filter-in only valid Challenge Bundles. This token is 351 also accessible to DTN on-path eavesdroppers. 353 "token-bundle" This token is unique to each Challenge Bundle sent by 354 the ACME server. It is contained in the Challenge Bundle of 355 Section 3.3 and Response Bundle of Section 3.4. This ensures that 356 the Key Authorization is bound to the ability to receive the 357 Challenge Bundle and not just have access to the ACME Challenge 358 Object. This token is also accessible to DTN on-path 359 eavesdroppers. 361 The DTN Node ID Challenge SHALL only be allowed for URIs usable as a 362 DTN Node ID, which are currently the schemes "dtn" and "ipn" as 363 defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node 364 ID validation, the ACME server SHALL define a challenge object in 365 accordance with Section 3.1. Once this challenge object is defined, 366 the ACME client may begin the validation. 368 To initiate a Node ID validation, the ACME client performs the 369 following steps: 371 1. The ACME client POSTs a newOrder or newAuthz request including 372 the identifier of type "bundleEID" for the desired Node ID. From 373 either of these entry points an authorization for the "bundleEID" 374 type is indicated by the ACME server. See Section 7.4 of 375 [RFC8555] for more details. 377 2. The ACME client obtains the challenge source Node ID and "token- 378 chal" from the challenge object in accordance with Section 3.1. 380 3. The ACME client indicates to the administrative element of its BP 381 agent the source Node ID and challenge "token-chal" which is 382 authorized for use and the associated client account key 383 thumbprint. The ACME client SHALL wait, if necessary, until the 384 agent is configured before proceeding to the next step. 386 4. The ACME client POSTs a challenge response to the challenge URL 387 on the ACME server accordance with Section 7.5.1 of [RFC8555]. 388 The payload object is constructed in accordance with Section 3.2. 390 5. The administrative element waits for a Challenge Bundle to be 391 received with the authorized ACME parameters, including its 392 "token-bundle" payload, in accordance with Section 3.3. 394 6. The administrative element concatenates "token-bundle" with 395 "token-chal" (each as base64url-encoded text strings) and 396 computes the Key Authorization in accordance with Section 8.1 of 397 [RFC8555] using the full token and client account key thumbprint. 399 7. The administrative element computes the SHA-256 digest of the Key 400 Authorization result and generates a Response Bundle to send back 401 to the ACME server in accordance with Section 3.4. 403 8. The ACME client waits for the authorization to be finalized on 404 the ACME server in accordance with Section 7.5.1 of [RFC8555]. 406 9. Once the challenge is completed (successfully or not), the ACME 407 client indicates to the BP agent that the validation source and 408 "token-chal" is no longer usable. If the authorization fails, 409 the ACME client MAY retry the challenge from Step 3. 411 The ACME server verifies the client's control over a Node ID by 412 performing the following steps: 414 1. The ACME server receives a newOrder or newAuthz request including 415 the identifier of type "bundleEID", where the URI value is a Node 416 ID. 418 2. The ACME server generates an authorization for the Node ID with 419 challenge type "dtn-nodeid-01" in accordance with Section 3.1. 421 3. The ACME server receives a POST to the challenge URL indicated 422 from the authorization object. The payload is handled in 423 accordance with Section 3.2. 425 4. The ACME server sends, via the administrative element of its BP 426 agent, one or more Challenge Bundles in accordance with 427 Section 3.3. Each challenge bundle SHALL contain a distinct 428 "token-bundle" to be able to correlate with a response bundle. 429 Computing an expected Key Authorization digest is not necessary 430 until a response is received. 432 5. The ACME server waits for Response Bundle(s) for a limited 433 interval of time (based on the challenge response object of 434 Section 3.2). Responses are encoded in accordance with 435 Section 3.4. 437 6. Once received and decoded, the ACME server checks the contents of 438 each Response Bundle in accordance with Section 3.4.1. After all 439 Challenge Bundles have either been responded to or timed-out, the 440 validation procedure is successful only if all responses are 441 successful. If validation is not successful, a client may retry 442 the challenge which starts in Step 3. 444 An ACME server MAY send multiple challenges from different origins in 445 the DTN network to avoid possible on-path attacks, as recommended in 446 Section 10.2 of [RFC8555]. If responses are received from multiple 447 challenges, any response failure SHALL cause a failure of the overall 448 validation. Each response failure MAY be indicated to the ACME 449 client as a validation subproblem. 451 When responding to a Challenge Bundle, a BP agent SHALL send a single 452 Response Bundle in accordance with Section 3.4. A BP agent SHALL 453 respond to ACME challenges only within the interval of time, only for 454 the Node ID, and only for the "token-chal" indicated by the ACME 455 client. A BP agent SHALL respond to multiple challenges with the 456 same parameters. 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, string): The source Node ID of bundles originating 469 at the ACME server as a text URI. 471 token-chal (required, string): A random value that uniquely 472 identifies the challenge. This value MUST have at least 128 bits 473 of entropy. It MUST NOT contain any characters outside the 474 base64url alphabet as described in Section 5 of [RFC4648]. 475 Trailing '=' padding characters MUST be stripped. See [RFC4086] 476 for additional information on randomness requirements. 478 { 479 "type": "dtn-nodeid-01", 480 "url": "https://example.com/acme/chall/prV_B7yEyA4", 481 "source": "dtn://acme-server/", 482 "token-chal": "tPUZNY4ONIk6LxErRFEjVw" 483 } 484 The "token-chal" value included in this object is fixed for the 485 entire challenge, and may correspond with multiple separate "token- 486 bundle" values when multiple Challenge Bundles are sent for a single 487 validation. 489 3.2. DTN Node ID Challenge Response Object 491 The DTN Node ID Challenge response object is defined by the ACME 492 client when it authorizes validation of a Node ID. Because a DTN has 493 the potential for significantly longer delays than a non-DTN network, 494 the ACME client is able to inform the ACME server if a particular 495 validation round-trip is expected to take longer than normal network 496 delays (on the order of seconds). 498 The DTN Node ID Challenge response object has the following content: 500 rtt (optional, number): An expected round-trip time (RTT), in 501 seconds, between sending a Challenge Bundle and receiving a 502 Response Bundle. This value is a hint to the ACME server for how 503 long to wait for responses but is not authoritative. The minimum 504 RTT value SHALL be zero. There is no special significance to 505 zero-value RTT, it simply indicates the response is expected in 506 less than the least significant unit used by the ACME client. 508 { 509 "rtt": 300.0 510 } 512 A challenge response is not sent until the BP agent has been 513 configured to properly respond to the challenge, so the RTT value is 514 meant to indicate any node-specific path delays expected to 515 encountered from the ACME server. Because there is no requirement on 516 the path (or paths) which bundles may traverse between the ACME 517 server and the BP agent, and the ACME server can attempt some path 518 diversity, the RTT value SHOULD be pessimistic. 520 A default bundle response interval, used when the object does not 521 contain an RTT, SHOULD be a configurable parameter of the ACME 522 server. If the ACME client indicated an RTT value in the object, the 523 response interval SHOULD be twice the RTT (with limiting logic 524 applied as described below). The lower limit on response interval is 525 network-specific, but SHOULD NOT be shorter than one second. The 526 upper limit on response interval is network-specific, but SHOULD NOT 527 be longer than one minute (60 seconds) for a terrestrial-only DTN. 529 3.3. ACME Node ID Validation Challenge Bundles 531 Each ACME Node ID Validation Challenge Bundle SHALL be structured and 532 encoded in accordance with [I-D.ietf-dtn-bpbis]. 534 Each Challenge Bundle has parameters as listed here: 536 Bundle Processing Control Flags: The primary block flags SHALL 537 indicate that the payload is an administrative record. The 538 primary block flags SHALL indicate that user application 539 acknowledgement is requested; this flag distinguishes the 540 Challenge Bundle from the Response Bundle. The primary block 541 flags MAY indicate that status reports are requested; such status 542 can be helpful to troubleshoot routing issues. 544 Destination EID: The Destination EID SHALL be identical to the Node 545 ID being validated. The ACME server SHOULD NOT perform URI 546 normalization on the Node ID given by the ACME client. 548 Source Node ID: The Source Node ID SHALL indicate the Node ID of the 549 BP agent of the ACME server performing the challenge. 551 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 552 to the time at which the challenge was generated. The Lifetime 553 SHALL indicate the response interval (of Section 3.2) for which 554 ACME server will accept responses to this challenge. 556 Administrative Record Type Code: Set to the ACME Node ID Validation 557 type code defined in Section 9.3. 559 Administrative Record Content: The Challenge Bundle administrative 560 record content SHALL consist of a CBOR map containing two pairs: 562 * One pair SHALL consist of key 1 with value of ACME challenge 563 "token-chal", copied from the challenge object, represented as 564 a CBOR byte string. 566 * One pair SHALL consist of key 2 with value of ACME challenge 567 "token-bundle", represented as a CBOR byte string. The "token- 568 bundle" is a random value that uniquely identifies the 569 challenge bundle. This value MUST have at least 128 bits of 570 entropy. See [RFC4086] for additional information on 571 randomness requirements. 573 This structure is part of the extension CDDL in Appendix A. An 574 example full Challenge Bundle is included in Appendix B.1 575 If the BP agent generating a Challenge Bundle does not have a well- 576 synchronized clock or the agent responding to the challenge is 577 expected to not have a well-synchronized clock, the bundle SHALL 578 include a Bundle Age extension block. 580 Challenge Bundles SHALL include a Block Integrity Block (BIB) in 581 accordance with Section 4 or with a Security Source identical to the 582 bundle Source Node. Challenge Bundles SHALL NOT be directly 583 encrypted by Block Confidentiality Block (BCB) or any other method 584 (see Section 8.1). 586 3.3.1. Challenge Bundle Checks 588 A proper Challenge Bundle meets all of the following criteria: 590 * The Challenge Bundle was received within the time interval allowed 591 for the challenge. The allowed interval starts at the Creation 592 Timestamp and extends for the Lifetime of the Challenge Bundle. 594 * The Challenge Bundle Source Node ID is identical to the Node ID 595 indicated in the ACME challenge object. The comparison of Node 596 IDs SHALL use the comparison logic of [RFC3986] and scheme-based 597 normalization of those schemes specified in [I-D.ietf-dtn-bpbis]. 599 * The Challenge Bundle contains a BIB which covers at least the 600 primary block and payload. That BIB has a security source which 601 is trusted and passes security-context-specific validation (i.e. 602 MAC or signature verification). 604 * The challenge payload contains the "token-chal" as indicated in 605 the ACME challenge object. The challenge payload contains a 606 "token-bundle" meeting the definition in Section 3.3. 608 Any of the failures above SHALL cause the challenge bundle to be 609 deleted and otherwise ignored by the BP agent. The BP agent MAY send 610 status reports about the deletion if allowed by security policy. 612 3.4. ACME Node ID Validation Response Bundles 614 Each ACME Node ID Validation Response Bundle SHALL be structured and 615 encoded in accordance with [I-D.ietf-dtn-bpbis]. 617 Each Response Bundle has parameters as listed here: 619 Bundle Processing Control Flags: The primary block flags SHALL 620 indicate that the payload is an administrative record. The 621 primary block flags SHALL NOT indicate that user application 622 acknowledgement is requested; this flag distinguishes the Response 623 Bundle from the Challenge Bundle. The primary block flags MAY 624 indicate that status reports are requested; such status can be 625 helpful to troubleshoot routing issues. 627 Destination EID: The Destination EID SHALL be identical to the 628 Source Node ID of the Challenge Bundle to which this response 629 corresponds. 631 Source Node ID: The Source Node ID SHALL be identical to the 632 Destination EID of the Challenge Bundle to which this response 633 corresponds. 635 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 636 to the time at which the response was generated. The response 637 Lifetime SHALL indicate the response interval remaining if the 638 Challenge Bundle indicated a limited Lifetime. 640 Administrative Record Type Code: Set to the ACME Node ID Validation 641 type code defined in Section 9.3. 643 Administrative Record Content: The Response Bundle administrative 644 record content SHALL consist of a CBOR map containing three pairs: 646 * One pair SHALL consist of key 1 with value of ACME challenge 647 "token-chal", copied from the Request Bundle, represented as a 648 CBOR byte string. 650 * One pair SHALL consist of key 2 with value of ACME challenge 651 "token-bundle", copied from the Request Bundle, represented as 652 a CBOR byte string. 654 * One pair SHALL consist of key 3 with value of the SHA-256 655 digest [FIPS180-4] of the ACME Key Authorization in accordance 656 with Section 8.1 of [RFC8555], represented as a CBOR byte 657 string. 659 This structure is part of the extension CDDL in Appendix A. An 660 example full Response Bundle is included in Appendix B.2 662 If the BP agent responding to a Challenge Bundle does not have a 663 well-synchronized clock, it SHALL use any information about last-hop 664 delays and (if present) Bundle Age extension data to infer the age of 665 the Challenge Bundle and lifetime of the Response Bundle. 667 Response Bundles SHALL include a BIB in accordance with Section 4. 668 Response Bundles SHALL NOT be directly encrypted by BCB or any other 669 method (see Section 8.1 for explanation). 671 3.4.1. Response Bundle Checks 673 A proper Response Bundle meets all of the following criteria: 675 * The Response Bundle was received within the time interval allowed 676 for the challenge. The allowed interval starts at the Creation 677 Timestamp and extends for the Lifetime of the Response Bundle. 679 * The Response Bundle Source Node ID is identical to the Node ID 680 being validated. The comparison of Node IDs SHALL use the 681 comparison logic of [RFC3986] and scheme-based normalization of 682 those schemes specified in [I-D.ietf-dtn-bpbis]. 684 * The Response Bundle contains a BIB which covers at least the 685 primary block and payload. That BIB has a security source which 686 is trusted and passes security-context-specific validation. 688 * The response payload contains the "token-chal" and "token-bundle" 689 as sent in the Challenge Bundle. The response payload contains 690 the expected Key Authorization digest computed by the ACME server. 691 Because multiple Challenge Bundles can be sent to validate the 692 same Node ID, the "token-bundle" in the response is needed to 693 correlate with the expected Key Authorization digest. 695 Any of the failures above SHALL cause the validation to fail with an 696 ACME error type of "incorrectResponse". Any of the failures above 697 SHOULD be indicated as subproblems to the ACME client. The lack of a 698 response within the expected response interval, as defined in 699 Section 3.2, SHALL also be treated as a validation failure. 701 4. Bundle Integrity Gateway 703 This section defines a BIB use which closely resembles the function 704 of DKIM email signing [RFC6376]. In this mechanism a routing node in 705 a DTN sub-network attests to the origination of a bundle by adding a 706 BIB before forwarding it. The bundle receiver then need not trust 707 the source of the bundle, but only trust this security source node. 708 The receiver needs policy configuration to know which security 709 sources are permitted to attest for which bundle sources. 711 An integrity gateway SHALL validate the Source Node ID of a bundle, 712 using local-network-specific means, before adding a BIB to the 713 bundle. The exact means by which an integrity gateway validates a 714 bundle's source is network-specific, but could use physical-layer, 715 network-layer or BP-convergence-layer authentication. The bundle 716 source could also add its own BIB with a local-network-specific 717 security context or local-network-specific key material (i.e. a group 718 key shared within the local network). 720 When an integrity gateway adds a BIB it SHALL be in accordance with 721 [I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload 722 block and the primary block (either directly as a target or as 723 additional authenticated data for the payload block MAC/signature). 724 The Security Source of this BIB SHALL be either the bundle source 725 Node ID itself or a routing node trusted by the destination node (see 726 Section 8.2). 728 5. Certificate Request Profile 730 The ultimate purpose of this ACME validation is to allow a CA to 731 issue certificates following the profiles of Section 4.4.2 of 732 [I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and 733 [I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as 734 bundle security certificates. 736 One defining aspect of bundle security certificates is the Extended 737 Key Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When 738 requesting a certificate which includes a Node ID SAN, the CSR SHOULD 739 include an Extended Key Usage of id-kp-bundleSecurity. When a bundle 740 security certificate is issued based on a validated Node ID SAN, the 741 certificate SHALL include an Extended Key Usage of id-kp- 742 bundleSecurity. 744 5.1. Multiple Identity Claims 746 A single bundle security CSR MAY contain a mixed set of SAN claims, 747 including combinations of "ip", "dns", and "bundleEID" claims. There 748 is no restriction on how a certificate combines these claims, but 749 each claim MUST be validated by an ACME server to issue such a 750 certificate as part of an associated ACME order. This is no 751 different than the existing behavior of [RFC8555] but is mentioned 752 here to make sure that CA policy handles such situations; especially 753 related to validation failure of an identifier in the presence of 754 multiple identifiers. The specific use case of 755 [I-D.ietf-dtn-tcpclv4] allows, and for some network policies 756 requires, that a certificate authenticate both the DNS name of an 757 entity as well as the Node ID of the entity. 759 5.2. Generating Encryption-only or Signing-only Bundle Security 760 Certificates 762 ACME extensions specified in this document can be used to request 763 encryption-only or signing-only bundle security certificates. 765 In order to request signing only bundle security certificate, the CSR 766 MUST include the key usage extension with digitalSignature and/or 767 nonRepudiation bits set and no other bits set. 769 In order to request encryption only bundle security certificate, the 770 CSR MUST include the key usage extension with keyEncipherment or 771 keyAgreement bits set and no other bits set. 773 Presence of both of the above sets of key usage bits in the CSR, as 774 well as absence of key usage extension in the CSR, signals to ACME 775 server to issue a bundle security certificate suitable for both 776 signing and encryption. 778 6. Bundle Protocol Administrative Record Types Registry 780 This document updates the requirements in Section 6.1 of 781 [I-D.ietf-dtn-bpbis] to use an existing IANA registry and updates 782 that sub-registry in Section 9.3. 784 Instead of using the explicit list of types in Table 3 of 785 [I-D.ietf-dtn-bpbis], a BP Agent SHALL interpret administrative 786 record type code values in accordance with the IANA "Administrative 787 Record Types" sub-registry for entries having a "Bundle Protocol 788 Version" of 7. Additionally, this document clarifies the zero-value 789 reservation for BPv7 and makes a reservation of high-valued record 790 type codes for "private or experimental use" which applies only to 791 BPv7. 793 7. Implementation Status 795 This section is to be removed before publishing as an RFC. 797 [NOTE to the RFC Editor: please remove this section before 798 publication, as well as the reference to [RFC7942] and 799 [github-dtn-demo-agent] and [github-dtn-wireshark].] 801 This section records the status of known implementations of the 802 protocol defined by this specification at the time of posting of this 803 Internet-Draft, and is based on a proposal described in [RFC7942]. 804 The description of implementations in this section is intended to 805 assist the IETF in its decision processes in progressing drafts to 806 RFCs. Please note that the listing of any individual implementation 807 here does not imply endorsement by the IETF. Furthermore, no effort 808 has been spent to verify the information presented here that was 809 supplied by IETF contributors. This is not intended as, and must not 810 be construed to be, a catalog of available implementations or their 811 features. Readers are advised to note that other implementations can 812 exist. 814 An example implementation of the this draft of ACME Node ID 815 Validation has been created as a GitHub project 816 [github-dtn-demo-agent] and is intended to use as a proof-of-concept 817 and as a possible source of interoperability testing. 819 A Wireshark dissector for of the this draft of ACME Node ID 820 Validation has been created as a GitHub project 821 [github-dtn-wireshark] and is intended to be used to inspect and 822 troubleshoot implementations. 824 8. Security Considerations 826 This section separates security considerations into threat categories 827 based on guidance of BCP 72 [RFC3552]. 829 8.1. Threat: Passive Leak of Validation Data 831 Because this challenge mechanism is used to bootstrap security 832 between DTN Nodes, the challenge and its response are likely to be 833 transferred in plaintext. The only ACME data present on-the-wire is 834 a random token and a cryptographic digest, so there is no sensitive 835 data to be leaked within the Node ID Validation bundle exchange. 836 Because each challenge uses a separate token, there is no value in an 837 on-path attacker seeing the tokens from past challenges and/or 838 responses. 840 It is possible for intermediate BP nodes to encapsulate-and-encrypt 841 Challenge and/or Response Bundles while they traverse untrusted 842 networks, but that is a DTN configuration matter outside of the scope 843 of this document. 845 8.2. Threat: BP Node Impersonation 847 As described in Section 8.1 of [RFC8555], it is possible for an 848 active attacker to alter data on both ACME client channel and the DTN 849 validation channel. 851 The primary mitigation is to delegate bundle integrity sourcing to a 852 trusted routing node near, in the sense of bundle routing topology, 853 to the bundle source node as defined in Section 4. This is 854 functionally similar to DKIM signing of [RFC6376] and provides some 855 level of bundle origination. 857 Another way to mitigate single-path on-path attacks is to attempt 858 validation of the same Node ID via multiple bundle routing paths, as 859 recommended in Section 3. It is not a trivial task to guarantee 860 bundle routing though, so more advanced techniques such as onion 861 routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) 862 could be employed. 864 8.3. Threat: Bundle Replay 866 It is possible for an on-path attacker to replay both Challenge 867 Bundles or Response Bundles. Even in a properly-configured DTN it is 868 possible that intermediate bundle routers to use multicast forwarding 869 of a unicast-destination bundle. 871 Ultimately, the point of the ACME bundle exchange is to derive a Key 872 Authorization and its cryptographic digest and communicate it back to 873 the ACME server for validation, so the uniqueness of the Key 874 Authorization directly determines the scope of replay validity. The 875 uniqueness of each "token-bundle" to each challenge bundle ensures 876 that the Key Authorization is unique to the challenge bundle. The 877 uniqueness of each "token-chal" to the ACME challenge ensures that 878 the Key Authorization is unique to that ACME challenge. 880 Having each bundle's primary block and payload block covered by a BIB 881 from a trusted security source (see Section 4) ensures that a 882 replayed bundle cannot be altered in the blocks used by ACME. All 883 together, these properties mean that there is no degraded security 884 caused by replay of either a Challenge Bundle or a Response Bundle 885 even in the case where the primary or payload block is not covered by 886 a BIB. The worst that can come of bundle replay is the waste of 887 network resources as described in Section 8.4. 889 8.4. Threat: Denial of Service 891 The behaviors described in this section all amount to a potential 892 denial-of-service to a BP agent. 894 A malicious entity can continually send Challenge Bundles to a BP 895 agent. The victim BP agent can ignore Challenge Bundles which do not 896 conform to the specific time interval and challenge token for which 897 the ACME client has informed the BP agent that challenges are 898 expected. The victim BP agent can require all Challenge Bundles to 899 be BIB-signed to ensure authenticity of the challenge. 901 A malicious entity can continually send Response Bundles to a BP 902 agent. The victim BP agent can ignore Response Bundles which do not 903 conform to the specific time interval or Source Node ID or challenge 904 token for an active Node ID validation. 906 Similar to other validation methods, an ACME server validating a DTN 907 Node ID could be used as a denial of service amplifier. For this 908 reason any ACME server can rate-limit validation activities for 909 individual clients and individual certificate requests. 911 8.5. Inherited Security Considerations 913 Because this protocol relies on ACME for part of its operation, the 914 security considerations of [RFC8555] apply to all ACME client--server 915 exchanges during Node ID validation. 917 Because this protocol relies on BPv7 for part of its operation, the 918 security considerations of [I-D.ietf-dtn-bpbis] and 919 [I-D.ietf-dtn-bpsec] apply to all BP messaging during Node ID 920 validation. 922 8.6. Out-of-Scope BP Agent Communication 924 Although messaging between an ACME client or ACME server an its 925 associated BP agent are out-of-scope for this document, both of those 926 channels are critical to Node ID validation security. Either channel 927 can potentially leak data or provide attack vectors if not properly 928 secured. These channels need to protect against spoofing of 929 messaging in both directions to avoid interruption of normal 930 validation sequencing and to prevent false validations from 931 succeeding. 933 The ACME server and its BP agent exchange the outgoing "token-chal", 934 "token-bundle", and Key Authorization digest but these values do not 935 need to be confidential (they are also in plaintext over the BP 936 channel). 938 Depending on implementation details, the ACME client might transmit 939 the client account key thumbprint to its BP agent to allow computing 940 the Key Authorization digest on the BP agent. If an ACME client does 941 transmit its client account key thumbprint to a BP agent, it is 942 important that this data is kept confidential because it provides the 943 binding of the client account key to the Node ID validation (as well 944 as for all other types of ACME validation). Avoiding this 945 transmission would require a full round-trip between BP agent and 946 ACME client, which can be undesirable if the two are separated by a 947 long-delay network. 949 9. IANA Considerations 951 This specification adds to the ACME registry and BP registry for this 952 behavior. 954 9.1. ACME Identifier Types 956 Within the "Automated Certificate Management Environment (ACME) 957 Protocol" registry [IANA-ACME], the following entry has been added to 958 the "ACME Identifier Types" sub-registry. 960 +=======+==================================+ 961 | Label | Reference | 962 +=======+==================================+ 963 | uri | This specification and [RFC3986] | 964 +-------+----------------------------------+ 966 Table 1 968 9.2. ACME Validation Methods 970 Within the "Automated Certificate Management Environment (ACME) 971 Protocol" registry [IANA-ACME], the following entry has been added to 972 the "ACME Validation Methods" sub-registry. 974 +===============+=================+======+====================+ 975 | Label | Identifier Type | ACME | Reference | 976 +===============+=================+======+====================+ 977 | dtn-nodeid-01 | uri | Y | This specification | 978 +---------------+-----------------+------+--------------------+ 980 Table 2 982 9.3. Bundle Administrative Record Types 984 Within the "Bundle Protocol" registry [IANA-BP], the "Bundle 985 Administrative Record Types" sub-registry has been updated to include 986 a leftmost "Bundle Protocol Version" column. The existing sub- 987 registry entries have been updated to have BP versions as in the 988 following table. 990 +=================+=======+===============+======================+ 991 | Bundle Protocol | Value | Description | Reference | 992 | Version | | | | 993 +=================+=======+===============+======================+ 994 | 6,7 | 0 | Reserved | [RFC7116] | 995 +-----------------+-------+---------------+----------------------+ 996 | 6,7 | 1 | Bundle status | [RFC5050] | 997 | | | report | [I-D.ietf-dtn-bpbis] | 998 +-----------------+-------+---------------+----------------------+ 999 | 6 | 2 | Custody | [RFC5050] | 1000 | | | signal | | 1001 +-----------------+-------+---------------+----------------------+ 1002 | 6,7 | 3-15 | Unassigned | | 1003 +-----------------+-------+---------------+----------------------+ 1005 Table 3 1007 Within the "Bundle Protocol" registry [IANA-BP], the following 1008 entries have been added to the "Bundle Administrative Record Types" 1009 sub-registry. [NOTE to the RFC Editor: For RFC5050 compatibility the 1010 TBD value needs to be no larger than 15, but such compatibility is 1011 not needed. For BPbis the TBD value needs to be no larger than 1012 65535.] 1014 +=================+==========+======================+===============+ 1015 | Bundle Protocol | Value | Description | Reference | 1016 | Version | | | | 1017 +=================+==========+======================+===============+ 1018 | 7 | TBD | ACME Node ID | This | 1019 | | | Validation | specification | 1020 +-----------------+----------+----------------------+---------------+ 1021 | 7 | 16-65535 | Unassigned | | 1022 +-----------------+----------+----------------------+---------------+ 1023 | 7 | >= 65536 | Reserved for | This | 1024 | | | Private or | specification | 1025 | | | Experimental Use | | 1026 +-----------------+----------+----------------------+---------------+ 1028 Table 4 1030 10. Acknowledgments 1032 This specification is based on DTN use cases related to PKIX 1033 certificate issuance. 1035 The workflow and terminology of this validation method was originally 1036 copied from the work of Alexey Melnikov in [RFC8823]. 1038 11. References 1040 11.1. Normative References 1042 [FIPS180-4] 1043 National Institute of Standards and Technology, "Secure 1044 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 1045 . 1048 [IANA-ACME] 1049 IANA, "Automated Certificate Management Environment (ACME) 1050 Protocol", . 1052 [IANA-BP] IANA, "Bundle Protocol", 1053 . 1055 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", 1056 . 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, 1060 DOI 10.17487/RFC2119, March 1997, 1061 . 1063 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1064 Classes and Attribute Types Version 2.0", RFC 2985, 1065 DOI 10.17487/RFC2985, November 2000, 1066 . 1068 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1069 Text on Security Considerations", BCP 72, RFC 3552, 1070 DOI 10.17487/RFC3552, July 2003, 1071 . 1073 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1074 Resource Identifier (URI): Generic Syntax", STD 66, 1075 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1076 . 1078 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1079 "Randomness Requirements for Security", BCP 106, RFC 4086, 1080 DOI 10.17487/RFC4086, June 2005, 1081 . 1083 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1084 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1085 . 1087 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1088 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1089 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1090 April 2007, . 1092 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1093 Housley, R., and W. Polk, "Internet X.509 Public Key 1094 Infrastructure Certificate and Certificate Revocation List 1095 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1096 . 1098 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1099 Code: The Implementation Status Section", BCP 205, 1100 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1101 . 1103 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1104 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1105 May 2017, . 1107 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1108 Kasten, "Automatic Certificate Management Environment 1109 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1110 . 1112 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1113 Definition Language (CDDL): A Notational Convention to 1114 Express Concise Binary Object Representation (CBOR) and 1115 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1116 June 2019, . 1118 [I-D.ietf-dtn-bpbis] 1119 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle 1120 Protocol Version 7", Work in Progress, Internet-Draft, 1121 draft-ietf-dtn-bpbis-31, 25 January 2021, 1122 . 1125 [I-D.ietf-dtn-bpsec] 1126 III, E. J. B. and K. McKeever, "Bundle Protocol Security 1127 Specification", Work in Progress, Internet-Draft, draft- 1128 ietf-dtn-bpsec-27, 16 February 2021, 1129 . 1132 11.2. Informative References 1134 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1135 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1136 2007, . 1138 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1139 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1140 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1141 . 1143 [RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission 1144 Protocol (LTP), Compressed Bundle Header Encoding (CBHE), 1145 and Bundle Protocol IANA Registries", RFC 7116, 1146 DOI 10.17487/RFC7116, February 2014, 1147 . 1149 [RFC8823] Melnikov, A., "Extensions to Automatic Certificate 1150 Management Environment for End-User S/MIME Certificates", 1151 RFC 8823, DOI 10.17487/RFC8823, April 2021, 1152 . 1154 [I-D.ietf-dtn-bibect] 1155 Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in 1156 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 1157 February 2020, . 1160 [I-D.ietf-dtn-tcpclv4] 1161 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 1162 Tolerant Networking TCP Convergence Layer Protocol Version 1163 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 1164 tcpclv4-26, 15 February 2021, 1165 . 1168 [I-D.sipos-dtn-udpcl] 1169 Sipos, B., "Delay-Tolerant Networking UDP Convergence 1170 Layer Protocol", Work in Progress, Internet-Draft, draft- 1171 sipos-dtn-udpcl-01, 26 March 2021, 1172 . 1175 [I-D.bsipos-dtn-bpsec-cose] 1176 Sipos, B., "DTN Bundle Protocol Security COSE Security 1177 Context", Work in Progress, Internet-Draft, draft-bsipos- 1178 dtn-bpsec-cose-06, 3 June 2021, 1179 . 1182 [github-dtn-demo-agent] 1183 Sipos, B., "Python implementation of basic BPv7-related 1184 protocols", 1185 . 1187 [github-dtn-wireshark] 1188 Sipos, B., "Wireshark Dissectors for BPv7-related 1189 Protocols", 1190 . 1192 Appendix A. Administrative Record Types CDDL 1194 [NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the 1195 "ACME Node ID Validation" administrative record type code.] 1197 The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles 1198 is: 1200 ; All ACME records have the same structure 1201 $admin-record /= [0xFFFF, acme-record] 1202 acme-record = { 1203 token-chal, 1204 token-bundle, 1205 ? key-auth-digest ; present for Response Bundles 1206 } 1207 token-chal = (1 => bstr) 1208 token-bundle = (2 => bstr) 1209 key-auth-digest = (3 => bstr) 1211 Appendix B. Example Authorization 1213 [NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced 1214 by the "ACME Node ID Validation" administrative record type code.] 1216 This example is a bundle exchange for the ACME server with Node ID 1217 "dtn://acme-server/" performing a verification for ACME client Node 1218 ID "dtn://acme-client/". The example bundles use no block CRC or 1219 BPSec integrity, which is for simplicity and is not recommended for 1220 normal use. The provided figures are extended diagnostic notation 1221 [RFC8610]. 1223 For this example the ACME client key thumbprint has the base64url 1224 encoded value of: 1226 "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 1228 And the ACME-server generated "token-chal" has the base64url-encoded 1229 value of: 1231 "tPUZNY4ONIk6LxErRFEjVw" 1233 B.1. Challenge Bundle 1235 For the single challenge bundle in this example, the "token-bundle" 1236 (transported as byte string via BP) has the base64url-encoded value 1237 of: 1239 "p3yRYFU4KxwQaHQjJ2RdiQ" 1241 The minimal-but-valid Challenge Bundle is shown in Figure 2. This 1242 challenge requires that the ACME client respond within a 60 second 1243 time window. 1245 [ 1246 [ 1247 7, / BP version / 1248 0x22, / flags: user-app-ack, payload-is-an-admin-record / 1249 0, / CRC type: none / 1250 [1, "//acme-client/"], / destination / 1251 [1, "//acme-server/"], / source / 1252 [1, "//acme-server/"], / report-to / 1253 [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 / 1254 60000 / lifetime: 60s / 1255 ], 1256 [ 1257 1, / block type code / 1258 1, / block number / 1259 0, / flags / 1260 0, / CRC type: none / 1261 <<[ / type-specific data / 1262 0xFFFF, / record-type-code / 1263 { / record-content / 1264 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / 1265 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 1266 } 1267 ]>> 1268 ] 1269 ] 1271 Figure 2: Example Challenge Bundle 1273 B.2. Response Bundle 1275 When the tokens are combined with the key thumbprint, the full Key 1276 Authorization value (a single string split across lines for 1277 readability) is: 1279 "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw." 1280 "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 1282 The minimal-but-valid Response Bundle is shown in Figure 3. This 1283 response indicates that there is 30 seconds remaining in the response 1284 time window. 1286 [ 1287 [ 1288 7, / BP version / 1289 0x02, / flags: payload-is-an-admin-record / 1290 0, / CRC type: none / 1291 [1, "//acme-server/"], / destination / 1292 [1, "//acme-client/"], / source / 1293 [1, 0], / report-to: none / 1294 [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 / 1295 30000 / lifetime: 30s / 1296 ], 1297 [ 1298 1, / block type code / 1299 1, / block number / 1300 0, / flags / 1301 0, / CRC type: none / 1302 <<[ / block-type-specific data / 1303 0xFFFF, / record-type-code / 1304 { / record-content / 1305 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / 1306 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 1307 3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' 1308 / key auth. digest / 1309 } 1310 ]>> 1311 ] 1312 ] 1314 Figure 3: Example Response Bundle 1316 Author's Address 1318 Brian Sipos 1319 RKF Engineering Solutions, LLC 1320 7500 Old Georgetown Road 1321 Suite 1275 1322 Bethesda, MD 20814-6198 1323 United States of America 1325 Email: BSipos@rkf-eng.com