idnits 2.17.1 draft-ietf-acme-dtnnodeid-03.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 (3 May 2021) is 1089 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1000000' on line 1118 -- Looks like a reference, but probably isn't: '0' on line 1159 -- Looks like a reference, but probably isn't: '1' on line 1158 -- Looks like a reference, but probably isn't: '1030000' on line 1159 == 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-05 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 Intended status: Experimental 3 May 2021 5 Expires: 4 November 2021 7 Automated Certificate Management Environment (ACME) Delay-Tolerant 8 Networking (DTN) Node ID Validation Extension 9 draft-ietf-acme-dtnnodeid-03 11 Abstract 13 This document specifies an extension to the Automated Certificate 14 Management Environment (ACME) protocol which allows an ACME server to 15 validate the Delay-Tolerant Networking (DTN) Node ID for an ACME 16 client. The DTN Node ID is encoded as a certificate Subject 17 Alternative Name (SAN) of type Uniform Resource Identifier (URI) and 18 ACME Identifier type "uri". 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 4 November 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 4 56 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 7 59 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 7 60 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 10 61 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 11 62 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 12 63 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 13 64 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 13 65 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 15 66 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 15 67 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 16 68 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 16 69 5.2. Generating Encryption-only or Signing-only Bundle Security 70 Certificates . . . . . . . . . . . . . . . . . . . . . . 17 71 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 18 74 7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 18 75 7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 18 76 7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 19 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 8.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 20 79 8.2. ACME Validation Method . . . . . . . . . . . . . . . . . 20 80 8.3. BP Bundle Administrative Record Types . . . . . . . . . . 20 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 84 10.2. Informative References . . . . . . . . . . . . . . . . . 23 85 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 24 86 Appendix B. Example Authorization . . . . . . . . . . . . . . . 24 87 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 24 88 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 25 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 91 1. Introduction 93 Although the original purpose of the Automatic Certificate Management 94 Environment (ACME) [RFC8555] was to allow Public Key Infrastructure 95 Using X.509 (PKIX) certificate authorities to validate network domain 96 names of clients, the same mechanism can be used to validate any of 97 the subject claims supported by the PKIX profile [RFC5280]. 99 In the case of this specification, the claim being validated is a 100 Subject Alternative Name (SAN) of type Uniform Resource Identifier 101 (URI) used to represent the Node ID of a Delay-Tolerant Networking 102 (DTN) Node. A DTN Node ID is a URI with a specific set of allowed 103 schemes, and determines how bundles are routed within a DTN. 104 Currently the schemes "dtn" and "ipn" as defined in 105 [I-D.ietf-dtn-bpbis] are valid for a Node ID. 107 Once an ACME server validates a Node ID, either as a pre- 108 authorization of the "uri" or as one of the authorizations of an 109 order containing a "uri", the client can finalize the order using an 110 associated certificate signing request (CSR). Because a single order 111 can contain multiple identifiers of multiple types, there can be 112 operational issues for a client attempting to, and possibly failing 113 to, validate those multiple identifiers as described in Section 5.1. 114 Once a certificate is issued for a Node ID, how the ACME client 115 configures the Bundle Protocol (BP) agent with the new certificate is 116 an implementation matter. 118 The scope and behavior of this validation mechanism is similar to 119 that of secured email validation of [RFC8823]. 121 1.1. Scope 123 This document describes the ACME messages, BPv7 payloads, and BPSec 124 requirements needed to validate Node ID ownership. This document 125 does not address: 127 * Mechanisms for communication between ACME client or ACME server 128 and their associated BP agent(s). This document only describes 129 exchanges between ACME client--server pairs and between their BP 130 agents. 132 * Specific BP extension blocks or BPSec security contexts necessary 133 to fulfill the security requirements of this protocol. The exact 134 security context needed, and their parameters, are network- 135 specific. 137 * Policies or mechanisms for defining or configuring bundle 138 integrity gateways, or trusting integrity gateways on an 139 individual entity or across a network. 141 * Mechanisms for locating or identifying other bundle entities 142 (peers) within a network or across an internet. The mapping of 143 Node ID to potential convergence layer (CL) protocol and network 144 address is left to implementation and configuration of the BP 145 Agent and its various potential routing strategies. 147 * Logic for routing bundles along a path toward a bundle's endpoint. 148 This protocol is involved only in creating bundles at a source and 149 handling them at a destination. 151 * Logic for performing rate control and congestion control of bundle 152 transfers. The ACME server is responsible for rate control of 153 validation requests. 155 * Policies or mechanisms for provisioning, deploying, or accessing 156 certificates and private keys; deploying or accessing certificate 157 revocation lists (CRLs); or configuring security parameters on an 158 individual entity or across a network. 160 * Policies or mechanisms for an ACME server to handle mixed-use 161 certificate requests. This specification is focused only on 162 single-use DTN-specific PKIX profiles. 164 1.2. Authorization Strategy 166 The basic unit of data exchange in a DTN is a Bundle 167 [I-D.ietf-dtn-bpbis], which consists of a data payload with 168 accompanying metadata. An Endpoint ID is used as the destination of 169 a Bundle and can indicate both a unicast or a multicast destination. 170 A Node ID is used to identify the source of a Bundle and is used for 171 routing through intermediate nodes, including the final node(s) used 172 to deliver a Bundle to its destination endpoint. A Node ID can also 173 be used as an endpoint for administrative bundles. More detailed 174 descriptions of the rationale and capabilities of these networks can 175 be found in "Delay-Tolerant Network Architecture" [RFC4838]. 177 When a ACME client requests a pre-authorization or an order with a 178 "uri" having one of the DTN Node ID schemes, the ACME server offers a 179 challenge type to validate that Node ID. If the ACME client attempts 180 the authorization challenge to validate a Node ID, the ACME server 181 sends an ACME Node ID Validation Challenge Bundle with a destination 182 of the Node ID being validated. The BP agent on that node receives 183 the Challenge Bundle, generates an ACME key authorization digest, and 184 sends an ACME Node ID Validation Response Bundle in reply. An 185 Integrity Gateway on the client side of the DTN can be used to attest 186 to the source of the Response Bundle. Finally, the ACME server 187 receives the Response Bundle and checks that the digest was generated 188 for the associated ACME challenge and from the client account key 189 associated with the original request. This workflow is shown in the 190 diagram of Figure 1 and defined in Section 3. 192 +------------+ +------------+ 193 | ACME |<===== HTTPS exchanges =====>| ACME | 194 | Client | | Server | 195 +------------+ +------------+ 196 | | ^ 197 Enable or disable Send | | 198 challenge from server Challenge | | Indicate 199 | Non-DTN | | Response 200 -------------------------------------------------------------------- 201 V DTN V | 202 ++------------++ ++------------++ 203 || Admin Elem.|| || Admin Elem.|| 204 |+------------+| |+------------+| 205 | Client's |<----- Challenge Bundle ---| Server's | 206 | BP Agent | | BP Agent | 207 +--------------+ +--------------+ 208 | ^ 209 | +-------------+ | 210 | | Integrity | | 211 +---->| Gateway |---Response Bundle----+ 212 +-------------+ 214 Figure 1: The relationships between Node ID Validation entities 216 Because the DTN Node ID is used both for routing bundles between BP 217 agents and for multiplexing administrative services within a BP 218 agent, there is no possibility to separate the ACME validation of a 219 Node ID from normal bundle handling for that same Node ID. This 220 leaves administrative record types as a way to leave the Node ID 221 unchanged while disambiguating from other service data bundles. 223 There is nothing in this protocol which requires network-topological 224 co-location of either the ACME client or ACME server with their 225 associated BP agent. While ACME requires a low-enough latency 226 network to perform HTTPS exchanges between ACME client and server, 227 the client's BP agent (the one being validated) could be on the far 228 side of a long-delay or multi-hop DTN network. The means by which 229 the ACME client or server communicates with its associated BP agent 230 is an implementation matter. 232 1.3. Use of CDDL 234 This document defines CBOR structure using the Concise Data 235 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure 236 can be extracted from the XML version of this document using the 237 XPath expression: 239 '//sourcecode[@type="cddl"]' 241 The following initial fragment defines the top-level symbols of this 242 document's CDDL, which includes the example CBOR content. 244 start = acme-record / bundle / tstr 246 1.4. Terminology 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 250 "OPTIONAL" in this document are to be interpreted as described in BCP 251 14 [RFC2119] [RFC8174] when, and only when, they appear in all 252 capitals, as shown here. 254 In this document, several terms are shortened for the sake of 255 terseness. These terms are: 257 Challenge Request: This is a shortened form of the full "DTN Node ID 258 Challenge Request Object". It is a JSON object created by the 259 ACME server for challenge type "dtn-nodeid-01". 261 Challenge Response: This is a shortened form of the full "DTN Node 262 ID Challenge Response Object". It is a JSON object created by the 263 ACME client to authorize a challenge type "dtn-nodeid-01". 265 Challenge Bundle: This is a shortened form of the full "ACME Node ID 266 Validation Challenge Bundle". It is a Bundle created by the ACME 267 server to challenge a Node ID claim. 269 Response Bundle: This is a shortened form of the full "ACME Node ID 270 Validation Response Bundle". It is a Bundle created by the BP 271 agent managed by the ACME client to validate a Node ID claim. 273 2. URI ACME Identifier 275 This specification is the first to make use of a URI to identify a 276 service for a certificate request in ACME. The URI-type identifier 277 is general purpose, and validating ownership of a URI requires a 278 specific purpose related to its "scheme" component. In this 279 document, the only purpose for which a URI ACME identifier is 280 validated is as a DTN Node ID (see Section 3), but other 281 specifications can define challenge types for other URI uses. 283 Identifiers of type "uri" in certificate requests MUST appear in an 284 extensionRequest attribute [RFC2985] containing a subjectAltName 285 extension of type uniformResourceIdentifier having a value consistent 286 with the requirements of [RFC3986]. Because the 287 uniformResourceIdentifier is encoded as an IA5String it SHALL be 288 treated as being in the percent-encoded form of Section 2.1 of 289 [RFC3986]. Any "uri" identifier which fails to properly percent- 290 decode SHALL be rejected with an ACME error type of "malformed". 292 Identifiers of type "uri" present in ACME messages are unicode text 293 strings and SHALL NOT be percent encoded. 295 The ACME server SHALL decode and normalize (based on scheme-specific 296 syntax) all received identifiers of type "uri". Any "uri" identifier 297 request which uses a scheme not handled by the ACME server or for 298 which the URI does not match the scheme-specific syntax SHALL be 299 rejected with an ACME error type of "rejectedIdentifier". 301 When an ACME server needs to request proof that a client controls a 302 URI, it SHALL create an authorization with the identifier type "uri". 303 The ACME server SHALL NOT attempt to dereference the URI value on its 304 own. It is the responsibility of a validation method to ensure the 305 URI ownership via scheme-specific means authorized by the ACME 306 client. 308 An identifier for the Node ID of "dtn://example/" would be formatted 309 as: 311 {"type": "uri", "value": "dtn://example/"} 313 3. DTN Node ID Validation 315 The DTN Node ID validation method proves control over a Node ID by 316 requiring the ACME client to configure a BP agent to respond to 317 specific Challenge Bundles sent from the ACME server. The ACME 318 server validates control of the Node ID URI by verifying that 319 received Response Bundles correspond with the BP Node and client 320 account key being validated. 322 Similar to the ACME use case for validating email address ownership 323 [RFC8823], this challenge splits the token into several parts, each 324 being transported by a different channel, and the Key Authorization 325 result requires combining all parts of the token. The token parts 326 are: 328 "token-chal" This token is unique to, and constant for, each ACME 329 authorization. It is contained in the Challenge Object of 330 Section 3.1 as well as the Challenge Bundle of Section 3.3. It 331 ensures that the Key Authorization is bound to the specific ACME 332 challenge (and parent ACME authorization) and also allows the ACME 333 client's BP agent to filter-in only valid Challenge Bundles. This 334 token is also accessible to DTN on-path eavesdroppers. 336 "token-bundle" This token is unique to each Challenge Bundle sent by 337 the ACME server. It is contained in the Challenge Bundle of 338 Section 3.3 and ensures that the Key Authorization is bound to the 339 ability to receive the Challenge Bundle. This token is also 340 accessible to DTN on-path eavesdroppers. 342 The DTN Node ID Challenge SHALL only be allowed for URIs usable as a 343 DTN Node ID, which are currently the schemes "dtn" and "ipn" as 344 defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node 345 ID validation, the ACME server SHALL define a challenge object in 346 accordance with Section 3.1. Once this challenge object is defined, 347 the ACME client may begin the validation. 349 To initiate a Node ID validation, the ACME client performs the 350 following steps: 352 1. The ACME client POSTs a newOrder or newAuthz request including 353 the identifier of type "uri" for the desired Node ID. From 354 either of these entry points an authorization for the "uri" type 355 is indicated by the ACME server. See Section 7.4 of [RFC8555] 356 for more details. 358 2. The ACME client obtains the challenge source Node ID and "token- 359 chal" from the challenge object in accordance with Section 3.1. 361 3. The ACME client indicates to the administrative element of its BP 362 agent the source Node ID and challenge "token-chal" which is 363 authorized for use and the associated client account key 364 thumbprint. The ACME client SHALL wait, if necessary, until the 365 agent is configured before proceeding to the next step. 367 4. The ACME client POSTs a challenge response to the challenge URL 368 on the ACME server accordance with Section 7.5.1 of [RFC8555]. 369 The payload object is constructed in accordance with Section 3.2. 371 5. The administrative element waits for a Challenge Bundle to be 372 received with the authorized ACME parameters, including its 373 "token-bundle" payload, in accordance with Section 3.3. 375 6. The administrative element concatenates "token-bundle" with 376 "token-chal" (each as base64url-encoded text strings) and 377 computes the Key Authorization in accordance with Section 8.1 of 378 [RFC8555] using the full token and client account key thumbprint. 380 7. The administrative element computes the SHA-256 digest of the Key 381 Authorization result and generates a Response Bundle to send back 382 to the ACME server in accordance with Section 3.4. 384 8. The ACME client waits for the authorization to be finalized on 385 the ACME server in accordance with Section 7.5.1 of [RFC8555]. 387 9. Once the challenge is completed (successfully or not), the ACME 388 client indicates to the BP agent that the validation source and 389 "token-chal" is no longer usable. If the authorization fails, 390 the ACME client MAY retry the challenge from Step 3. 392 The ACME server verifies the client's control over a Node ID by 393 performing the following steps: 395 1. The ACME server receives a newOrder or newAuthz request including 396 the identifier of type "uri", where the URI value is a Node ID. 398 2. The ACME server generates an authorization for the Node ID with 399 challenge type "dtn-nodeid-01" in accordance with Section 3.1. 401 3. The ACME server receives a POST to the challenge URL indicated 402 from the authorization object. The payload is handled in 403 accordance with Section 3.2. 405 4. The ACME server sends, via the administrative element of its BP 406 agent, one or more Challenge Bundles in accordance with 407 Section 3.3. Each challenge bundle SHALL contain a distinct 408 "token-bundle" to be able to correlate with a response bundle. 409 Computing an expected Key Authorization digest is not necessary 410 until a response is received. 412 5. The ACME server waits for Response Bundle(s) for a limited 413 interval of time (based on the challenge response object). 414 Responses are encoded in accordance with Section 3.4. 416 6. Once received and decoded, the ACME server checks the contents of 417 each Response Bundle in accordance with Section 3.4.1. After all 418 Challenge Bundles have either been responded to or timed-out, the 419 validation procedure is successful only if all responses are 420 successful. If validation is not successful, a client may retry 421 the challenge which starts in Step 3. 423 An ACME server MAY send multiple challenges from different origins in 424 the DTN network to avoid possible on-path attacks, as recommended in 425 Section 10.2 of [RFC8555]. If responses are received from multiple 426 challenges, any response failure SHALL cause a failure of the overall 427 validation. Each response failure MAY be indicated to the ACME 428 client as a validation subproblem. 430 When responding to a Challenge Bundle, a BP agent SHALL send a single 431 Response Bundle in accordance with Section 3.4. A BP agent SHALL 432 respond to ACME challenges only within the interval of time, only for 433 the Node ID, and only for the "token-chal" indicated by the ACME 434 client. A BP agent SHALL respond to multiple challenges with the 435 same parameters. These correspond with the ACME server validating 436 via multiple routing paths. 438 3.1. DTN Node ID Challenge Request Object 440 The DTN Node ID Challenge request object is defined by the ACME 441 server when it supports validating Node IDs. 443 The DTN Node ID Challenge request object has the following content: 445 type (required, string): The string "dtn-nodeid-01". 447 source (required, string): The source Node ID of bundles originating 448 at the ACME server as a text URI. 450 token-chal (required, string): A random value that uniquely 451 identifies the challenge. This value MUST have at least 128 bits 452 of entropy. It MUST NOT contain any characters outside the 453 base64url alphabet as described in Section 5 of [RFC4648]. 454 Trailing '=' padding characters MUST be stripped. See [RFC4086] 455 for additional information on randomness requirements. 457 { 458 "type": "dtn-nodeid-01", 459 "url": "https://example.com/acme/chall/prV_B7yEyA4", 460 "source": "dtn://acme-server/", 461 "token-chal": "tPUZNY4ONIk6LxErRFEjVw" 462 } 463 The "token-chal" value included in this object is fixed for the 464 entire challenge, and may correspond with multiple separate "token- 465 bundle" values when multiple Challenge Bundles are sent for a single 466 validation. 468 3.2. DTN Node ID Challenge Response Object 470 The DTN Node ID Challenge response object is defined by the ACME 471 client when it authorizes validation of a Node ID. Because a DTN has 472 the potential for significantly longer delays than a non-DTN network, 473 the ACME client is able to inform the ACME server if a particular 474 validation round-trip is expected to take longer than normal network 475 delays (on the order of seconds). 477 The DTN Node ID Challenge response object has the following content: 479 rtt (optional, number): An expected round-trip time (RTT), in 480 seconds, between sending a Challenge Bundle and receiving a 481 Response Bundle. This value is a hint to the ACME server for how 482 long to wait for responses but is not authoritative. The minimum 483 RTT value SHALL be zero. There is no special significance to 484 zero-value RTT, it simply indicates the response is expected in 485 less than the least significant unit used by the ACME client. 487 { 488 "rtt": 300.0 489 } 491 A challenge response is not sent until the BP agent has been 492 configured to properly respond to the challenge, so the RTT value is 493 meant to indicate any node-specific path delays expected to 494 encountered from the ACME server. Because there is no requirement on 495 the path (or paths) which bundles may traverse between the ACME 496 server and the BP agent, and the ACME server can attempt some path 497 diversity, the RTT value SHOULD be pessimistic. 499 A default bundle response interval, used when the object does not 500 contain an RTT, SHOULD be a configurable parameter of the ACME 501 server. If the ACME client indicated an RTT value in the object, the 502 response interval SHOULD be twice the RTT (with limiting logic 503 applied as described below). The lower limit on response waiting 504 time is network-specific, but SHOULD NOT be shorter than one second. 505 The upper limit on response waiting time is network-specific, but 506 SHOULD NOT be longer than one minute (60 seconds) for a terrestrial- 507 only DTN. 509 3.3. ACME Node ID Validation Challenge Bundles 511 Each Each ACME Node ID Validation Challenge Bundle SHALL be 512 structured and encoded in accordance with [I-D.ietf-dtn-bpbis]. 514 Each Challenge Bundle has parameters as listed here: 516 Bundle Processing Control Flags: The primary block flags SHALL 517 indicate that the payload is an administrative record. The 518 primary block flags SHALL indicate that user application 519 acknowledgement is requested; this flag distinguishes the 520 Challenge Bundle from the Response Bundle. The primary block 521 flags MAY indicate that status reports are requested; such status 522 can be helpful to troubleshoot routing issues. 524 Destination EID: The Destination EID SHALL be identical to the Node 525 ID being validated. The ACME server SHOULD NOT perform URI 526 normalization on the Node ID given by the ACME client. 528 Source Node ID: The Source Node ID SHALL indicate the Node ID of the 529 ACME server performing the challenge. 531 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 532 to the time at which the challenge was generated. The Lifetime 533 SHALL indicate the response interval for which ACME server will 534 accept responses to this challenge. 536 Administrative Record Type Code: Set to the ACME Node ID Validation 537 type code defined in Section 8.3. 539 Administrative Record Content: The Challenge Bundle administrative 540 record content SHALL consist of a CBOR map containing two pairs: 542 * One pair SHALL consist of key 1 with value of ACME challenge 543 "token-chal", copied from the challenge object, represented as 544 a CBOR byte string. 546 * One pair SHALL consist of key 2 with value of ACME challenge 547 "token-bundle", represented as a CBOR byte string. The "token- 548 bundle" is a random value that uniquely identifies the 549 challenge bundle. This value MUST have at least 128 bits of 550 entropy. See [RFC4086] for additional information on 551 randomness requirements. 553 This structure is part of the extension CDDL in Appendix A. An 554 example full Challenge Bundle is included in Appendix B.1 555 If the BP agent generating a Challenge Bundle does not have a well- 556 synchronized clock or the agent responding to the challenge is 557 expected to not have a well-synchronized clock, the bundle SHALL 558 include a Bundle Age extension block. 560 Challenge Bundles SHALL include a Block Integrity Block (BIB) in 561 accordance with Section 4 or with a Security Source identical to the 562 bundle Source Node. Challenge Bundles SHALL NOT be directly 563 encrypted by Block Confidentiality Block (BCB) or any other method 564 (see Section 7.1). 566 3.3.1. Challenge Bundle Checks 568 A proper Challenge Bundle meets all of the following criteria: 570 * The Challenge Bundle was received within the time interval allowed 571 for the challenge. 573 * The Challenge Bundle Source Node ID is identical to the Node ID 574 indicated in the ACME challenge object. The comparison of Node 575 IDs SHALL use the comparison logic of [RFC3986] and scheme-based 576 normalization of those schemes specified in [I-D.ietf-dtn-bpbis]. 578 * The Challenge Bundle contains a BIB which covers at least the 579 primary block and payload. That BIB has a security source which 580 is trusted and passes security-context-specific validation (i.e. 581 MAC or signature verification). 583 * The challenge payload contains the "token-chal" as indicated in 584 the ACME challenge object. The challenge payload contains a 585 "token-bundle" meeting the definition in Section 3.3. 587 Any of the failures above SHALL cause the challenge bundle to be 588 deleted and otherwise ignored by the BP agent. The BP agent MAY send 589 status reports about the deletion if allowed by security policy. 591 3.4. ACME Node ID Validation Response Bundles 593 Each Each ACME Node ID Validation Response Bundle SHALL be structured 594 and encoded in accordance with [I-D.ietf-dtn-bpbis]. 596 Each Response Bundle has parameters as listed here: 598 Bundle Processing Control Flags: The primary block flags SHALL 599 indicate that the payload is an administrative record. The 600 primary block flags SHALL NOT indicate that user application 601 acknowledgement is requested; this flag distinguishes the Response 602 Bundle from the Challenge Bundle. The primary block flags MAY 603 indicate that status reports are requested; such status can be 604 helpful to troubleshoot routing issues. 606 Destination EID: The Destination EID SHALL be identical to the 607 Source Node ID of the Challenge Bundle to which this response 608 corresponds. 610 Source Node ID: The Source Node ID SHALL be identical to the the 611 Destination EID of the Challenge Bundle to which this response 612 corresponds. 614 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 615 to the time at which the response was generated. The response 616 Lifetime SHALL indicate the response interval remaining if the 617 Challenge Bundle indicated a limited Lifetime. 619 Administrative Record Type Code: Set to the ACME Node ID Validation 620 type code defined in Section 8.3. 622 Administrative Record Content: The Response Bundle administrative 623 record content SHALL consist of a CBOR map containing three pairs: 625 * One pair SHALL consist of key 1 with value of ACME challenge 626 "token-chal", copied from the Request Bundle, represented as a 627 CBOR byte string. 629 * One pair SHALL consist of key 2 with value of ACME challenge 630 "token-bundle", copied from the Request Bundle, represented as 631 a CBOR byte string. 633 * One pair SHALL consist of key 3 with value of the SHA-256 634 digest [FIPS180-4] of the ACME Key Authorization in accordance 635 with Section 8.1 of [RFC8555], represented as a CBOR byte 636 string. 638 This structure is part of the extension CDDL in Appendix A. An 639 example full Response Bundle is included in Appendix B.2 641 If the BP agent responding to a Challenge Bundle does not have a 642 well-synchronized clock, it SHALL use any information about last-hop 643 delays and (if present) Bundle Age extension data to infer the age of 644 the Challenge Bundle and lifetime of the Response Bundle. 646 Response Bundles SHALL include a BIB in accordance with Section 4. 647 Response Bundles SHALL NOT be directly encrypted by BCB or any other 648 method (see Section 7.1 for explanation). 650 3.4.1. Response Bundle Checks 652 A proper Response Bundle meets all of the following criteria: 654 * The Response Bundle was received within the time interval allowed 655 for the challenge. 657 * The Response Bundle Source Node ID is identical to the Node ID 658 being validated. The comparison of Node IDs SHALL use the 659 comparison logic of [RFC3986] and scheme-based normalization of 660 those schemes specified in [I-D.ietf-dtn-bpbis]. 662 * The Response Bundle contains a BIB which covers at least the 663 primary block and payload. That BIB has a security source which 664 is trusted and passes security-context-specific validation. 666 * The response payload contains the "token-chal" and "token-bundle" 667 as sent in the Challenge Bundle. The response payload contains 668 the expected Key Authorization digest computed by the ACME server. 669 Because multiple Challenge Bundles can be sent to validate the 670 same Node ID, the "token-bundle" in the response is needed to 671 correlate with the expected Key Authorization digest. 673 Any of the failures above SHALL cause the validation to fail. Any of 674 the failures above SHOULD be indicated as subproblems to the ACME 675 client. 677 4. Bundle Integrity Gateway 679 This section defines a BIB use which closely resembles the function 680 of DKIM email signing [RFC6376]. In this mechanism a routing node in 681 a DTN sub-network vouches for the origination of a bundle by adding a 682 BIB before forwarding it. The bundle receiver then need not trust 683 the source of the bundle, but only trust this security source node. 684 The receiver needs policy configuration to know which security source 685 is permitted to vouch for which bundle sources. 687 An integrity gateway SHALL validate the Source Node ID of a bundle, 688 using local-network-specific means, before adding a BIB to the 689 bundle. The exact means by which an integrity gateway validates a 690 bundle's source is network-specific, but could use physical-layer, 691 network-layer or BP-convergence-layer authentication. The bundle 692 source could also add its own BIB with a local-network-specific 693 security context or local-network-specific key material (i.e. a group 694 key shared within the local network). 696 When an integrity gateway adds a BIB it SHALL be in accordance with 697 [I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload 698 block and the primary block (either directly as a target or as 699 additional authenticated data for the payload block signature). The 700 Security Source of this BIB SHALL be either the bundle source Node ID 701 itself or a routing node trusted by the destination node (see 702 Section 7.2). 704 5. Certificate Request Profile 706 The ultimate purpose of this ACME validation is to allow a CA to 707 issue certificates following the profiles of Section 4.4.2 of 708 [I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and 709 [I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as 710 bundle security certificates. 712 One defining aspect of bundle security certificates is the Extended 713 Key Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When 714 requesting a certificate which includes a Node ID SAN, the CSR SHOULD 715 include an Extended Key Usage of id-kp-bundleSecurity. When a bundle 716 security certificate is issued based on a validated Node ID SAN, the 717 certificate SHALL include an Extended Key Usage of id-kp- 718 bundleSecurity. 720 5.1. Multiple Identity Claims 722 A single bundle security CSR MAY contain a mixed set of SAN claims, 723 including combinations of "ip", "dns", and "uri" claims. There is no 724 restriction on how a certificate combines these claims, but each 725 claim MUST be validated by an ACME server to issue such a certificate 726 as part of an associated ACME order. This is no different than the 727 existing behavior of [RFC8555] but is mentioned here to make sure 728 that CA policy handles such situations; especially related to 729 validation failure of an identifier in the presence of multiple 730 identifiers. The specific use case of [I-D.ietf-dtn-tcpclv4] allows, 731 and for some network policies requires, that a certificate 732 authenticate both the DNS name of an entity as well as the Node ID of 733 the entity. 735 5.2. Generating Encryption-only or Signing-only Bundle Security 736 Certificates 738 ACME extensions specified in this document can be used to request 739 encryption-only or signing-only bundle security certificates. 741 In order to request signing only bundle security certificate, the CSR 742 MUST include the key usage extension with digitalSignature and/or 743 nonRepudiation bits set and no other bits set. 745 In order to request encryption only bundle security certificate, the 746 CSR MUST include the key usage extension with keyEncipherment or 747 keyAgreement bits set and no other bits set. 749 Presence of both of the above sets of key usage bits in the CSR, as 750 well as absence of key usage extension in the CSR, signals to ACME 751 server to issue a bundle security certificate suitable for both 752 signing and encryption. 754 6. Implementation Status 756 [NOTE to the RFC Editor: please remove this section before 757 publication, as well as the reference to [RFC7942] and 758 [github-acme-dtnnodeid].] 760 This section records the status of known implementations of the 761 protocol defined by this specification at the time of posting of this 762 Internet-Draft, and is based on a proposal described in [RFC7942]. 763 The description of implementations in this section is intended to 764 assist the IETF in its decision processes in progressing drafts to 765 RFCs. Please note that the listing of any individual implementation 766 here does not imply endorsement by the IETF. Furthermore, no effort 767 has been spent to verify the information presented here that was 768 supplied by IETF contributors. This is not intended as, and must not 769 be construed to be, a catalog of available implementations or their 770 features. Readers are advised to note that other implementations can 771 exist. 773 An example implementation of the this draft of ACME has been created 774 as a GitHub project [github-acme-dtnnodeid] and is intended to use as 775 a proof-of-concept and as a possible source of interoperability 776 testing. This example implementation only constructs encoded bundles 777 and does not attempt to provide a full BP Agent interface. 779 7. Security Considerations 781 This section separates security considerations into threat categories 782 based on guidance of BCP 72 [RFC3552]. 784 7.1. Threat: Passive Leak of Validation Data 786 Because this challenge mechanism is used to bootstrap security 787 between DTN Nodes, the challenge and its response are likely to be 788 transferred in plaintext. The only ACME data present on-the-wire is 789 a random token and a cryptographic digest, so there is no sensitive 790 data to be leaked within the Node ID Validation bundle exchange. 791 Because each challenge uses a separate token, there is no value in an 792 on-path attacker seeing the tokens from past challenges and/or 793 responses. 795 It is possible for intermediate BP nodes to encapsulate-and-encrypt 796 Challenge and/or Response Bundles while they traverse untrusted 797 networks, but that is a DTN configuration matter outside of the scope 798 of this document. 800 7.2. Threat: BP Node Impersonation 802 As described in Section 8.1 of [RFC8555], it is possible for an 803 active attacker to alter data on both ACME client channel and the DTN 804 validation channel. 806 The primary mitigation is to delegate bundle integrity sourcing to a 807 trusted routing node near, in the sense of bundle routing topology, 808 to the bundle source node as defined in Section 4. This is 809 functionally similar to DKIM signing of [RFC6376] and provides some 810 level of bundle origination. 812 Another way to mitigate single-path on-path attacks is to attempt 813 validation of the same Node ID via multiple bundle routing paths, as 814 recommended in Section 3. It is not a trivial task to guarantee 815 bundle routing though, so more advanced techniques such as onion 816 routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) 817 could be employed. 819 7.3. Threat: Bundle Replay 821 It is possible for an on-path attacker to replay both Challenge 822 Bundles or Response Bundles. Even in a properly-configured DTN it is 823 possible that intermediate bundle routers to use multicast forwarding 824 of a unicast-destination bundle. 826 Ultimately, the point of the ACME bundle exchange is to derive a Key 827 Authorization and its cryptographic digest and communicate it back to 828 the ACME server for validation, so the uniqueness of the Key 829 Authorization directly determines the scope of replay validity. The 830 uniqueness of each "token-bundle" to each challenge bundle ensures 831 that the Key Authorization is unique to the challenge bundle. The 832 uniqueness of each "token-chal" to the ACME challenge ensures that 833 the Key Authorization is unique to that ACME challenge. 835 Having each bundle's primary block and payload block covered by a BIB 836 from a trusted security source (see Section 4) ensures that a 837 replayed bundle cannot be altered in the blocks used by ACME. All 838 together, these properties mean that there is no degraded security 839 caused by replay of either a Challenge Bundle or a Response Bundle 840 even in the case where the primary or payload block is not covered by 841 a BIB. The worst that can come of bundle replay is the waste of 842 network resources as described in Section 7.4. 844 7.4. Threat: Denial of Service 846 The behaviors described in this section all amount to a potential 847 denial-of-service to a BP agent. 849 A malicious entity can continually send Challenge Bundles to a BP 850 agent. The victim BP agent can ignore Challenge Bundles which do not 851 conform to the specific time interval and challenge token for which 852 the ACME client has informed the BP agent that challenges are 853 expected. The victim BP agent can require all Challenge Bundles to 854 be BIB-signed to ensure authenticity of the challenge. 856 A malicious entity can continually send Response Bundles to a BP 857 agent. The victim BP agent can ignore Response Bundles which do not 858 conform to the specific time interval or Source Node ID or challenge 859 token for an active Node ID validation. 861 Similar to other validation methods, an ACME server validating a DTN 862 Node ID could be used as a denial of service amplifier. For this 863 reason any ACME server can rate-limit validation activities for 864 individual clients and individual certificate requests. 866 8. IANA Considerations 868 This specification adds to the ACME registry and BP registry for this 869 behavior. 871 8.1. ACME Identifier Type 873 Within the "Automated Certificate Management Environment (ACME) 874 Protocol" registry [IANA-ACME], the following entry has been added to 875 the "ACME Identifier Types" sub-registry. 877 +=======+==================================+ 878 | Label | Reference | 879 +=======+==================================+ 880 | uri | This specification and [RFC3986] | 881 +-------+----------------------------------+ 883 Table 1 885 8.2. ACME Validation Method 887 Within the "Automated Certificate Management Environment (ACME) 888 Protocol" registry [IANA-ACME], the following entry has been added to 889 the "ACME Validation Methods" sub-registry. 891 +===============+=================+======+====================+ 892 | Label | Identifier Type | ACME | Reference | 893 +===============+=================+======+====================+ 894 | dtn-nodeid-01 | uri | Y | This specification | 895 +---------------+-----------------+------+--------------------+ 897 Table 2 899 8.3. BP Bundle Administrative Record Types 901 Within the "Bundle Protocol" registry [IANA-BP], the following entry 902 has been added to the "Bundle Administrative Record Types" sub- 903 registry. [NOTE to the RFC Editor: For RFC5050 compatibility this 904 value needs to be no larger than 15, but such compatibility is not 905 needed. BPbis has no upper limit on this code point value.] 907 +=========================+=======+==============+===============+ 908 | Bundle Protocol Version | Value | Description | Reference | 909 +=========================+=======+==============+===============+ 910 | 7 | TBD | ACME Node ID | This | 911 | | | Validation | specification | 912 +-------------------------+-------+--------------+---------------+ 914 Table 3 916 9. Acknowledgments 918 This specification is based on DTN use cases related to PKIX 919 certificate issuance. 921 The workflow and terminology of this validation method was originally 922 copied from the work of Alexey Melnikov in [RFC8823]. 924 10. References 926 10.1. Normative References 928 [FIPS180-4] 929 National Institute of Standards and Technology, "Secure 930 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 931 . 934 [IANA-ACME] 935 IANA, "Automated Certificate Management Environment (ACME) 936 Protocol", . 938 [IANA-BP] IANA, "Bundle Protocol", 939 . 941 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", 942 . 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, 946 DOI 10.17487/RFC2119, March 1997, 947 . 949 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 950 Classes and Attribute Types Version 2.0", RFC 2985, 951 DOI 10.17487/RFC2985, November 2000, 952 . 954 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 955 Text on Security Considerations", BCP 72, RFC 3552, 956 DOI 10.17487/RFC3552, July 2003, 957 . 959 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 960 Resource Identifier (URI): Generic Syntax", STD 66, 961 RFC 3986, DOI 10.17487/RFC3986, January 2005, 962 . 964 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 965 "Randomness Requirements for Security", BCP 106, RFC 4086, 966 DOI 10.17487/RFC4086, June 2005, 967 . 969 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 970 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 971 . 973 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 974 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 975 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 976 April 2007, . 978 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 979 Housley, R., and W. Polk, "Internet X.509 Public Key 980 Infrastructure Certificate and Certificate Revocation List 981 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 982 . 984 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 985 Code: The Implementation Status Section", BCP 205, 986 RFC 7942, DOI 10.17487/RFC7942, July 2016, 987 . 989 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 990 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 991 May 2017, . 993 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 994 Kasten, "Automatic Certificate Management Environment 995 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 996 . 998 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 999 Definition Language (CDDL): A Notational Convention to 1000 Express Concise Binary Object Representation (CBOR) and 1001 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1002 June 2019, . 1004 [I-D.ietf-dtn-bpbis] 1005 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle 1006 Protocol Version 7", Work in Progress, Internet-Draft, 1007 draft-ietf-dtn-bpbis-31, 25 January 2021, 1008 . 1010 [I-D.ietf-dtn-bpsec] 1011 III, E. J. B. and K. McKeever, "Bundle Protocol Security 1012 Specification", Work in Progress, Internet-Draft, draft- 1013 ietf-dtn-bpsec-27, 16 February 2021, 1014 . 1016 10.2. Informative References 1018 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1019 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1020 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1021 . 1023 [RFC8823] Melnikov, A., "Extensions to Automatic Certificate 1024 Management Environment for End-User S/MIME Certificates", 1025 RFC 8823, DOI 10.17487/RFC8823, April 2021, 1026 . 1028 [I-D.ietf-dtn-bibect] 1029 Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in 1030 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 1031 February 2020, 1032 . 1034 [I-D.ietf-dtn-tcpclv4] 1035 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 1036 Tolerant Networking TCP Convergence Layer Protocol Version 1037 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 1038 tcpclv4-26, 15 February 2021, 1039 . 1041 [I-D.sipos-dtn-udpcl] 1042 Sipos, B., "Delay-Tolerant Networking UDP Convergence 1043 Layer Protocol", Work in Progress, Internet-Draft, draft- 1044 sipos-dtn-udpcl-01, 26 March 2021, 1045 . 1047 [I-D.bsipos-dtn-bpsec-cose] 1048 Sipos, B., "DTN Bundle Protocol Security COSE Security 1049 Context", Work in Progress, Internet-Draft, draft-bsipos- 1050 dtn-bpsec-cose-05, 16 March 2021, 1051 . 1054 [github-acme-dtnnodeid] 1055 Sipos, B., "ACME Node ID Example Implementation", 1056 . 1058 Appendix A. Administrative Record Types CDDL 1060 [NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the 1061 "ACME Node ID Validation" administrative record type code.] 1063 The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles 1064 is: 1066 ; All ACME records have the same structure 1067 $admin-record /= [0xFFFF, acme-record] 1068 acme-record = { 1069 token-chal, 1070 token-bundle, 1071 ? key-auth-digest ; present for Response Bundles 1072 } 1073 token-chal = (1 => bstr) 1074 token-bundle = (2 => bstr) 1075 key-auth-digest = (3 => bstr) 1077 Appendix B. Example Authorization 1079 [NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced 1080 by the "ACME Node ID Validation" administrative record type code.] 1082 This example is a bundle exchange for the ACME server with Node ID 1083 "dtn://acme-server/" performing a verification for ACME client Node 1084 ID "dtn://acme-client/". The example bundles use no block CRC or 1085 BPSec integrity, which is for simplicity and is not recommended for 1086 normal use. The provided figures are extended diagnostic notation 1087 [RFC8610]. 1089 For this example the ACME client key thumbprint has the base64url 1090 encoded value of: 1092 "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 1094 And the ACME-server generated "token-chal" has the base64url-encoded 1095 value of: 1097 "tPUZNY4ONIk6LxErRFEjVw" 1099 B.1. Challenge Bundle 1101 For the single challenge bundle in this example, the "token-bundle" 1102 (transported as byte string via BP) has the base64url-encoded value 1103 of: 1105 "p3yRYFU4KxwQaHQjJ2RdiQ" 1106 The minimal-but-valid Challenge Bundle is shown in Figure 2. This 1107 challenge requires that the ACME client respond within a 60 second 1108 time window. 1110 [ 1111 [ 1112 7, / BP version / 1113 0x22, / flags: user-app-ack, payload-is-an-admin-record / 1114 0, / CRC type: none / 1115 [1, "//acme-client/"], / destination / 1116 [1, "//acme-server/"], / source / 1117 [1, "//acme-server/"], / report-to / 1118 [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 / 1119 60000 / lifetime: 60s / 1120 ], 1121 [ 1122 1, / block type code / 1123 1, / block number / 1124 0, / flags / 1125 0, / CRC type: none / 1126 <<[ / type-specific data / 1127 0xFFFF, / record-type-code / 1128 { / record-content / 1129 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / 1130 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 1131 } 1132 ]>> 1133 ] 1134 ] 1136 Figure 2: Example Challenge Bundle 1138 B.2. Response Bundle 1140 When the tokens are combined with the key thumbprint, the full Key 1141 Authorization value (a single string split across lines for 1142 readability) is: 1144 "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw." 1145 "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" 1147 The minimal-but-valid Response Bundle is shown in Figure 3. This 1148 response indicates that there is 30 seconds remaining in the response 1149 time window. 1151 [ 1152 [ 1153 7, / BP version / 1154 0x02, / flags: payload-is-an-admin-record / 1155 0, / CRC type: none / 1156 [1, "//acme-server/"], / destination / 1157 [1, "//acme-client/"], / source / 1158 [1, 0], / report-to: none / 1159 [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 / 1160 30000 / lifetime: 30s / 1161 ], 1162 [ 1163 1, / block type code / 1164 1, / block number / 1165 0, / flags / 1166 0, / CRC type: none / 1167 <<[ / block-type-specific data / 1168 0xFFFF, / record-type-code / 1169 { / record-content / 1170 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / 1171 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 1172 3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' 1173 / key auth. digest / 1174 } 1175 ]>> 1176 ] 1177 ] 1179 Figure 3: Example Response Bundle 1181 Author's Address 1183 Brian Sipos 1184 RKF Engineering Solutions, LLC 1185 7500 Old Georgetown Road 1186 Suite 1275 1187 Bethesda, MD 20814-6198 1188 United States of America 1190 Email: BSipos@rkf-eng.com