idnits 2.17.1 draft-ietf-dtn-bpsec-default-sc-11.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 (25 July 2021) is 1005 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 2102 -- Looks like a reference, but probably isn't: '40' on line 1645 -- Looks like a reference, but probably isn't: '1' on line 2435 -- Looks like a reference, but probably isn't: '7' on line 1750 -- Looks like a reference, but probably isn't: '3' on line 2441 == Missing Reference: '0x00' is mentioned on line 2188, but not defined -- Looks like a reference, but probably isn't: '2' on line 2441 -- Looks like a reference, but probably isn't: '4' on line 2442 -- Looks like a reference, but probably isn't: '5' on line 2107 -- Looks like a reference, but probably isn't: '6' on line 2352 == Missing Reference: '0x07' is mentioned on line 2442, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-GCM' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking E.J. Birrane 3 Internet-Draft A. White 4 Intended status: Standards Track S. Heiner 5 Expires: 26 January 2022 JHU/APL 6 25 July 2021 8 BPSec Default Security Contexts 9 draft-ietf-dtn-bpsec-default-sc-11 11 Abstract 13 This document defines default integrity and confidentiality security 14 contexts that can be used with the Bundle Protocol Security Protocol 15 (BPSec) implementations. These security contexts are intended to be 16 used for both testing the interoperability of BPSec implementations 17 and for providing basic security operations when no other security 18 contexts are defined or otherwise required for a network. 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 26 January 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 4 56 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 7 60 3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 7 61 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 8 62 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 8 63 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 9 65 3.6. Security Processing Considerations . . . . . . . . . . . 10 66 3.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 10 67 3.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.8.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 11 69 3.8.2. Keyed Hash Verification . . . . . . . . . . . . . . . 12 70 4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 13 71 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 16 75 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 16 76 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 17 77 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 17 78 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 18 79 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 19 81 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 20 82 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 20 83 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 21 84 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 22 85 4.7.1. Cipher text related calculations . . . . . . . . . . 22 86 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 23 87 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 24 88 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 24 89 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 26 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 92 5.1. Security Context Identifiers . . . . . . . . . . . . . . 27 93 5.2. Integrity Scope Flags . . . . . . . . . . . . . . . . . . 27 94 5.3. AAD Scope Flags . . . . . . . . . . . . . . . . . . . . . 28 95 5.4. Guidance for Designated Experts . . . . . . . . . . . . . 29 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 97 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 30 98 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 31 99 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 32 101 6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 32 102 7. Normative References . . . . . . . . . . . . . . . . . . . . 33 103 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 34 104 A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 35 105 A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 35 106 A.1.2. Security Operation Overview . . . . . . . . . . . . . 37 107 A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 38 108 A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 39 109 A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 39 110 A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 39 111 A.2.2. Security Operation Overview . . . . . . . . . . . . . 40 112 A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 41 113 A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 43 114 A.3. Example 3: Security Blocks from Multiple Sources . . . . 43 115 A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 43 116 A.3.2. Security Operation Overview . . . . . . . . . . . . . 45 117 A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 45 118 A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 47 119 A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 49 120 A.4. Example 4: Security Blocks with Full Scope . . . . . . . 49 121 A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 49 122 A.4.2. Security Operation Overview . . . . . . . . . . . . . 50 123 A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 51 124 A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 52 125 A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 55 126 Appendix B. CDDL Expression . . . . . . . . . . . . . . . . . . 55 127 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 56 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 130 1. Introduction 132 The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] 133 specification provides inter-bundle integrity and confidentiality 134 operations for networks deploying the Bundle Protocol (BP) 135 [I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry 136 security information produced under the auspices of some security 137 context. 139 This document defines two security contexts (one for an integrity 140 service and one for a confidentiality service) for populating BPSec 141 Block Integrity Blocks (BIBs) and Block Confidentiality Blocks 142 (BCBs). This document assumes familiarity with the concepts and 143 terminology associated with BP and BPSec, as these security contexts 144 are used with BPSec security blocks and other BP blocks carried 145 within BP bundles. 147 These contexts generate information that MUST be encoded using the 148 CBOR specification documented in [RFC8949]. 150 2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 3. Integrity Security Context BIB-HMAC-SHA2 160 3.1. Overview 162 The BIB-HMAC-SHA2 security context provides a keyed-hash Message 163 Authentication Code (MAC) over a set of plain text information. This 164 context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS] 165 combined with the HMAC keyed hash discussed in [RFC2104]. The 166 combination of HMAC and SHA-2 as the integrity mechanism for this 167 security context was selected for two reasons: 169 1. The use of symmetric keys allows this security context to be used 170 in places where an asymmetric-key infrastructure (such as a 171 public key infrastructure) might be impractical. 173 2. The combination HMAC-SHA2 represents a well-supported and well- 174 understood integrity mechanism with multiple implementations 175 available. 177 BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the 178 supported length of the SHA-2 hash value. These variants correspond 179 to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in 180 [RFC8152] Table 7: HMAC Algorithm Values. The selection of which 181 variant is used by this context is provided as a security context 182 parameter. 184 The output of the HMAC MUST be equal to the size of the SHA2 hashing 185 function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits 186 for SHA-512. 188 The BIB-HMAC-SHA2 security context MUST have the security context 189 identifier specified in Section 5.1. 191 3.2. Scope 193 The scope of BIB-HMAC-SHA2 is the set of information used to produce 194 the plain text over which a keyed hash is calculated. This plain 195 text is termed the "Integrity Protected Plain Text" (IPPT). The 196 content of the IPPT is constructed as the concatenation of 197 information whose integrity is being preserved from the BIB-HMAC-SHA2 198 security source to its security acceptor. There are five types of 199 information that can be used in the generation of the IPPT, based on 200 how broadly the concept of integrity is being applied. These five 201 types of information, whether they are required, and why they are 202 important for integrity, are discussed as follows. 204 Security target contents 205 The contents of the block-type-specific data field of the 206 security target MUST be included in the IPPT. Including this 207 information protects the security target data and is considered 208 the minimal, required set of information for an integrity service 209 on the security target. 211 IPPT Scope 212 The determination of which optional types of information were 213 used when constructing the IPPT MUST, itself, always be included 214 in the IPPT. Including this information ensures that the scope 215 of the IPPT construction at a security source matches the scope 216 of the IPPT construction at security verifiers and security 217 acceptors. 219 Primary block 220 The primary block identifies a bundle and, once created, the 221 contents of this block are immutable. Changes to the primary 222 block associated with the security target indicate that the 223 security target (and BIB) might no longer be in the correct 224 bundle. 226 For example, if a security target and associated BIB are copied 227 from one bundle to another bundle, the BIB might still contain a 228 verifiable signature for the security target unless information 229 associated with the bundle primary block is included in the keyed 230 hash carried by the BIB. 232 Including this information in the IPPT protects the integrity of 233 the association of the security target with a specific bundle. 235 Security target other fields 236 The other fields of the security target include block 237 identification and processing information. Changing this 238 information changes how the security target is treated by nodes 239 in the network even when the "user data" of the security target 240 are otherwise unchanged. 242 For example, if the block processing control flags of a security 243 target are different at a security verifier than they were 244 originally set at the security source then the policy for 245 handling the security target has been modified. 247 Including this information in the IPPT protects the integrity of 248 the policy and identification of the security target data. 250 BIB other fields 251 The other fields of the BIB include block identification and 252 processing information. Changing this information changes how 253 the BIB is treated by nodes in the network, even when other 254 aspects of the BIB are unchanged. 256 For example, if the block processing control flags of the BIB are 257 different at a security verifier than they were originally set at 258 the security source, then the policy for handling the BIB has 259 been modified. 261 Including this information in the IPPT protects the integrity of 262 the policy and identification of the security service in the 263 bundle. 265 NOTE: The security context identifier and security context 266 parameters of the security block are not included in the IPPT 267 because these parameters, by definition, are required to verify 268 or accept the security service. Successful verification at 269 security verifiers and security acceptors implies that these 270 parameters were unchanged since being specified at the security 271 source. This is the case because keys cannot be re-used across 272 security contexts, and because the integrity scope flags used to 273 define the IPPT are included in the IPPT itself. 275 The scope of the BIB-HMAC-SHA2 security context is configured using 276 an optional security context parameter. 278 3.3. Parameters 280 BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, 281 communicate key information, and define the scope of the IPPT. 283 3.3.1. SHA Variant 285 This optional parameter identifies which variant of the SHA-2 286 algorithm is to be used in the generation of the authentication code. 288 This value MUST be encoded as a CBOR unsigned integer. 290 Valid values for this parameter are as follows. 292 SHA Variant Parameter Values 294 +=======+======================================+ 295 | Value | Description | 296 +=======+======================================+ 297 | 5 | HMAC 256/256 as defined in [RFC8152] | 298 | | Table 7: HMAC Algorithm Values | 299 +-------+--------------------------------------+ 300 | 6 | HMAC 384/384 as defined in [RFC8152] | 301 | | Table 7: HMAC Algorithm Values | 302 +-------+--------------------------------------+ 303 | 7 | HMAC 512/512 as defined in [RFC8152] | 304 | | Table 7: HMAC Algorithm Values | 305 +-------+--------------------------------------+ 307 Table 1 309 When not provided, implementations SHOULD assume a value of 6 310 (indicating use of HMAC 384/384), unless an alternate default is 311 established by local security policy at the security source, 312 verifiers, or acceptor of this integrity service. 314 3.3.2. Wrapped Key 316 This optional parameter contains the output of the AES key wrap 317 authenticated encryption function (KW-AE) as defined in [RFC5649]. 318 Specifically, this parameter holds the cipher text produced when 319 running the KW-AE algorithm with the input string being the symmetric 320 HMAC key used to generate the security results present in the 321 security block. The value of this parameter is used as input to the 322 AES key wrap authenticated decryption function (KW-AD) at security 323 verifiers and security acceptors to determine the symmetric HMAC key 324 needed for the proper validation of the security results in the 325 security block. 327 This value MUST be encoded as a CBOR byte string. 329 If this parameter is not present then security verifiers and 330 acceptors MUST determine the proper key as a function of their local 331 BPSec policy and configuration. 333 3.3.3. Integrity Scope Flags 335 This optional parameter contains a series of flags that describe what 336 information is to be included with the block-type-specific data when 337 constructing the IPPT value. 339 This value MUST be represented as a CBOR unsigned integer, the value 340 of which MUST be processed as a 16-bit field. The maximum value of 341 this field, as a CBOR unsigned integer, MUST be 65535. 343 Implementations MUST set reserved and unassigned bits in this field 344 to 0 when constructing these flags at a security source. Once set, 345 the value of this field MUST NOT be altered until the security 346 service is completed at the security acceptor in the network and 347 removed from the bundle. 349 Bits in this field represent additional information to be included 350 when generating an integrity signature over the security target. 351 These bits are defined as follows. 353 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 355 - Bit 1 (0x0002): Target Header Flag. 357 - Bit 2 (0x0004): Security Header Flag. 359 - Bits 3-7 are reserved. 361 - Bits 8-15 are unassigned. 363 3.3.4. Enumerations 365 The BIB-HMAC-SHA2 security context parameters are listed in Table 2. 366 In this table, the "Parm Id" column refers to the expected Parameter 367 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 368 and Result Identification". 370 If the default value column is empty, this indicates that the 371 security parameter does not have a default value. 373 BIB-HMAC-SHA2 Security Parameters 375 +=========+=============+====================+===============+ 376 | Parm Id | Parm Name | CBOR Encoding Type | Default Value | 377 +=========+=============+====================+===============+ 378 | 1 | SHA Variant | unsigned integer | 6 | 379 +---------+-------------+--------------------+---------------+ 380 | 2 | Wrapped Key | Byte String | | 381 +---------+-------------+--------------------+---------------+ 382 | 3 | Integrity | unsigned integer | 7 | 383 | | Scope Flags | | | 384 +---------+-------------+--------------------+---------------+ 386 Table 2 388 3.4. Results 390 The BIB-HMAC-SHA2 security context results are listed in Table 3. In 391 this table, the "Result Id" column refers to the expected Result 392 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 393 and Result Identification". 395 BIB-HMAC-SHA2 Security Results 397 +========+==========+===============+======================+ 398 | Result | Result | CBOR Encoding | Description | 399 | Id | Name | Type | | 400 +========+==========+===============+======================+ 401 | 1 | Expected | byte string | The output of the | 402 | | HMAC | | HMAC calculation at | 403 | | | | the security source. | 404 +--------+----------+---------------+----------------------+ 406 Table 3 408 3.5. Key Considerations 410 HMAC keys used with this context MUST be symmetric and MUST have a 411 key length equal to the output of the HMAC. For this reason, HMAC 412 key lengths will be integer divisible by 8 bytes and special padding- 413 aware AES key wrap algorithms are not needed. 415 It is assumed that any security verifier or security acceptor 416 performing an integrity verification can determine the proper HMAC 417 key to be used. Potential sources of the HMAC key include (but are 418 not limited to) the following: 420 Pre-placed keys selected based on local policy. 422 Keys extracted from material carried in the BIB. 424 Session keys negotiated via a mechanism external to the BIB. 426 When an AES-KW wrapped key is present in a security block, it is 427 assumed that security verifiers and security acceptors can 428 independently determine the key encryption key (KEK) used in the 429 wrapping of the symmetric HMAC key. 431 As discussed in Section 6 and emphasized here, it is strongly 432 recommended that keys be protected once generated, both when they are 433 stored and when they are transmitted. 435 3.6. Security Processing Considerations 437 An HMAC calculated over the same IPPT with the same key will always 438 have the same value. This regularity can lead to practical side- 439 channel attacks whereby an attacker could produce known plain text 440 and a guess at an HMAC tag and observe the behavior of a verifier. 441 With a modest number of trials, a side-channel attack could produce 442 an HMAC tag for attacher-provided plain text without the attacker 443 ever knowing the HMAC key. 445 A common method of observing the behavior of a verifier is precise 446 analysis of the timing associated with comparisons. Therefore, one 447 way to prevent behavior analysis of this type is to ensure that any 448 comparisons of the supplied and expected authentication tag occur in 449 constant time. 451 A constant-time comparison function SHOULD be used for the comparison 452 of authentication tags by any implementation of this security 453 context. In cases where such a function is difficult or impossible 454 to use, the impact of side-channel (in general) and timing attacks 455 (specifically) need to be considered as part of the implementation. 457 3.7. Canonicalization Algorithms 459 This section defines the canonicalization algorithm used to prepare 460 the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The 461 construction of the IPPT depends on the settings of the integrity 462 scope flags that can be provided as part of customizing the behavior 463 of this security context. 465 In all cases, the canonical form of any portion of an extension block 466 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 467 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 468 the canonical forms for extension blocks defined in 469 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 470 are represented in CBOR. 472 The IPPT is constructed using the following process. While integrity 473 scope flags might not be included in the BIB representing the 474 security operation, they MUST be included in the IPPT value itself. 476 1. The canonical form of the IPPT starts as the CBOR encoding of the 477 integrity scope flags in which all unset flags, reserved bits, 478 and unassigned bits have been set to 0. For example, if the 479 primary block flag, target header flag, and security header flag 480 are each set, then the initial value of the canonical form of the 481 IPPT will be 0x07. 483 2. If the primary block flag of the integrity scope flags is set to 484 1, then a canonical form of the bundle's primary block MUST be 485 calculated and the result appended to the IPPT. 487 3. If the target header flag of the integrity scope flags is set to 488 1, then the canonical form of the block type code, block number, 489 and block processing control flags associated with the security 490 target MUST be calculated and, in that order, appended to the 491 IPPT. 493 4. If the security header flag of the integrity scope flags is set 494 to 1, then the canonical form of the block type code, block 495 number, and block processing control flags associated with the 496 BIB MUST be calculated and, in that order, appended to the IPPT. 498 5. The canonical form of the security target block-type-specific 499 data MUST be calculated and appended to the IPPT. 501 3.8. Processing 503 3.8.1. Keyed Hash Generation 505 During keyed hash generation, two inputs are prepared for the the 506 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 507 data items MUST be generated as follows. 509 The HMAC key MUST have the appropriate length as required by local 510 security policy. The key can be generated specifically for this 511 integrity service, given as part of local security policy, or 512 through some other key management mechanism as discussed in 513 Section 3.5. 515 Prior to the generation of the IPPT, if a CRC value is present for 516 the target block of the BIB, then that CRC value MUST be removed 517 from the target block. This involves both removing the CRC value 518 from the target block and setting the CRC Type field of the target 519 block to "no CRC is present." 520 Once CRC information is removed, the IPPT MUST be generated as 521 discussed in Section 3.7. 523 Upon successful hash generation the following actions MUST occur. 525 The keyed hash produced by the HMAC/SHA2 variant MUST be added as 526 a security result for the BIB representing the security operation 527 on this security target, as discussed in Section 3.4. 529 Finally, the BIB containing information about this security operation 530 MUST be updated as follows. These operations can occur in any order. 532 The security context identifier for the BIB MUST be set to the 533 context identifier for BIB-HMAC-SHA2. 535 Any local flags used to generate the IPPT MUST be placed in the 536 integrity scope flags security parameter for the BIB unless these 537 flags are expected to be correctly configured at security 538 verifiers and acceptors in the network. 540 The HMAC key MAY be included as a security parameter in which case 541 it MUST be wrapped using the NIST AES-KW algorithm and the results 542 of the wrapping added as the wrapped key security parameter for 543 the BIB. 545 The SHA variant used by this security context SHOULD be added as 546 the SHA variant security parameter for the BIB if it differs from 547 the default key length. Otherwise, this parameter MAY be omitted 548 if doing so provides a useful reduction in message sizes. 550 Problems encountered in the keyed hash generation MUST be processed 551 in accordance with local BPSec security policy. 553 3.8.2. Keyed Hash Verification 555 During keyed hash verification, the input of the security target and 556 a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. 558 During keyed hash verification, two inputs are prepared for the 559 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 560 data items MUST be generated as follows. 562 The HMAC key MUST be derived using the wrapped key security 563 parameter if such a parameter is included in the security context 564 parameters of the BIB. Otherwise, this key MUST be derived in 565 accordance with security policy at the verifying node as discussed 566 in Section 3.5. 568 The IPPT MUST be generated as discussed in Section 3.7 with the 569 value of integrity scope flags being taken from the integrity 570 scope flags security context parameter. If the integrity scope 571 flags parameter is not included in the security context parameters 572 then these flags MAY be derived from local security policy. 574 The calculated HMAC output MUST be compared to the expected HMAC 575 output encoded in the security results of the BIB for the security 576 target. If the calculated HMAC and expected HMAC are identical, the 577 verification MUST be considered a success. Otherwise, the 578 verification MUST be considered a failure. 580 If the verification fails or otherwise experiences an error, or if 581 any needed parameters are missing, then the verification MUST be 582 treated as failed and processed in accordance with local security 583 policy. 585 This security service is removed from the bundle at the security 586 acceptor as required by the BPSec specification. If the security 587 acceptor is not the bundle destination and if no other integrity 588 service is being applied to the target block, then a CRC MUST be 589 included for the target block. The CRC type, as determined by 590 policy, is set in the target block's CRC type field and the 591 corresponding CRC value is added as the CRC field for that block. 593 4. Security Context BCB-AES-GCM 595 4.1. Overview 597 The BCB-AES-GCM security context replaces the block-type-specific 598 data field of its security target with cipher text generated using 599 the Advanced Encryption Standard (AES) cipher operating in Galois/ 600 Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the 601 cipher suite for this confidentiality mechanism for several reasons: 603 1. The selection of a symmetric-key cipher suite allows for 604 relatively smaller keys than asymmetric-key cipher suites. 606 2. The selection of a symmetric-key cipher suite allows this 607 security context to be used in places where an asymmetric-key 608 infrastructure (such as a public key infrastructure) might be 609 impractical. 611 3. The use of the Galois/Counter Mode produces cipher-text with the 612 same size as the plain text making the replacement of target 613 block information easier as length fields do not need to be 614 changed. 616 4. The AES-GCM cipher suite provides authenticated encryption, as 617 required by the BPSec protocol. 619 Additionally, the BCB-AES-GCM security context generates an 620 authentication tag based on the plain text value of the block-type- 621 specific data and other additional authenticated data that might be 622 specified via parameters to this security context. 624 This security context supports two variants of AES-GCM, based on the 625 supported length of the symmetric key. These variants correspond to 626 A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value 627 for AES-GCM. 629 The BCB-AES-GCM security context MUST have the security context 630 identifier specified in Section 5.1. 632 4.2. Scope 634 There are two scopes associated with BCB-AES-GCM: the scope of the 635 confidentiality service and the scope of the authentication service. 636 The first defines the set of information provided to the AES-GCM 637 cipher for the purpose of producing cipher text. The second defines 638 the set of information used to generate an authentication tag. 640 The scope of the confidentiality service defines the set of 641 information provided to the AES-GCM cipher for the purpose of 642 producing cipher text. This MUST be the full set of plain text 643 contained in the block-type-specific data field of the security 644 target. 646 The scope of the authentication service defines the set of 647 information used to generate an authentication tag carried with the 648 security block. This information contains all data protected by the 649 confidentiality service, the scope flags used to identify other 650 optional information, and MAY include other information (additional 651 authenticated data), as follows. 653 Primary block 654 The primary block identifies a bundle and, once created, the 655 contents of this block are immutable. Changes to the primary 656 block associated with the security target indicate that the 657 security target (and BCB) might no longer be in the correct 658 bundle. 660 For example, if a security target and associated BCB are copied 661 from one bundle to another bundle, the BCB might still be able to 662 decrypt the security target even though these blocks were never 663 intended to exist in the copied-to bundle. 665 Including this information as part of additional authenticated 666 data ensures that security target (and security block) appear in 667 the same bundle at the time of decryption as at the time of 668 encryption. 670 Security target other fields 671 The other fields of the security target include block 672 identification and processing information. Changing this 673 information changes how the security target is treated by nodes 674 in the network even when the "user data" of the security target 675 are otherwise unchanged. 677 For example, if the block processing control flags of a security 678 target are different at a security verifier than they were 679 originally set at the security source then the policy for 680 handling the security target has been modified. 682 Including this information as part of additional authenticated 683 data ensures that the cipher text in the security target will not 684 be used with a different set of block policy than originally set 685 at the time of encryption. 687 BCB other fields 688 The other fields of the BCB include block identification and 689 processing information. Changing this information changes how 690 the BCB is treated by nodes in the network, even when other 691 aspects of the BCB are unchanged. 693 For example, if the block processing control flags of the BCB are 694 different at a security acceptor than they were originally set at 695 the security source then the policy for handling the BCB has been 696 modified. 698 Including this information as part of additional authenticated 699 data ensures that the policy and identification of the security 700 service in the bundle has not changed. 702 NOTE: The security context identifier and security context 703 parameters of the security block are not included as additional 704 authenticated data because these parameters, by definition, are 705 those needed to verify or accept the security service. 706 Therefore, it is expected that changes to these values would 707 result in failures at security verifiers and security acceptors. 708 This is the case because keys cannot be re-used across security 709 contexts, and because the AAD scope flags used to identify the 710 AAD are included in the AAD. 712 The scope of the BCB-AES-GCM security context is configured using an 713 optional security context parameter. 715 4.3. Parameters 717 BCB-AES-GCM can be parameterized to specify the AES variant, 718 initialization vector, key information, and identify additional 719 authenticated data. 721 4.3.1. Initialization Vector (IV) 723 This optional parameter identifies the initialization vector (IV) 724 used to initialize the AES-GCM cipher. 726 The length of the initialization vector, prior to any CBOR encoding, 727 MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used 728 unless local security policy requires a different length. 730 This value MUST be encoded as a CBOR byte string. 732 The initialization vector can have any value with the caveat that a 733 value MUST NOT be re-used for multiple encryptions using the same 734 encryption key. This value MAY be re-used when encrypting with 735 different keys. For example, if each encryption operation using BCB- 736 AES-GCM uses a newly generated key, then the same IV can be reused. 738 4.3.2. AES Variant 740 This optional parameter identifies the AES variant being used for the 741 AES-GCM encryption, where the variant is identified by the length of 742 key used. 744 This value MUST be encoded as a CBOR unsigned integer. 746 Valid values for this parameter are as follows. 748 AES Variant Parameter Values 750 +=======+=======================================+ 751 | Value | Description | 752 +=======+=======================================+ 753 | 1 | A128GCM as defined in [RFC8152] | 754 | | Table 9: Algorithm Values for AES-GCM | 755 +-------+---------------------------------------+ 756 | 3 | A256GCM as defined in [RFC8152] | 757 | | Table 9: Algorithm Values for AES-GCM | 758 +-------+---------------------------------------+ 760 Table 4 762 When not provided, implementations SHOULD assume a value of 3 763 (indicating use of A256GCM), unless an alternate default is 764 established by local security policy at the security source, 765 verifier, or acceptor of this integrity service. 767 Regardless of the variant, the generated authentication tag MUST 768 always be 128 bits. 770 4.3.3. Wrapped Key 772 This optional parameter contains the output of the AES key wrap 773 authenticated encryption function (KW-AE) as defined in [RFC5649]. 774 Specifically, this parameter holds the cipher text produced when 775 running the KW-AE algorithm with the input string being the symmetric 776 AES key used to generate the security results present in the security 777 block. The value of this parameter is used as input to the AES key 778 wrap authenticated decryption function (KW-AD) at security verifiers 779 and security acceptors to determine the symmetric AES key needed for 780 the proper decryption of the security results in the security block. 782 This value MUST be encoded as a CBOR byte string. 784 If this parameter is not present then security verifiers and 785 acceptors MUST determine the proper key as a function of their local 786 BPSec policy and configuration. 788 4.3.4. AAD Scope Flags 790 This optional parameter contains a series of flags that describe what 791 information is to be included with the block-type-specific data of 792 the security target as part of additional authenticated data (AAD). 794 This value MUST be represented as a CBOR unsigned integer, the value 795 of which MUST be processed as a 16-bit field. The maximum value of 796 this field, as a CBOR unsigned integer, MUST be 65535. 798 Implementations MUST set reserved and unassigned bits in this field 799 to 0 when constructing these flags at a security source. Once set, 800 the value of this field MUST NOT be altered until the security 801 service is completed at the security acceptor in the network and 802 removed from the bundle. 804 Bits in this field represent additional information to be included 805 when generating an integrity signature over the security target. 806 These bits are defined as follows. 808 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 810 - Bit 1 (0x0002): Target Header Flag. 812 - Bit 2 (0x0004): Security Header Flag. 814 - Bits 3-7 are reserved. 816 - Bits 8-15 are unassigned. 818 4.3.5. Enumerations 820 The BCB-AES-GCM security context parameters are listed in Table 5. 821 In this table, the "Parm Id" column refers to the expected Parameter 822 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 823 and Result Identification". 825 If the default value column is empty, this indicates that the 826 security parameter does not have a default value. 828 BCB-AES-GCM Security Parameters 830 +=========+================+====================+===============+ 831 | Parm Id | Parm Name | CBOR Encoding Type | Default Value | 832 +=========+================+====================+===============+ 833 | 1 | Initialization | Byte String | | 834 | | Vector | | | 835 +---------+----------------+--------------------+---------------+ 836 | 2 | AES Variant | Unsigned Integer | 3 | 837 +---------+----------------+--------------------+---------------+ 838 | 3 | Wrapped Key | Byte String | | 839 +---------+----------------+--------------------+---------------+ 840 | 4 | AAD Scope | Unsigned Integer | 7 | 841 | | Flags | | | 842 +---------+----------------+--------------------+---------------+ 844 Table 5 846 4.4. Results 848 The BCB-AES-GCM security context produces a single security result 849 carried in the security block: the authentication tag. 851 NOTES: 853 * The cipher text generated by the cipher suite is not considered a 854 security result as it is stored in the block-type-specific data 855 field of the security target block. When operating in GCM mode, 856 AES produces cipher text of the same size as its plain text and, 857 therefore, no additional logic is required to handle padding or 858 overflow caused by the encryption in most cases (see below). 860 * If the authentication tag can be separated from the cipher text, 861 then the tag MAY be separated and stored in the authentication tag 862 security result field. Otherwise, the security target block MUST 863 be resized to accommodate the additional 128 bits of 864 authentication tag included with the generated cipher text 865 replacing the block-type-specific-data field of the security 866 target block. 868 4.4.1. Authentication Tag 870 The authentication tag is generated by the cipher suite over the 871 security target plain text input to the cipher suite as combined with 872 any optional additional authenticated data. This tag is used to 873 ensure that the plain text (and important information associated with 874 the plain text) is authenticated prior to decryption. 876 If the authentication tag is included in the cipher text placed in 877 the security target block-type-specific data field, then this 878 security result MUST NOT be included in the BCB for that security 879 target. 881 The length of the authentication tag, prior to any CBOR encoding, 882 MUST be 128 bits. 884 This value MUST be encoded as a CBOR byte string. 886 4.4.2. Enumerations 888 The BCB-AES-GCM security context results are listed in Table 6. In 889 this table, the "Result Id" column refers to the expected Result 890 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 891 and Result Identification". 893 BCB-AES-GCM Security Results 895 +===========+====================+====================+ 896 | Result Id | Result Name | CBOR Encoding Type | 897 +===========+====================+====================+ 898 | 1 | Authentication Tag | Byte String | 899 +-----------+--------------------+--------------------+ 901 Table 6 903 4.5. Key Considerations 905 Keys used with this context MUST be symmetric and MUST have a key 906 length equal to the key length defined in the security context 907 parameters or as defined by local security policy at security 908 verifiers and acceptors. For this reason, content-encrypting key 909 lengths will be integer divisible by 8 bytes and special padding- 910 aware AES key wrap algorithms are not needed. 912 It is assumed that any security verifier or security acceptor can 913 determine the proper key to be used. Potential sources of the key 914 include (but are not limited to) the following. 916 Pre-placed keys selected based on local policy. 918 Keys extracted from material carried in the BCB. 920 Session keys negotiated via a mechanism external to the BCB. 922 When an AES-KW wrapped key is present in a security block, it is 923 assumed that security verifiers and security acceptors can 924 independently determine the key encryption key (KEK) used in the 925 wrapping of the symmetric AES content-encrypting key. 927 The security provided by block ciphers is reduced as more data is 928 processed with the same key. The total number of AES blocks 929 processed with a single key for AES-GCM is recommended to be less 930 than 2^64, as described in Appendix B of [AES-GCM]. 932 Additionally, there exist limits on the number of encryptions that 933 can be performed with the same key. The total number of invocations 934 of the authenticated encryption function with a single key for AES- 935 GCM is required to not exceed 2^32, as described in Section 8.3 of 936 [AES-GCM]. 938 As discussed in Section 6 and emphasized here, it is strongly 939 recommended that keys be protected once generated, both when they are 940 stored and when they are transmitted. 942 4.6. GCM Considerations 944 The GCM cryptographic mode of AES has specific requirements that MUST 945 be followed by implementers for the secure function of the BCB-AES- 946 GCM security context. While these requirements are well documented 947 in [AES-GCM], some of them are repeated here for emphasis. 949 With the exception of the AES-KW function, the IVs used by the 950 BCB-AES-GCM security context are considered to be per-invocation 951 IVs. The pairing of a per-invocation IV and a security key MUST 952 be unique. A per-invocation IV MUST NOT be used with a security 953 key more than one time. If a per-invocation IV and key pair are 954 repeated then the GCM implementation is vulnerable to forgery 955 attacks. Because the loss of integrity protection occurs with 956 even a single reuse, this situation is often considered to have 957 catastrophic security consequences. More information regarding 958 the importance of the uniqueness of the IV value can be found in 959 Appendix A of [AES-GCM]. 961 Methods of generating unique IV values are provided in Chapter 8 962 of [AES-GCM]. For example, one method decomposes the IV value 963 into a fixed field and an invocation field. The fixed field being 964 a constant value associated with a device and the invocation field 965 changing on each invocation (such as by incrementing an integer 966 counter). Implementers SHOULD carefully read all relevant 967 sections of [AES-GCM] when generating any mechanism to create 968 unique IVs. 970 The AES-KW function used to wrap keys for the security contexts in 971 this document uses a single, globally constant IV input to the AES 972 cipher operation and, thus, is distinct from the aforementioned 973 requirement related to per-invocation IVs. 975 While any tag-based authentication mechanism has some likelihood 976 of being forged, this probability is increased when using AES-GCM. 977 In particular, short tag lengths combined with very long messages 978 SHOULD be avoided when using this mode. The BCB-AES-GCM security 979 context requires the use of 128-bit authentication tags at all 980 times. Concerns relating to the size of authentication tags is 981 discussed in Appendices B and C of [AES-GCM]. 983 As discussed in Appendix B of [AES-GCM], implementations SHOULD 984 limit the number of unsuccessful verification attempts for each 985 key to reduce the likelihood of guessing tag values. This type of 986 check has potential state-keeping issues when AES-KW is used, 987 since an attacker could cause a large number of keys to have been 988 used at least once. 990 As discussed in the Security Considerations section of 991 [I-D.ietf-dtn-bpsec], delay-tolerant networks have a higher 992 occurrence of replay attacks due to the store-and-forward nature 993 of the network. Because GCM has no inherent replay attack 994 protection, implementors SHOULD attempt to detect replay attacks 995 by using mechanisms such as those described in Appendix D of 996 [AES-GCM]. 998 4.7. Canonicalization Algorithms 1000 This section defines the canonicalization algorithms used to prepare 1001 the inputs used to generate both the cipher text and the 1002 authentication tag. 1004 In all cases, the canonical form of any portion of an extension block 1005 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 1006 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 1007 the canonical forms for extension blocks defined in 1008 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 1009 are represented in CBOR. 1011 4.7.1. Cipher text related calculations 1013 The BCB operates over the block-type-specific data of a block, but 1014 the BP always encodes these data within a single, definite-length 1015 CBOR byte string. Therefore, the plain text used during encryption 1016 MUST be calculated as the value of the block-type-specific data field 1017 of the security target excluding the BP CBOR encoding. 1019 Consider the following two CBOR encoded examples and the plain text 1020 that would be extracted from them. The first example is an unsigned 1021 integer, while the second is a byte string. 1023 CBOR Plain Text Extraction Examples 1025 +==============================+=======+==========================+ 1026 | CBOR Encoding (Hex) | CBOR | Plain Text Part (Hex) | 1027 | | Part | | 1028 | | (Hex) | | 1029 +==============================+=======+==========================+ 1030 | 18ED | 18 | ED | 1031 +------------------------------+-------+--------------------------+ 1032 | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | 1033 +------------------------------+-------+--------------------------+ 1035 Table 7 1037 Similarly, the cipher text used during decryption MUST be calculated 1038 as the single, definite-length CBOR byte string representing the 1039 block-type-specific data field excluding the CBOR byte string 1040 identifying byte and optional CBOR byte string length field. 1042 All other fields of the security target (such as the block type code, 1043 block number, block processing control flags, or any CRC information) 1044 MUST NOT be considered as part of encryption or decryption. 1046 4.7.2. Additional Authenticated Data 1048 The construction of additional authenticated data depends on the AAD 1049 scope flags that can be provided as part of customizing the behavior 1050 of this security context. 1052 The canonical form of the AAD input to the BCB-AES-GCM mechanism is 1053 constructed using the following process. While the AAD scope flags 1054 might not be included in the BCB representing the security operation, 1055 they MUST be included in the AAD value itself. This process MUST be 1056 followed when generating AAD for either encryption or decryption. 1058 1. The canonical form of the AAD starts as the CBOR encoding of the 1059 AAD scope flags in which all unset flags, reserved bits, and 1060 unassigned bits have been set to 0. For example, if the primary 1061 block flag, target header flag, and security header flag are each 1062 set, then the initial value of the canonical form of the AAD will 1063 be 0x07. 1065 2. If the primary block flag of the AAD scope flags is set to 1, 1066 then a canonical form of the bundle's primary block MUST be 1067 calculated and the result appended to the AAD. 1069 3. If the target header flag of the AAD scope flags is set to 1, 1070 then the canonical form of the block type code, block number, and 1071 block processing control flags associated with the security 1072 target MUST be calculated and, in that order, appended to the 1073 AAD. 1075 4. If the security header flag of the AAD scope flags is set to 1, 1076 then the canonical form of the block type code, block number, and 1077 block processing control flags associated with the BIB MUST be 1078 calculated and, in that order, appended to the AAD. 1080 4.8. Processing 1082 4.8.1. Encryption 1084 During encryption, four inputs are prepared for input to the AES/GCM 1085 cipher: the encryption key, the IV, the security target plain text to 1086 be encrypted, and any additional authenticated data. These data 1087 items MUST be generated as follows. 1089 Prior to encryption, if a CRC value is present for the target block, 1090 then that CRC value MUST be removed. This requires removing the CRC 1091 field from the target block and setting the CRC type field of the 1092 target block to "no CRC is present." 1094 The encryption key MUST have the appropriate length as required by 1095 local security policy. The key might be generated specifically 1096 for this encryption, given as part of local security policy, or 1097 through some other key management mechanism as discussed in 1098 Section 4.5. 1100 The IV selected MUST be of the appropriate length. Because 1101 replaying an IV in counter mode voids the confidentiality of all 1102 messages encrypted with said IV, this context also requires a 1103 unique IV for every encryption performed with the same key. This 1104 means the same key and IV combination MUST NOT be used more than 1105 once. 1107 The security target plain text for encryption MUST be generated as 1108 discussed in Section 4.7.1. 1110 Additional authenticated data MUST be generated as discussed in 1111 Section 4.7.2 with the value of AAD scope flags being taken from 1112 local security policy. 1114 Upon successful encryption the following actions MUST occur. 1116 The cipher text produced by AES/GCM MUST replace the bytes used to 1117 define the plain text in the security target block's block-type- 1118 specific data field. The block length of the security target MUST 1119 be updated if the generated cipher text is larger than the plain 1120 text (which can occur when the authentication tag is included in 1121 the cipher text calculation, as discussed in Section 4.4). 1123 The authentication tag calculated by the AES/GCM cipher MAY be 1124 added as a security result for the security target in the BCB 1125 holding results for this security operation, in which case it MUST 1126 be processed as described in Section 4.4. 1128 The authentication tag MUST be included either as a security 1129 result in the BCB representing the security operation or (with the 1130 cipher text) in the security target block-type-specific data 1131 field. 1133 Finally, the BCB containing information about this security operation 1134 MUST be updated as follows. These operations can occur in any order. 1136 The security context identifier for the BCB MUST be set to the 1137 context identifier for BCB-AES-GCM. 1139 The IV input to the cipher MUST be added as the IV security 1140 parameter for the BCB. 1142 Any local flags used to generated AAD for this cipher MUST be 1143 placed in the AAD scope flags security parameter for the BCB 1144 unless these flags are expected to be correctly configured at 1145 security verifiers and security acceptors in the network. 1147 The encryption key MAY be included as a security parameter in 1148 which case it MUST be wrapped using the NIST AES-KW algorithm and 1149 the results of the wrapping added as the wrapped key security 1150 parameter for the BCB. 1152 The AES variant used by this security context SHOULD be added as 1153 the AES variant security parameter for the BCB if it differs from 1154 the default key length. Otherwise, this parameter MAY be omitted 1155 if doing so provides a useful reduction in message sizes. 1157 Problems encountered in the encryption MUST be processed in 1158 accordance with local security policy. This MAY include restoring a 1159 CRC value removed from the target block prior to encryption, if the 1160 target block is allowed to be transmitted after an encryption error. 1162 4.8.2. Decryption 1164 During decryption, five inputs are prepared for input to the AES/GCM 1165 cipher: the decryption key, the IV, the security target cipher text 1166 to be decrypted, any additional authenticated data, and the 1167 authentication tag generated from the original encryption. These 1168 data items MUST be generated as follows. 1170 The decryption key MUST be derived using the wrapped key security 1171 parameter if such a parameter is included in the security context 1172 parameters of the BCB. Otherwise this key MUST be derived in 1173 accordance with local security policy at the decrypting node as 1174 discussed in Section 4.5. 1176 The IV MUST be set to the value of the IV security parameter 1177 included in the BCB. If the IV parameter is not included as a 1178 security parameter, an IV MAY be derived as a function of local 1179 security policy and other BCB contents or a lack of an IV security 1180 parameter in the BCB MAY be treated as an error by the decrypting 1181 node. 1183 The security target cipher text for decryption MUST be generated 1184 as discussed in Section 4.7.1. 1186 Additional authenticated data MUST be generated as discussed in 1187 Section 4.7.2 with the value of AAD scope flags being taken from 1188 the AAD scope flags security context parameter. If the AAD scope 1189 flags parameter is not included in the security context parameters 1190 then these flags MAY be derived from local security policy in 1191 cases where the set of such flags is determinable in the network. 1193 The authentication tag MUST be present either as a security result 1194 in the BCB representing the security operation or (with the cipher 1195 text) in the security target block-type-specific data field. 1197 Upon successful decryption the following actions MUST occur. 1199 The plain text produced by AES/GCM MUST replace the bytes used to 1200 define the cipher text in the security target block's block-type- 1201 specific data field. Any changes to the security target block 1202 length field MUST be corrected in cases where the plain text has a 1203 different length than the replaced cipher text. 1205 If the security acceptor is not the bundle destination and if no 1206 other integrity or confidentiality service is being applied to the 1207 target block, then a CRC MUST be included for the target block. The 1208 CRC type, as determined by policy, is set in the target block's CRC 1209 type field and the corresponding CRC value is added as the CRC field 1210 for that block. 1212 If the cipher text fails to authenticate, if any needed parameters 1213 are missing, or if there are other problems in the decryption then 1214 the decryption MUST be treated as failed and processed in accordance 1215 with local security policy. 1217 5. IANA Considerations 1219 5.1. Security Context Identifiers 1221 This specification allocates two security context identifiers from 1222 the "BPSec Security Context Identifiers" registry defined in 1223 [I-D.ietf-dtn-bpsec]. 1225 Additional Entries for the BPSec Security Context Identifiers 1226 Registry: 1228 +=======+===============+===============+ 1229 | Value | Description | Reference | 1230 +=======+===============+===============+ 1231 | TBA | BIB-HMAC-SHA2 | This document | 1232 +-------+---------------+---------------+ 1233 | TBA | BCB-AES-GCM | This document | 1234 +-------+---------------+---------------+ 1236 Table 8 1238 5.2. Integrity Scope Flags 1240 The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field 1241 for which IANA is requested to create and maintain a new registry 1242 named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle 1243 Protocol registry page. Initial values for this registry are given 1244 below. 1246 The registration policy for this registry is: Specification Required. 1248 The value range is unsigned 16-bit integer. 1250 BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry 1252 +==============================+=======================+===========+ 1253 | Bit Position (right to left) | Description | Reference | 1254 +==============================+=======================+===========+ 1255 | 0 | Include primary block | This | 1256 | | | document | 1257 +------------------------------+-----------------------+-----------+ 1258 | 1 | Include target header | This | 1259 | | flag | document | 1260 +------------------------------+-----------------------+-----------+ 1261 | 2 | Include security | This | 1262 | | header flag | document | 1263 +------------------------------+-----------------------+-----------+ 1264 | 3-7 | reserved | This | 1265 | | | document | 1266 +------------------------------+-----------------------+-----------+ 1267 | 8-15 | unassigned | This | 1268 | | | document | 1269 +------------------------------+-----------------------+-----------+ 1271 Table 9 1273 5.3. AAD Scope Flags 1275 The BCB-AES-GCM security context has an AAD Scope Flags field for 1276 which IANA is requested to create and maintain a new registry named 1277 "BPSec BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol registry 1278 page. Initial values for this registry are given below. 1280 The registration policy for this registry is: Specification Required. 1282 The value range is unsigned 16-bit integer. 1284 BPSec BCB-AES-GCM AAD Scope Flags Registry 1286 +==============================+=======================+===========+ 1287 | Bit Position (right to left) | Description | Reference | 1288 +==============================+=======================+===========+ 1289 | 0 | Include primary block | This | 1290 | | | document | 1291 +------------------------------+-----------------------+-----------+ 1292 | 1 | Include target header | This | 1293 | | flag | document | 1294 +------------------------------+-----------------------+-----------+ 1295 | 2 | Include security | This | 1296 | | header flag | document | 1297 +------------------------------+-----------------------+-----------+ 1298 | 3-7 | reserved | This | 1299 | | | document | 1300 +------------------------------+-----------------------+-----------+ 1301 | 8-15 | unassigned | This | 1302 | | | document | 1303 +------------------------------+-----------------------+-----------+ 1305 Table 10 1307 5.4. Guidance for Designated Experts 1309 New assignments within the BIB-HMAC-SHA2 Integrity Scope Flags 1310 Registry and the BCB-AES-GCM AAD Scope Flags Registry require review 1311 by a Designated Expert (DE). This section provides guidance to the 1312 DE when performing their reviews. Specifically, a DE is expected to 1313 perform the following activities. 1315 * Ascertain the existence of suitable documentation (a 1316 specification) as described in [RFC8126] and to verify that the 1317 document is permanently and publicly available. 1319 * Ensure that any changes to the Integrity Scope Flags clearly state 1320 how new assignments interact with existing flags and how the 1321 inclusion of new assignments affects the construction of the IPPT 1322 value. 1324 * Ensure that any changes to the AAD Scope Flags clearly state how 1325 new assignments interact with existing flags and how the inclusion 1326 of new assignments affects the construction of the AAD input to 1327 the BCB-AES-GCM mechanism. 1329 * Ensure that any processing changes proposed with new assignments 1330 do not alter any required behavior in this specification. 1332 6. Security Considerations 1334 Security considerations specific to a single security context are 1335 provided in the description of that context. This section discusses 1336 security considerations that should be evaluated by implementers of 1337 any security context described in this document. Considerations can 1338 also be found in documents listed as normative references and they 1339 should also be reviewed by security context implementors. 1341 6.1. Key Management 1343 The delayed and disrupted nature of DTNs complicates the process of 1344 key management because there might not be reliable, timely round-trip 1345 exchange between security sources, security verifiers, and security 1346 acceptors in the network. This is true when there is a substantial 1347 signal propagation delay between nodes, when nodes are in a highly 1348 challenged communications environment, and when nodes do not support 1349 bi-directional communication. 1351 In these environments, key establishment protocols that rely on 1352 round-trip information exchange might not converge on a shared secret 1353 in a timely manner (or at all). Also, key revocation or key 1354 verification mechanisms that rely on access to a centralized 1355 authority (such as a certificate authority) might similarly fail in 1356 the stressing conditions of a DTN. 1358 For these reasons, the default security contexts described in this 1359 document rely on symmetric key cryptographic mechanisms because 1360 asymmetric key infrastructure (such as a public key infrastructure) 1361 might be impractical in this environment. 1363 BPSec assumes that "key management is handled as a separate part of 1364 network management" [I-D.ietf-dtn-bpsec]. This assumption is also 1365 made by the security contexts defined in this document which do not 1366 define new protocols for key derivation, exchange of key-encrypting 1367 keys, revocation of existing keys, or the security configuration or 1368 policy used to select certain keys for certain security operations. 1370 Nodes using these security contexts need to perform the following 1371 kinds of activities, independent of the construction, transmission, 1372 and processing of BPSec security blocks. 1374 Establish shared key-encrypting-keys with other nodes in the 1375 network using an out-of-band mechanism. This might include pre- 1376 sharing of key encryption keys or the use of traditional key 1377 establishment mechanisms prior to the exchange of BPsec security 1378 blocks. 1380 Determine when a key is considered exhausted and no longer to be 1381 used in the generation, verification, or acceptance of a security 1382 block. 1384 Determine when a key is considered invalid and no longer to be 1385 used in the generation, verification, or acceptance of a security 1386 block. Such revocations can be based on a variety of mechanisms 1387 to include local security policy, time relative to the generation 1388 or use of the key, or as specified through network management. 1390 Determine, through an out-of-band mechanism such as local security 1391 policy, what keys are to be used for what security blocks. This 1392 includes the selection of which key should be used in the 1393 evaluation of a security block received by a security verifier or 1394 a security acceptor. 1396 The failure to provide effective key management techniques 1397 appropriate for the operational networking environment can result in 1398 the compromise of those unmanaged keys and the loss of security 1399 services in the network. 1401 6.2. Key Handling 1403 Once generated, keys should be handled as follows. 1405 It is strongly RECOMMENDED that implementations protect keys both 1406 when they are stored and when they are transmitted. 1408 In the event that a key is compromised, any security operations 1409 using a security context associated with that key SHOULD also be 1410 considered compromised. This means that the BIB-HMAC-SHA2 1411 security context SHOULD NOT be treated as providing integrity when 1412 used with a compromised key and BCB-AES-GCM SHOULD NOT be treated 1413 as providing confidentiality when used with a compromised key. 1415 The same key, whether a key-encrypting-key or a wrapped key, MUST 1416 NOT be used for different algorithms as doing so might leak 1417 information about the key. 1419 A key-encrypting-key MUST NOT be used to encrypt keys for 1420 different security contexts. Any key-encrypting-key used by a 1421 security context defined in this document MUST only be used to 1422 wrap keys associated with security operations using that security 1423 context. This means that a compliant security source would not 1424 use the same key-encrypting-key to wrap keys for both the BIB- 1425 HMAC-SHA2 and BCB-AES-GCM security contexts. Similarly, any 1426 compliant security verifier or security acceptor would not use the 1427 same key-encrypting-key to unwrap keys for different security 1428 contexts. 1430 6.3. AES GCM 1432 There are a significant number of considerations related to the use 1433 of the GCM mode of AES to provide a confidentiality service. These 1434 considerations are provided in Section 4.6 as part of the 1435 documentation of the BCB-AES-GCM security context. 1437 The length of the cipher text produced by the GCM mode of AES will be 1438 equal to the length of the plain text input to the cipher suite. The 1439 authentication tag also produced by this cipher suite is separate 1440 from the cipher text. However, it should be noted that 1441 implementations of the AES-GCM cipher suite might not separate the 1442 concept of cipher text and authentication tag in their application 1443 programming interface (API). 1445 Implementations of the BCB-AES-GCM security context can either keep 1446 the length of the target block unchanged by holding the 1447 authentication tag in a BCB security result or alter the length of 1448 the target block by including the authentication tag with the cipher 1449 text replacing the block-type-specific-data field of the target 1450 block. Implementations MAY use the authentication tag security 1451 result in cases where keeping target block length unchanged is an 1452 important processing concern. In all cases, the cipher text and 1453 authentication tag MUST be processed in accordance with the API of 1454 the AES-GCM cipher suites at the security source and security 1455 acceptor. 1457 6.4. AES Key Wrap 1459 The AES key wrap (AES-KW) algorithm used by the security contexts in 1460 this document does not use a per-invocation initialization vector and 1461 does not require any key padding. Key padding is not needed because 1462 wrapped keys used by these security contexts will always be multiples 1463 of 8 bytes. The length of the wrapped key can be determined by 1464 inspecting the security context parameters. Therefore, a key can be 1465 unwrapped using only the information present in the security block 1466 and the key encryption key provided by local security policy at the 1467 security verifier or security acceptor. 1469 6.5. Bundle Fragmentation 1471 Bundle fragmentation might prevent security services in a bundle from 1472 being verified after a bundle is fragmented and before the bundle is 1473 re-assembled. Examples of potential issues include the following. 1475 If a security block and its security target do not exist in the 1476 same fragment, then the security block cannot be processed until 1477 the bundle is re-assembled. If a fragment includes an encrypted 1478 target block, but not its BCB, then a receiving bundle processing 1479 agent (BPA) will not know that the target block has been 1480 encrypted. 1482 A security block can be cryptographically bound to a bundle by 1483 setting the Integrity Scope Flags (for BIB-HMAC-SHA2) or the AAD 1484 Scope Flags (for BCB-AES-GCM) to include the bundle primary block. 1486 When a security block is cryptographically bound to a bundle, it 1487 cannot be processed even if the security block and target both 1488 coexist in the fragment. This is because fragments have different 1489 primary blocks than the original bundle. 1491 If security blocks and their target blocks are repeated in 1492 multiple fragments, policy needs to determine how to deal with 1493 issues where a security operation verifies in one fragment but 1494 fails in another fragment. This might happen, for example, if a 1495 BIB block becomes corrupted in one fragment but not in another 1496 fragment. 1498 Implementors should consider how security blocks are processed when a 1499 BPA fragments a received bundle. For example, security blocks and 1500 their targets could be placed in the same fragment if the security 1501 block is not otherwise cryptographically bound to the bundle being 1502 fragmented. Alternatively, if security blocks are cryptographically 1503 bound to a bundle, then a fragmenting BPA should consider 1504 encapsulating the bundle first and then fragmenting the encapsulating 1505 bundle. 1507 7. Normative References 1509 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 1510 Recommendation for Block Cipher Modes of Operation: 1511 Galois/Counter Mode (GCM) and GMAC.", November 2007. 1513 [I-D.ietf-dtn-bpbis] 1514 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle 1515 Protocol Version 7", Work in Progress, Internet-Draft, 1516 draft-ietf-dtn-bpbis-31, 25 January 2021, 1517 . 1520 [I-D.ietf-dtn-bpsec] 1521 III, E. J. B. and K. McKeever, "Bundle Protocol Security 1522 Specification", Work in Progress, Internet-Draft, draft- 1523 ietf-dtn-bpsec-27, 16 February 2021, 1524 . 1527 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1528 Hashing for Message Authentication", RFC 2104, 1529 DOI 10.17487/RFC2104, February 1997, 1530 . 1532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1533 Requirement Levels", BCP 14, RFC 2119, 1534 DOI 10.17487/RFC2119, March 1997, 1535 . 1537 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1538 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1539 DOI 10.17487/RFC5649, September 2009, 1540 . 1542 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1543 Writing an IANA Considerations Section in RFCs", BCP 26, 1544 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1545 . 1547 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1548 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1549 . 1551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1553 May 2017, . 1555 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1556 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1557 . 1559 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1560 Representation (CBOR)", STD 94, RFC 8949, 1561 DOI 10.17487/RFC8949, December 2020, 1562 . 1564 [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- 1565 180-4, Gaithersburg, MD, USA, August 2015. 1566 https://csrc.nist.gov/publications/detail/fips/180/4/final 1568 Appendix A. Examples 1570 This appendix is informative. 1572 This section presents a series of examples of constructing BPSec 1573 security blocks (using the security contexts defined in this 1574 document) and adding those blocks to a sample bundle. 1576 The examples presented in this appendix represent valid constructions 1577 of bundles, security blocks, and the encoding of security context 1578 parameters and results. For this reason, they can inform unit test 1579 suites for individual implementations as well as interoperability 1580 test suites amongst implementations. However, these examples do not 1581 cover every permutation of security parameters, security results, or 1582 use of security blocks in a bundle. 1584 NOTE: The bundle diagrams in this section are patterned after the 1585 bundle diagrams used in [I-D.ietf-dtn-bpsec] Section 3.11 "BSP Block 1586 Examples". 1588 NOTE: Figures in this section identified as "(CBOR Diagnostic 1589 Notation)" are represented using the CBOR diagnostic notation defined 1590 in [RFC8949]. This notation is used to express CBOR data structures 1591 in a manner that enables visual inspection. The bundles, security 1592 blocks, and security context contents in these figures are 1593 represented using CBOR structures. In cases where BP blocks (to 1594 include BPSec security blocks) are comprised of a sequence of CBOR 1595 objects, these objects are represented as a CBOR sequence as defined 1596 in [RFC8742]. 1598 NOTE: Examples in this section use the "ipn" URI scheme for 1599 EndpointID naming, as defined in [I-D.ietf-dtn-bpbis]. 1601 NOTE: The bundle source is presumed to be the security source for all 1602 security blocks in this section, unless otherwise noted. 1604 A.1. Example 1: Simple Integrity 1606 This example shows the addition of a BIB to a sample bundle to 1607 provide integrity for the payload block. 1609 A.1.1. Original Bundle 1611 The following diagram shows the original bundle before the BIB has 1612 been added. 1614 Block Block Block 1615 in Bundle Type Number 1616 +========================================+=======+========+ 1617 | Primary Block | N/A | 0 | 1618 +----------------------------------------+-------+--------+ 1619 | Payload Block | 1 | 1 | 1620 +----------------------------------------+-------+--------+ 1622 Figure 1: Example 1 Original Bundle 1624 A.1.1.1. Primary Block 1626 The BPv7 bundle has no special processing flags and no CRC is 1627 provided because the primary block is expected to be protected by an 1628 integrity service BIB using the BIB-HMAC-SHA2 security context. 1630 The bundle is sourced at the source node ipn:2.1 and destined for the 1631 destination node ipn:1.2. The bundle creation time uses a DTN 1632 creation time of 0 indicating lack of an accurate clock and a 1633 sequence number of 40. The lifetime of the bundle is given as 1634 1,000,000 milliseconds since the bundle creation time. 1636 The primary block is provided as follows. 1638 [ 1639 7, / BP version / 1640 0, / flags / 1641 0, / CRC type / 1642 [2, [1,2]], / destination (ipn:1.2) / 1643 [2, [2,1]], / source (ipn:2.1) / 1644 [2, [2,1]], / report-to (ipn:2.1) / 1645 [0, 40], / timestamp / 1646 1000000 / lifetime / 1647 ] 1649 Figure 2: Primary Block (CBOR Diagnostic Notation) 1651 The CBOR encoding of the primary block is 1652 0x88070000820282010282028202018202820201820018281a000f4240. 1654 A.1.1.2. Payload Block 1656 Other than its use as a source of plaintext for security blocks, the 1657 payload has no required distinguishing characteristic for the purpose 1658 of this example. The sample payload is a 32 byte string whose value 1659 is "Ready Generate a 32 byte payload". 1661 The payload is represented in the payload block as a byte string of 1662 the raw payload string. It is NOT represented as a CBOR text string 1663 wrapped within a CBOR binary string. The hex value of the payload 1664 "Ready Generate a 32 byte payload" is 1665 0x52656164792047656e657261746520612033322062797465207061796c6f6164. 1667 The payload block is provided as follows. 1669 [ 1670 1, / type code: Payload block / 1671 1, / block number / 1672 0, / block processing flags / 1673 0, / CRC Type / 1674 h'52656164792047656e65726174652061 / type-specific-data: payload / 1675 2033322062797465207061796c6f6164' 1676 ] 1678 Figure 3: Payload Block (CBOR Diagnostic Notation) 1680 The CBOR encoding of the payload block is 0x8501010000582052656164792 1681 047656e657261746520612033322062797465207061796c6f6164. 1683 A.1.1.3. Bundle CBOR Representation 1685 A BPv7 bundle is represented as an indefinite-length array consisting 1686 of the blocks comprising the bundle, with a terminator character at 1687 the end. 1689 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1690 28202018202820201820018281a000f42408501010000582052656164792047656e65 1691 7261746520612033322062797465207061796c6f6164ff. 1693 A.1.2. Security Operation Overview 1695 This example adds a BIB to the bundle using the BIB-HMAC-SHA2 1696 security context to provide an integrity mechanism over the payload 1697 block. 1699 The following diagram shows the resulting bundle after the BIB is 1700 added. 1702 Block Block Block 1703 in Bundle Type Number 1704 +========================================+=======+========+ 1705 | Primary Block | N/A | 0 | 1706 +----------------------------------------+-------+--------+ 1707 | Bundle Integrity Block | 11 | 2 | 1708 | OP(bib-integrity, target=1) | | | 1709 +----------------------------------------+-------+--------+ 1710 | Payload Block | 1 | 1 | 1711 +----------------------------------------+-------+--------+ 1713 Figure 4: Example 1 Resulting Bundle 1715 A.1.3. Bundle Integrity Block 1717 In this example, a BIB is used to carry an integrity signature over 1718 the payload block. 1720 A.1.3.1. Configuration, Parameters, and Results 1722 For this example, the following configuration and security parameters 1723 are used to generate the security results indicated. 1725 This BIB has a single target and includes a single security result: 1726 the calculated signature over the payload block. 1728 Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 1729 SHA Variant : HMAC 512/512 1730 Scope Flags : 0x00 1731 Payload Data: h'52656164792047656e65726174652061 1732 2033322062797465207061796c6f6164' 1733 Signature : h'0654d65992803252210e377d66d0a8dc 1734 18a1e8a392269125ae9ac198a9a598be 1735 4b83d5daa8be2f2d16769ec1c30cfc34 1736 8e2205fba4b3be2b219074fdd5ea8ef0' 1738 Figure 5: Example 1: Configuration, Parameters, and Results 1740 A.1.3.2. Abstract Security Block 1742 The abstract security block structure of the BIB's block-type- 1743 specific-data field for this application is as follows. 1745 [1], / Security Target - Payload block / 1746 1, / Security Context ID - BIB-HMAC-SHA2 / 1747 1, / Security Context Flags - Parameters Present / 1748 [2,[2, 1]], / Security Source - ipn:2.1 / 1749 [ / Security Parameters - 2 Parameters / 1750 [1, 7], / SHA Variant - HMAC 512/512 / 1751 [3, 0x00] / Scope Flags - No Additional Scope / 1752 ], 1753 [ / Security Results: 1 Result / 1754 [1, h'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b 1755 e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0'] 1756 ] 1758 Figure 6: Example 1: BIB Abstract Security Block (CBOR Diagnostic 1759 Notation) 1761 The CBOR encoding of the BIB block-type-specific-data field (the 1762 abstract security block) is 0x810101018202820201828201078203008182015 1763 8400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b 1764 83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0. 1766 A.1.3.3. Representations 1768 The BIB wrapping this abstract security block is as follows. 1770 [ 1771 11, / type code / 1772 2, / block number / 1773 0, / flags / 1774 0, / CRC type / 1775 h'8101010182028202018282010782030081820158400654d65992803252210e377d66 1776 d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34 1777 8e2205fba4b3be2b219074fdd5ea8ef0', 1778 ] 1780 Figure 7: Example 1: BIB (CBOR Diagnostic Notation) 1782 The CBOR encoding of the BIB block is 0x850b0200005855810101018202820 1783 2018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392 1784 269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2 1785 b219074fdd5ea8ef0. 1787 A.1.4. Final Bundle 1789 The CBOR encoding of the full output bundle, with the BIB: 0x9f880700 1790 00820282010282028202018202820201820018281a000f4240850b020000585581010 1791 10182028202018282010782030081820158400654d65992803252210e377d66d0a8dc 1792 18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e220 1793 5fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e6572617465 1794 20612033322062797465207061796c6f6164ff. 1796 A.2. Example 2: Simple Confidentiality with Key Wrap 1798 This example shows the addition of a BCB to a sample bundle to 1799 provide confidentiality for the payload block. AES key wrap is used 1800 to transmit the symmetric key used to generate the security results 1801 for this service. 1803 A.2.1. Original Bundle 1805 The following diagram shows the original bundle before the BCB has 1806 been added. 1808 Block Block Block 1809 in Bundle Type Number 1810 +========================================+=======+========+ 1811 | Primary Block | N/A | 0 | 1812 +----------------------------------------+-------+--------+ 1813 | Payload Block | 1 | 1 | 1814 +----------------------------------------+-------+--------+ 1816 Figure 8: Example 2 Original Bundle 1818 A.2.1.1. Primary Block 1820 The primary block used in this example is identical to the primary 1821 block presented in Example 1 Appendix A.1.1.1. 1823 In summary, the CBOR encoding of the primary block is 1824 0x88070000820282010282028202018202820201820018281a000f4240. 1826 A.2.1.2. Payload Block 1828 The payload block used in this example is identical to the payload 1829 block presented in Example 1 Appendix A.1.1.2. 1831 In summary, the CBOR encoding of the payload block is 0x8501010000582 1832 052656164792047656e657261746520612033322062797465207061796c6f6164. 1834 A.2.1.3. Bundle CBOR Representation 1836 A BPv7 bundle is represented as an indefinite-length array consisting 1837 of the blocks comprising the bundle, with a terminator character at 1838 the end. 1840 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1841 28202018202820201820018281a000f42408501010000582052656164792047656e65 1842 7261746520612033322062797465207061796c6f6164ff. 1844 A.2.2. Security Operation Overview 1846 This example adds a BCB using the BCB-AES-GCM security context using 1847 AES key wrap to provide a confidentiality mechanism over the payload 1848 block and transmit the symmetric key. 1850 The following diagram shows the resulting bundle after the BCB is 1851 added. 1853 Block Block Block 1854 in Bundle Type Number 1855 +========================================+=======+========+ 1856 | Primary Block | N/A | 0 | 1857 +----------------------------------------+-------+--------+ 1858 | Bundle Confidentiality Block | 12 | 2 | 1859 | OP(bcb-confidentiality, target=1) | | | 1860 +----------------------------------------+-------+--------+ 1861 | Payload Block (Encrypted) | 1 | 1 | 1862 +----------------------------------------+-------+--------+ 1864 Figure 9: Example 2 Resulting Bundle 1866 A.2.3. Bundle Confidentiality Block 1868 In this example, a BCB is used to encrypt the payload block and uses 1869 AES key wrap to transmit the symmetric key. 1871 A.2.3.1. Configuration, Parameters, and Results 1873 For this example, the following configuration and security parameters 1874 are used to generate the security results indicated. 1876 This BCB has a single target, the payload block. Three security 1877 results are generated: cipher text which replaces the plain text 1878 block-type-specific data to encrypt the payload block, an 1879 authentication tag, and the AES wrapped key. 1881 Content Encryption 1882 Key: h'71776572747975696f70617364666768' 1883 Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' 1884 IV: h'5477656c7665313231323132' 1885 AES Variant: A128GCM 1886 AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 1887 96fabf34d7fae700' 1888 Scope Flags: 0x00 1889 Payload Data: h'52656164792047656e65726174652061 1890 2033322062797465207061796c6f6164' 1891 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 1892 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 1893 a563e32648b700c2784e26a990d91f9d' 1895 Figure 10: Example 2: Configuration, Parameters, and Results 1897 A.2.3.2. Abstract Security Block 1899 The abstract security block structure of the BCB's block-type- 1900 specific-data field for this application is as follows. 1902 [1], / Security Target - Payload block / 1903 2, / Security Context ID - BCB-AES-GCM / 1904 1, / Security Context Flags - Parameters Present / 1905 [2,[2, 1]], / Security Source - ipn:2.1 / 1906 [ / Security Parameters - 4 Parameters / 1907 [1, h'5477656c7665313231323132'], / Initialization Vector / 1908 [2, 1], / AES Variant - A128GCM / 1909 [3, h'69c411276fecddc4780df42c8a / AES wrapped key / 1910 2af89296fabf34d7fae700'], 1911 [4, 0x00] / Scope Flags - No extra scope/ 1912 ], 1913 [ / Security Results: 1 Result / 1914 [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / 1915 ] 1917 Figure 11: Example 2: BCB Abstract Security Block (CBOR 1918 Diagnostic Notation) 1920 The CBOR encoding of the BCB block-type-specific-data field (the 1921 abstract security block) is 0x8101020182028202018482014c5477656c76653 1922 132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa 1923 e70082040081820150da08f4d8936024ad7c6b3b800e73dd97. 1925 A.2.3.3. Representations 1927 The BCB wrapping this abstract security block is as follows. 1929 [ 1930 12, / type code / 1931 2, / block number / 1932 1, / flags - block must be replicated in every fragment / 1933 0, / CRC type / 1934 h'8101020182028202018482014c5477656c766531323132313282020182035818 1935 69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da 1936 08f4d8936024ad7c6b3b800e73dd97' 1937 ] 1939 Figure 12: Example 2: BCB (CBOR Diagnostic Notation) 1941 The CBOR encoding of the BCB block is 0x850c020100584f810102018202820 1942 2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d 1943 f42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e7 1944 3dd97. 1946 A.2.4. Final Bundle 1948 The CBOR encoding of the full output bundle, with the BCB: 0x9f880700 1949 00820282010282028202018202820201820018281a000f4240850c020100584f81010 1950 20182028202018482014c5477656c76653132313231328202018203581869c411276f 1951 ecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7 1952 c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e326 1953 48b700c2784e26a990d91f9dff. 1955 A.3. Example 3: Security Blocks from Multiple Sources 1957 This example shows the addition of a BIB and BCB to a sample bundle. 1958 These two security blocks are added by two different nodes. The BCB 1959 is added by the source endpoint and the BIB is added by a forwarding 1960 node. 1962 The resulting bundle contains a BCB to encrypt the Payload Block and 1963 a BIB to provide integrity to the Primary and Bundle Age Block. 1965 A.3.1. Original Bundle 1967 The following diagram shows the original bundle before the security 1968 blocks have been added. 1970 Block Block Block 1971 in Bundle Type Number 1972 +========================================+=======+========+ 1973 | Primary Block | N/A | 0 | 1974 +----------------------------------------+-------+--------+ 1975 | Extension Block: Bundle Age Block | 7 | 2 | 1976 +----------------------------------------+-------+--------+ 1977 | Payload Block | 1 | 1 | 1978 +----------------------------------------+-------+--------+ 1980 Figure 13: Example 3 Original Bundle 1982 A.3.1.1. Primary Block 1984 The primary block used in this example is identical to the primary 1985 block presented in Example 1 Appendix A.1.1.1. 1987 In summary, the CBOR encoding of the primary block is 1988 0x88070000820282010282028202018202820201820018281a000f4240. 1990 A.3.1.2. Bundle Age Block 1992 A bundle age block is added to the bundle to help other nodes in the 1993 network determine the age of the bundle. The use of this block is as 1994 recommended because the bundle source does not have an accurate clock 1995 (as indicated by the DTN time of 0). 1997 Because this block is specified at the time the bundle is being 1998 forwarded, the bundle age represents the time that has elapsed from 1999 the time the bundle was created to the time it is being prepared for 2000 forwarding. In this case, the value is given as 300 milliseconds. 2002 The bundle age extension block is provided as follows. 2004 [ 2005 7, / type code: Bundle Age block / 2006 2, / block number / 2007 0, / block processing flags / 2008 0, / CRC Type / 2009 <<300>> / type-specific-data: age / 2010 ] 2012 Figure 14: Bundle Age Block (CBOR Diagnostic Notation) 2014 The CBOR encoding of the bundle age block is 0x85070200004319012c. 2016 A.3.1.3. Payload Block 2018 The payload block used in this example is identical to the payload 2019 block presented in Example 1 Appendix A.1.1.2. 2021 In summary, the CBOR encoding of the payload block is 0x8501010000582 2022 052656164792047656e657261746520612033322062797465207061796c6f6164. 2024 A.3.1.4. Bundle CBOR Representation 2026 A BPv7 bundle is represented as an indefinite-length array consisting 2027 of the blocks comprising the bundle, with a terminator character at 2028 the end. 2030 The CBOR encoding of the original bundle is 0x9f880700008202820102820 2031 28202018202820201820018281a000f424085070200004319012c8501010000582052 2032 656164792047656e657261746520612033322062797465207061796c6f6164ff. 2034 A.3.2. Security Operation Overview 2036 This example provides: 2038 a BIB with the BIB-HMAC-SHA2 security context to provide an 2039 integrity mechanism over the primary block and bundle age block. 2041 a BCB with the BCB-AES-GCM security context to provide a 2042 confidentiality mechanism over the payload block. 2044 The following diagram shows the resulting bundle after the security 2045 blocks are added. 2047 Block Block Block 2048 in Bundle Type Number 2049 +========================================+=======+========+ 2050 | Primary Block | N/A | 0 | 2051 +----------------------------------------+-------+--------+ 2052 | Bundle Integrity Block | 11 | 3 | 2053 | OP(bib-integrity, targets=0, 2) | | | 2054 +----------------------------------------+-------+--------+ 2055 | Bundle Confidentiality Block | 12 | 4 | 2056 | OP(bcb-confidentiality, target=1) | | | 2057 +----------------------------------------+-------+--------+ 2058 | Extension Block: Bundle Age Block | 7 | 2 | 2059 +----------------------------------------+-------+--------+ 2060 | Payload Block (Encrypted) | 1 | 1 | 2061 +----------------------------------------+-------+--------+ 2063 Figure 15: Example 3 Resulting Bundle 2065 A.3.3. Bundle Integrity Block 2067 In this example, a BIB is used to carry an integrity signature over 2068 the bundle age block and an additional signature over the payload 2069 block. The BIB is added by a waypoint node, ipn:3.0. 2071 A.3.3.1. Configuration, Parameters, and Results 2073 For this example, the following configuration and security parameters 2074 are used to generate the security results indicated. 2076 This BIB has two security targets and includes two security results, 2077 holding the calculated signatures over the bundle age block and 2078 primary block. 2080 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2081 SHA Variant: HMAC 256/256 2082 Scope Flags: 0x00 2083 Primary Block Data: h'88070000820282010282028202018202 2084 820201820018281a000f4240' 2085 Bundle Age Block 2086 Data: h'85070200004319012c' 2087 Primary Block 2088 Signature: h'8e059b8e71f7218264185a666bf3e453 2089 076f2b883f4dce9b3cdb6464ed0dcf0f' 2090 Bundle Age Block 2091 Signature: h'72dee8eba049a22978e84a95d0496466 2092 8eb131b1ca4800c114206d70d9065c80' 2094 Figure 16: Example 3: Configuration, Parameters, and Results for 2095 the BIB 2097 A.3.3.2. Abstract Security Block 2099 The abstract security block structure of the BIB's block-type- 2100 specific-data field for this application is as follows. 2102 [0, 2], / Security Targets / 2103 1, / Security Context ID - BIB-HMAC-SHA2 / 2104 1, / Security Context Flags - Parameters Present / 2105 [2,[3, 0]], / Security Source - ipn:3.0 / 2106 [ / Security Parameters - 2 Parameters / 2107 [1, 5], / SHA Variant - HMAC 256/256 / 2108 [3, 0x00] / Scope Flags - No Additional Scope / 2109 ], 2110 [ / Security Results: 2 Results / 2111 [1, h'8e059b8e71f7218264185a666bf3e453 2112 076f2b883f4dce9b3cdb6464ed0dcf0f'], / Primary Block / 2113 [1, h'72dee8eba049a22978e84a95d0496466 2114 8eb131b1ca4800c114206d70d9065c80'] / Bundle Age Block / 2115 ] 2117 Figure 17: Example 3: BIB Abstract Security Block (CBOR 2118 Diagnostic Notation) 2120 The CBOR encoding of the BIB block-type-specific-data field (the 2121 abstract security block) is 0x820002010182028203008282010582030082820 2122 158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f 2123 8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065 2124 c80. 2126 A.3.3.3. Representations 2128 The BIB wrapping this abstract security block is as follows. 2130 [ 2131 11, / type code / 2132 3, / block number / 2133 0, / flags / 2134 0, / CRC type / 2135 h'820002010182028203008282010582030082820158208e059b8e71f721826418 2136 5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049 2137 a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80', 2138 ] 2140 Figure 18: Example 3: BIB (CBOR Diagnostic Notation) 2142 The CBOR encoding of the BIB block is 0x850b030000585a820002010182028 2143 203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b88 2144 3f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb13 2145 1b1ca4800c114206d70d9065c80. 2147 A.3.4. Bundle Confidentiality Block 2149 In this example, a BCB is used encrypt the payload block. The BCB is 2150 added by the bundle source node, ipn:2.1. 2152 A.3.4.1. Configuration, Parameters, and Results 2154 For this example, the following configuration and security parameters 2155 are used to generate the security results indicated. 2157 This BCB has a single target, the payload block. Two security 2158 results are generated: cipher text which replaces the plain text 2159 block-type-specific data to encrypt the payload block, and an 2160 authentication tag. 2162 Content Encryption 2163 Key: h'71776572747975696f70617364666768' 2164 IV: h'5477656c7665313231323132' 2165 AES Variant: A128GCM 2166 Scope Flags: 0x00 2167 Payload Data: h'52656164792047656e65726174652061 2168 2033322062797465207061796c6f6164' 2169 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 2170 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 2171 a563e32648b700c2784e26a990d91f9d' 2173 Figure 19: Example 3: Configuration, Parameters, and Results for 2174 the BCB 2176 A.3.4.2. Abstract Security Block 2178 The abstract security block structure of the BCB's block-type- 2179 specific-data field for this application is as follows. 2181 [1], / Security Target - Payload block / 2182 2, / Security Context ID - BCB-AES-GCM / 2183 1, / Security Context Flags - Parameters Present / 2184 [2,[2, 1]], / Security Source - ipn:2.1 / 2185 [ / Security Parameters - 3 Parameters / 2186 [1, h'5477656c7665313231323132'], / Initialization Vector / 2187 [2, 1], / AES Variant - AES 128 / 2188 [4, 0x00] / Scope Flags - No Additional Scope / 2189 ], 2190 [ / Security Results: 1 Result / 2191 [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / 2192 ] 2194 Figure 20: Example 3: BCB Abstract Security Block (CBOR 2195 Diagnostic Notation) 2197 The CBOR encoding of the BCB block-type-specific-data field (the 2198 abstract security block) is 0x8101020182028202018382014c5477656c76653 2199 1323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97. 2201 A.3.4.3. Representations 2203 The BCB wrapping this abstract security block is as follows. 2205 [ 2206 12, / type code / 2207 4, / block number / 2208 1, / flags - block must be replicated in every fragment / 2209 0, / CRC type / 2210 h'8101020182028202018382014c5477656c766531323132313282020182040081 2211 820150da08f4d8936024ad7c6b3b800e73dd97', 2212 ] 2214 Figure 21: Example 3: BCB (CBOR Diagnostic Notation) 2216 The CBOR encoding of the BCB block is 0x850c0401005833810102018202820 2217 2018382014c5477656c766531323132313282020182040081820150da08f4d8936024 2218 ad7c6b3b800e73dd97. 2220 A.3.5. Final Bundle 2222 The CBOR encoding of the full output bundle, with the BIB and BCB 2223 added is: 0x9f88070000820282010282028202018202820201820018281a000f424 2224 0850b030000585a820002010182028203008282010582030082820158208e059b8e71 2225 f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8e 2226 ba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058 2227 338101020182028202018382014c5477656c766531323132313282020182040081820 2228 150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a 2229 09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff. 2231 A.4. Example 4: Security Blocks with Full Scope 2233 This example shows the addition of a BIB and BCB to a sample bundle. 2234 A BIB is added to provide integrity over the payload block and a BCB 2235 is added for confidentiality over the payload and BIB. 2237 The integrity scope and additional authentication data will bind the 2238 primary block, target header, and the security header. 2240 A.4.1. Original Bundle 2242 The following diagram shows the original bundle before the security 2243 blocks have been added. 2245 Block Block Block 2246 in Bundle Type Number 2247 +========================================+=======+========+ 2248 | Primary Block | N/A | 0 | 2249 +----------------------------------------+-------+--------+ 2250 | Payload Block | 1 | 1 | 2251 +----------------------------------------+-------+--------+ 2253 Figure 22: Example 4 Original Bundle 2255 A.4.1.1. Primary Block 2257 The primary block used in this example is identical to the primary 2258 block presented in Example 1 Appendix A.1.1.1. 2260 In summary, the CBOR encoding of the primary block is 2261 0x88070000820282010282028202018202820201820018281a000f4240. 2263 A.4.1.2. Payload Block 2265 The payload block used in this example is identical to the payload 2266 block presented in Example 1 Appendix A.1.1.2. 2268 In summary, the CBOR encoding of the payload block is 0x8501010000582 2269 052656164792047656e657261746520612033322062797465207061796c6f6164. 2271 A.4.1.3. Bundle CBOR Representation 2273 A BPv7 bundle is represented as an indefinite-length array consisting 2274 of the blocks comprising the bundle, with a terminator character at 2275 the end. 2277 The CBOR encoding of the original bundle is 0x9f880700008202820102820 2278 28202018202820201820018281a000f42408501010000582052656164792047656e65 2279 7261746520612033322062797465207061796c6f6164ff. 2281 A.4.2. Security Operation Overview 2283 This example provides: 2285 a BIB with the BIB-HMAC-SHA2 security context to provide an 2286 integrity mechanism over the payload block. 2288 a BCB with the BCB-AES-GCM security context to provide a 2289 confidentiality mechanism over the payload block and BIB. 2291 The following diagram shows the resulting bundle after the security 2292 blocks are added. 2294 Block Block Block 2295 in Bundle Type Number 2296 +========================================+=======+========+ 2297 | Primary Block | N/A | 0 | 2298 +----------------------------------------+-------+--------+ 2299 | Bundle Integrity Block (Encrypted) | 11 | 3 | 2300 | OP(bib-integrity, target=1) | | | 2301 +----------------------------------------+-------+--------+ 2302 | Bundle Confidentiality Block | 12 | 2 | 2303 | OP(bcb-confidentiality, targets=1, 3) | | | 2304 +----------------------------------------+-------+--------+ 2305 | Payload Block (Encrypted) | 1 | 1 | 2306 +----------------------------------------+-------+--------+ 2308 Figure 23: Example 4 Resulting Bundle 2310 A.4.3. Bundle Integrity Block 2312 In this example, a BIB is used to carry an integrity signature over 2313 the payload block. The IPPT contains the payload block block-type- 2314 specific data, primary block data, the payload block header, and the 2315 BIB header. That is, all additional headers are included in the 2316 IPPT. 2318 A.4.3.1. Configuration, Parameters, and Results 2320 For this example, the following configuration and security parameters 2321 are used to generate the security results indicated. 2323 This BIB has a single target and includes a single security result: 2324 the calculated signature over the Payload block. 2326 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2327 SHA Variant: HMAC 384/384 2328 Scope Flags: 0x07 (all additional headers) 2329 Primary Block Data: h'88070000820282010282028202018202 2330 820201820018281a000f4240 2331 Payload Data: h'52656164792047656e65726174652061 2332 2033322062797465207061796c6f6164' 2333 Payload Header: h'85010100005820' 2334 BIB Header: h'850b0300005845' 2335 Payload Signature: h'07c84d929f83bee4690130729d77a1bd 2336 da9611cd6598e73d0659073ea74e8c27 2337 523b02193cb8ba64be58dbc556887aca 2339 Figure 24: Example 4: Configuration, Parameters, and Results for 2340 the BIB 2342 A.4.3.2. Abstract Security Block 2344 The abstract security block structure of the BIB's block-type- 2345 specific-data field for this application is as follows. 2347 [1], / Security Target - Payload block / 2348 1, / Security Context ID - BIB-HMAC-SHA2 / 2349 1, / Security Context Flags - Parameters Present / 2350 [2,[2, 1]], / Security Source - ipn:2.1 / 2351 [ / Security Parameters - 2 Parameters / 2352 [1, 6], / SHA Variant - HMAC 384/384 / 2353 [3, 0x07] / Scope Flags - All additional headers in the SHA Hash / 2354 ], 2355 [ / Security Results: 1 Result / 2356 [1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d 2357 0659073ea74e8c27523b02193cb8ba64be58dbc556887aca'] 2358 ] 2360 Figure 25: Example 4: BIB Abstract Security Block (CBOR 2361 Diagnostic Notation) 2363 The CBOR encoding of the BIB block-type-specific-data field (the 2364 abstract security block) is 0x810101018202820201828201068203078182015 2365 83007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c2752 2366 3b02193cb8ba64be58dbc556887aca. 2368 A.4.3.3. Representations 2370 The BIB wrapping this abstract security block is as follows. 2372 [ 2373 11, / type code / 2374 3, / block number / 2375 0, / flags / 2376 0, / CRC type / 2377 h'81010101820282020182820106820307818201583007c84d929f83bee4690130 2378 729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db 2379 c556887aca', 2380 ] 2382 Figure 26: Example 4: BIB (CBOR Diagnostic Notation) 2384 The CBOR encoding of the BIB block is 0x850b0300005845810101018202820 2385 20182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd65 2386 98e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca. 2388 A.4.4. Bundle Confidentiality Block 2390 In this example, a BCB is used encrypt the payload block and the BIB 2391 that provides integrity over the payload. 2393 A.4.4.1. Configuration, Parameters, and Results 2395 For this example, the following configuration and security parameters 2396 are used to generate the security results indicated. 2398 This BCB has two targets: the payload block and BIB. Four security 2399 results are generated: cipher text which replaces the plain text 2400 block-type-specific data of the payload block, cipher text to encrypt 2401 the BIB, and authentication tags for both the payload block and BIB. 2403 Key: h'71776572747975696f70617364666768 2404 71776572747975696f70617364666768' 2405 IV: h'5477656c7665313231323132' 2406 AES Variant: A256GCM 2407 Scope Flags: 0x07 (All additional headers) 2408 Payload Data: h'52656164792047656e65726174652061 2409 2033322062797465207061796c6f6164' 2410 BIB Data: h'81010101820282020182820106820307 2411 818201583007c84d929f83bee4690130 2412 729d77a1bdda9611cd6598e73d065907 2413 3ea74e8c27523b02193cb8ba64be58db 2414 c556887aca 2415 BIB 2416 Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e' 2417 Payload Block 2418 Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff' 2419 Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 2420 319bb227706000abc8fcac3b9bb9c87e' 2421 BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 2422 902a815f221ebc837a134efc13bfa82a 2423 2d5d317747da3eb54acef4ca839bd961 2424 487284404259b60be12b8aed2f3e8a36 2425 2836529f66' 2427 Figure 27: Example 4: Configuration, Parameters, and Results for 2428 the BCB 2430 A.4.4.2. Abstract Security Block 2432 The abstract security block structure of the BCB's block-type- 2433 specific-data field for this application is as follows. 2435 [3, 1], / Security Targets / 2436 2, / Security Context ID - BCB-AES-GCM / 2437 1, / Security Context Flags - Parameters Present / 2438 [2,[2, 1]], / Security Source - ipn:2.1 / 2439 [ / Security Parameters - 3 Parameters / 2440 [1, h'5477656c7665313231323132'], / Initialization Vector / 2441 [2, 3], / AES Variant - AES 256 / 2442 [4, 0x07] / Scope Flags - All headers in SHA hash / 2443 ], 2444 [ / Security Results: 2 Results / 2445 [1, h'c95ed4534769b046d716e1cdfd00830e'], / BIB Auth. Tag / 2446 [1, h'0e365c700e4bb19c0d991faff5345aff'] / Payload Auth. Tag / 2447 ] 2449 Figure 28: Example 4: BCB Abstract Security Block (CBOR 2450 Diagnostic Notation) 2452 The CBOR encoding of the BCB block-type-specific-data field (the 2453 abstract security block) is 0x820301020182028202018382014c5477656c766 2454 531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201 2455 500e365c700e4bb19c0d991faff5345aff. 2457 A.4.4.3. Representations 2459 The BCB wrapping this abstract security block is as follows. 2461 [ 2462 12, / type code / 2463 2, / block number / 2464 1, / flags - block must be replicated in every fragment / 2465 0, / CRC type / 2466 h'820301020182028202018382014c5477656c7665313231323132820203820407 2467 82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d 2468 991faff5345aff', 2469 ] 2471 Figure 29: Example 4: BCB (CBOR Diagnostic Notation) 2473 The CBOR encoding of the BCB block is 0x850c0201005847820301020182028 2474 202018382014c5477656c766531323132313282020382040782820150c95ed4534769 2475 b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. 2477 A.4.5. Final Bundle 2479 The CBOR encoding of the full output bundle, with the security blocks 2480 added and payload block and BIB encrypted is: 0x9f8807000082028201028 2481 2028202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb9 2482 4d952175167df0902a815f221ebc837a134efc13bfa82a2d5d317747da3eb54acef4c 2483 a839bd961487284404259b60be12b8aed2f3e8a362836529f66 850c0201005847820 2484 301020182028202018382014c5477656c766531323132313282020382040782820150 2485 c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345af 2486 f8501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac 2487 3b9bb9c87eff. 2489 Appendix B. CDDL Expression 2491 For informational purposes, Brian Sipos has kindly provided an 2492 expression of the IPPT and AAD structures using the Concise Data 2493 Definition Language (CDDL). That CDDL expression is presented below. 2495 Note that wherever the CDDL expression is in disagreement with the 2496 textual representation of the security block specification presented 2497 in earlier sections of this document, the textual representation 2498 rules. 2500 Note that the structure of BP bundles and BPSec security blocks are 2501 provided by other specifications and this section only provides the 2502 CDDL expression for structures uniquely defined in this 2503 specification. Items related to elements of a bundle, such as 2504 "primary-block", are defined in Appendix B of the Bundle Protocol 2505 Version 7 [I-D.ietf-dtn-bpbis]. 2507 Note that the CDDL itself does not have the concept of unadorned CBOR 2508 sequences as a top-level subject of a specification. The current 2509 best practice, as documented in Section 4.1 of [RFC8742], requires 2510 representing the sequence as an array with a comment in the CDDL 2511 noting that the array represents a CBOR sequence. 2513 start = scope / AAD-list / IPPT-list ; satisfy CDDL decoders 2515 scope = uint .bits scope-flags 2516 scope-flags = &( 2517 has-primary-ctx: 0, 2518 has-target-ctx: 1, 2519 has-security-ctx: 2, 2520 ) 2522 ; Encoded as a CBOR sequence 2523 AAD-list = [ 2524 AAD-structure 2525 ] 2527 ; Encoded as a CBOR sequence 2528 IPPT-list = [ 2529 AAD-structure, 2530 target-btsd: bstr ; block-type-specific-data of the target block. 2531 ] 2533 AAD-structure = ( 2534 scope, 2535 ? primary-block, ; present if has-primary-ctx flag set 2536 ? block-metadata, ; present if has-target-ctx flag set 2537 ? block-metadata, ; present if has-security-ctx flag set 2538 ) 2540 ; Selected fields of a canonical block 2541 block-metadata = ( 2542 block-type-code: uint, 2543 block-number: uint, 2544 block-control-flags, 2545 ) 2547 Figure 30: IPPT and AAD Expressions 2549 Appendix C. Acknowledgements 2551 Amy Alford of the Johns Hopkins University Applied Physics Laboratory 2552 contributed useful review and analysis of these security contexts. 2554 Authors' Addresses 2555 Edward J. Birrane, III 2556 The Johns Hopkins University Applied Physics Laboratory 2557 11100 Johns Hopkins Rd. 2558 Laurel, MD 20723 2559 United States of America 2561 Phone: +1 443 778 7423 2562 Email: Edward.Birrane@jhuapl.edu 2564 Alex White 2565 The Johns Hopkins University Applied Physics Laboratory 2566 11100 Johns Hopkins Rd. 2567 Laurel, MD 20723 2568 United States of America 2570 Phone: +1 443 778 0845 2571 Email: Alex.White@jhuapl.edu 2573 Sarah Heiner 2574 The Johns Hopkins University Applied Physics Laboratory 2575 11100 Johns Hopkins Rd. 2576 Laurel, MD 20723 2577 United States of America 2579 Phone: +1 240 592 3704 2580 Email: Sarah.Heiner@jhuapl.edu