idnits 2.17.1 draft-ietf-dtn-bpsec-default-sc-10.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 (July 12, 2021) is 1019 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 2088 -- Looks like a reference, but probably isn't: '40' on line 1631 -- Looks like a reference, but probably isn't: '1' on line 2421 -- Looks like a reference, but probably isn't: '7' on line 1736 -- Looks like a reference, but probably isn't: '3' on line 2427 == Missing Reference: '0x00' is mentioned on line 2174, but not defined -- Looks like a reference, but probably isn't: '2' on line 2427 -- Looks like a reference, but probably isn't: '4' on line 2428 -- Looks like a reference, but probably isn't: '5' on line 2093 -- Looks like a reference, but probably isn't: '6' on line 2338 == Missing Reference: '0x07' is mentioned on line 2428, 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. Birrane 3 Internet-Draft A. White 4 Intended status: Standards Track S. Heiner 5 Expires: January 13, 2022 JHU/APL 6 July 12, 2021 8 BPSec Default Security Contexts 9 draft-ietf-dtn-bpsec-default-sc-10 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 January 13, 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 4 57 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 7 61 3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 7 62 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 8 63 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 8 64 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 9 66 3.6. Security Processing Considerations . . . . . . . . . . . 10 67 3.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 10 68 3.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.8.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 11 70 3.8.2. Keyed Hash Verification . . . . . . . . . . . . . . . 12 71 4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 13 72 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 16 76 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 16 77 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 17 78 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 17 79 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 18 80 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 19 82 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 20 83 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 20 84 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 21 85 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 22 86 4.7.1. Cipher text related calculations . . . . . . . . . . 22 87 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 23 88 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 24 89 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 24 90 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . 30 97 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 30 98 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 31 99 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 32 101 6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 33 102 7. Normative References . . . . . . . . . . . . . . . . . . . . 33 103 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35 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 . . . . . 40 110 A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 40 111 A.2.2. Security Operation Overview . . . . . . . . . . . . . 41 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 . . . . . . . . . . . . . . . 46 118 A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 48 119 A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 49 120 A.4. Example 4: Security Blocks with Full Scope . . . . . . . 50 121 A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 50 122 A.4.2. Security Operation Overview . . . . . . . . . . . . . 51 123 A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 51 124 A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 53 125 A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 55 126 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 55 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 129 1. Introduction 131 The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] 132 specification provides inter-bundle integrity and confidentiality 133 operations for networks deploying the Bundle Protocol (BP) 134 [I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry 135 security information produced under the auspices of some security 136 context. 138 This document defines two security contexts (one for an integrity 139 service and one for a confidentiality service) for populating BPSec 140 Block Integrity Blocks (BIBs) and Block Confidentiality Blocks 141 (BCBs). This document assumes familiarity with the concepts and 142 terminology associated with BP and BPSec, as these security contexts 143 are used with BPSec security blocks and other BP blocks carried 144 within BP bundles. 146 These contexts generate information that MUST be encoded using the 147 CBOR specification documented in [RFC8949]. 149 2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. Integrity Security Context BIB-HMAC-SHA2 159 3.1. Overview 161 The BIB-HMAC-SHA2 security context provides a keyed-hash Message 162 Authentication Code (MAC) over a set of plain text information. This 163 context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS] 164 combined with the HMAC keyed hash discussed in [RFC2104]. The 165 combination of HMAC and SHA-2 as the integrity mechanism for this 166 security context was selected for two reasons: 168 1. The use of symmetric keys allows this security context to be used 169 in places where an asymmetric-key infrastructure (such as a 170 public key infrastructure) might be impractical. 172 2. The combination HMAC-SHA2 represents a well-supported and well- 173 understood integrity mechanism with multiple implementations 174 available. 176 BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the 177 supported length of the SHA-2 hash value. These variants correspond 178 to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in 179 [RFC8152] Table 7: HMAC Algorithm Values. The selection of which 180 variant is used by this context is provided as a security context 181 parameter. 183 The output of the HMAC MUST be equal to the size of the SHA2 hashing 184 function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits 185 for SHA-512. 187 The BIB-HMAC-SHA2 security context MUST have the security context 188 identifier specified in Section 5.1. 190 3.2. Scope 192 The scope of BIB-HMAC-SHA2 is the set of information used to produce 193 the plain text over which a keyed hash is calculated. This plain 194 text is termed the "Integrity Protected Plain Text" (IPPT). The 195 content of the IPPT is constructed as the concatenation of 196 information whose integrity is being preserved from the BIB-HMAC-SHA2 197 security source to its security acceptor. There are five types of 198 information that can be used in the generation of the IPPT, based on 199 how broadly the concept of integrity is being applied. These five 200 types of information, whether they are required, and why they are 201 important for integrity, are discussed as follows. 203 Security target contents 204 The contents of the block-type-specific data field of the 205 security target MUST be included in the IPPT. Including this 206 information protects the security target data and is considered 207 the minimal, required set of information for an integrity service 208 on the security target. 210 IPPT Scope 211 The determination of which optional types of information were 212 used when constructing the IPPT MUST, itself, always be included 213 in the IPPT. Including this information ensures that the scope 214 of the IPPT construction at a security source matches the scope 215 of the IPPT construction at security verifiers and security 216 acceptors. 218 Primary block 219 The primary block identifies a bundle and, once created, the 220 contents of this block are immutable. Changes to the primary 221 block associated with the security target indicate that the 222 security target (and BIB) might no longer be in the correct 223 bundle. 225 For example, if a security target and associated BIB are copied 226 from one bundle to another bundle, the BIB might still contain a 227 verifiable signature for the security target unless information 228 associated with the bundle primary block is included in the keyed 229 hash carried by the BIB. 231 Including this information in the IPPT protects the integrity of 232 the association of the security target with a specific bundle. 234 Security target other fields 235 The other fields of the security target include block 236 identification and processing information. Changing this 237 information changes how the security target is treated by nodes 238 in the network even when the "user data" of the security target 239 are otherwise unchanged. 241 For example, if the block processing control flags of a security 242 target are different at a security verifier than they were 243 originally set at the security source then the policy for 244 handling the security target has been modified. 246 Including this information in the IPPT protects the integrity of 247 the policy and identification of the security target data. 249 BIB other fields 250 The other fields of the BIB include block identification and 251 processing information. Changing this information changes how 252 the BIB is treated by nodes in the network, even when other 253 aspects of the BIB are unchanged. 255 For example, if the block processing control flags of the BIB are 256 different at a security verifier than they were originally set at 257 the security source, then the policy for handling the BIB has 258 been modified. 260 Including this information in the IPPT protects the integrity of 261 the policy and identification of the security service in the 262 bundle. 264 NOTE: The security context identifier and security context 265 parameters of the security block are not included in the IPPT 266 because these parameters, by definition, are required to verify 267 or accept the security service. Successful verification at 268 security verifiers and security acceptors implies that these 269 parameters were unchanged since being specified at the security 270 source. This is the case because keys cannot be re-used across 271 security contexts, and because the integrity scope flags used to 272 define the IPPT are included in the IPPT itself. 274 The scope of the BIB-HMAC-SHA2 security context is configured using 275 an optional security context parameter. 277 3.3. Parameters 279 BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, 280 communicate key information, and define the scope of the IPPT. 282 3.3.1. SHA Variant 284 This optional parameter identifies which variant of the SHA-2 285 algorithm is to be used in the generation of the authentication code. 287 This value MUST be encoded as a CBOR unsigned integer. 289 Valid values for this parameter are as follows. 291 SHA Variant Parameter Values 293 +-------+-----------------------------------------------------------+ 294 | Value | Description | 295 +-------+-----------------------------------------------------------+ 296 | 5 | HMAC 256/256 as defined in [RFC8152] Table 7: HMAC | 297 | | Algorithm Values | 298 | 6 | HMAC 384/384 as defined in [RFC8152] Table 7: HMAC | 299 | | Algorithm Values | 300 | 7 | HMAC 512/512 as defined in [RFC8152] Table 7: HMAC | 301 | | Algorithm Values | 302 +-------+-----------------------------------------------------------+ 304 Table 1 306 When not provided, implementations SHOULD assume a value of 6 307 (indicating use of HMAC 384/384), unless an alternate default is 308 established by local security policy at the security source, 309 verifiers, or acceptor of this integrity service. 311 3.3.2. Wrapped Key 313 This optional parameter contains the output of the AES key wrap 314 authenticated encryption function (KW-AE) as defined in [RFC5649]. 315 Specifically, this parameter holds the cipher text produced when 316 running the KW-AE algorithm with the input string being the symmetric 317 HMAC key used to generate the security results present in the 318 security block. The value of this parameter is used as input to the 319 AES key wrap authenticated decryption function (KW-AD) at security 320 verifiers and security acceptors to determine the symmetric HMAC key 321 needed for the proper validation of the security results in the 322 security block. 324 This value MUST be encoded as a CBOR byte string. 326 If this parameter is not present then security verifiers and 327 acceptors MUST determine the proper key as a function of their local 328 BPSec policy and configuration. 330 3.3.3. Integrity Scope Flags 332 This optional parameter contains a series of flags that describe what 333 information is to be included with the block-type-specific data when 334 constructing the IPPT value. 336 This value MUST be represented as a CBOR unsigned integer, the value 337 of which MUST be processed as a 16-bit field. The maximum value of 338 this field, as a CBOR unsigned integer, MUST be 65535. 340 Integrity scope flags that are unrecognized MUST be ignored, as 341 future definitions of additional flags might not be integrated 342 simultaneously into security context implementations operating at all 343 nodes. 345 Implementations MUST set reserved and unassigned bits in this field 346 to 0 when constructing these flags at a security source. Once set, 347 the value of this field MUST NOT be altered until the security 348 service is completed at the security acceptor in the network and 349 removed from the bundle. 351 Bits in this field represent additional information to be included 352 when generating an integrity signature over the security target. 353 These bits are defined as follows. 355 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 357 - Bit 1 (0x0002): Target Header Flag. 359 - Bit 2 (0x0004): Security Header Flag. 361 - Bits 3-7 are reserved. 363 - Bits 8-15 are unassigned. 365 3.3.4. Enumerations 367 The BIB-HMAC-SHA2 security context parameters are listed in Table 2. 368 In this table, the "Parm Id" column refers to the expected Parameter 369 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 370 and Result Identification". 372 If the default value column is empty, this indicates that the 373 security parameter does not have a default value. 375 BIB-HMAC-SHA2 Security Parameters 377 +---------+---------------------+-------------------+---------------+ 378 | Parm Id | Parm Name | CBOR Encoding | Default Value | 379 | | | Type | | 380 +---------+---------------------+-------------------+---------------+ 381 | 1 | SHA Variant | unsigned integer | 6 | 382 | 2 | Wrapped Key | Byte String | | 383 | 3 | Integrity Scope | unsigned integer | 7 | 384 | | Flags | | | 385 +---------+---------------------+-------------------+---------------+ 387 Table 2 389 3.4. Results 391 The BIB-HMAC-SHA2 security context results are listed in Table 3. In 392 this table, the "Result Id" column refers to the expected Result 393 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 394 and Result Identification". 396 BIB-HMAC-SHA2 Security Results 398 +--------+----------+-------------+---------------------------------+ 399 | Result | Result | CBOR | Description | 400 | Id | Name | Encoding | | 401 | | | Type | | 402 +--------+----------+-------------+---------------------------------+ 403 | 1 | Expected | byte string | The output of the HMAC | 404 | | HMAC | | calculation at the security | 405 | | | | source. | 406 +--------+----------+-------------+---------------------------------+ 408 Table 3 410 3.5. Key Considerations 412 HMAC keys used with this context MUST be symmetric and MUST have a 413 key length equal to the output of the HMAC. For this reason, HMAC 414 key lengths will be integer divisible by 8 bytes and special padding- 415 aware AES key wrap algorithms are not needed. 417 It is assumed that any security verifier or security acceptor 418 performing an integrity verification can determine the proper HMAC 419 key to be used. Potential sources of the HMAC key include (but are 420 not limited to) the following: 422 Pre-placed keys selected based on local policy. 424 Keys extracted from material carried in the BIB. 426 Session keys negotiated via a mechanism external to the BIB. 428 When an AES-KW wrapped key is present in a security block, it is 429 assumed that security verifiers and security acceptors can 430 independently determine the key encryption key (KEK) used in the 431 wrapping of the symmetric HMAC key. 433 As discussed in Section 6 and emphasized here, it is strongly 434 recommended that keys be protected once generated, both when they are 435 stored and when they are transmitted. 437 3.6. Security Processing Considerations 439 An HMAC calculated over the same IPPT with the same key will always 440 have the same value. This regularity can lead to practical side- 441 channel attacks whereby an attacker could produce known plain text 442 and a guess at an HMAC tag and observe the behavior of a verifier. 443 With a modest number of trials, a side-channel attack could produce 444 an HMAC tag for attacher-provided plain text without the attacker 445 ever knowing the HMAC key. 447 A common method of observing the behavior of a verifier is precise 448 analysis of the timing associated with comparisons. Therefore, one 449 way to prevent behavior analysis of this type is to ensure that any 450 comparisons of the supplied and expected authentication tag occur in 451 constant time. 453 A constant-time comparison function SHOULD be used for the comparison 454 of authentication tags by any implementation of this security 455 context. In cases where such a function is difficult or impossible 456 to use, the impact of side-channel (in general) and timing attacks 457 (specifically) need to be considered as part of the implementation. 459 3.7. Canonicalization Algorithms 461 This section defines the canonicalization algorithm used to prepare 462 the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The 463 construction of the IPPT depends on the settings of the integrity 464 scope flags that can be provided as part of customizing the behavior 465 of this security context. 467 In all cases, the canonical form of any portion of an extension block 468 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 469 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 470 the canonical forms for extension blocks defined in 472 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 473 are represented in CBOR. 475 The IPPT is constructed using the following process. While integrity 476 scope flags might not be included in the BIB representing the 477 security operation, they MUST be included in the IPPT value itself. 479 1. The canonical form of the IPPT starts as the CBOR encoding of the 480 integrity scope flags in which all unset flags, reserved bits, 481 and unassigned bits have been set to 0. For example, if the 482 primary block flag, target header flag, and security header flag 483 are each set, then the initial value of the canonical form of the 484 IPPT will be 0x07. 486 2. If the primary block flag of the integrity scope flags is set to 487 1, then a canonical form of the bundle's primary block MUST be 488 calculated and the result appended to the IPPT. 490 3. If the target header flag of the integrity scope flags is set to 491 1, then the canonical form of the block type code, block number, 492 and block processing control flags associated with the security 493 target MUST be calculated and, in that order, appended to the 494 IPPT. 496 4. If the security header flag of the integrity scope flags is set 497 to 1, then the canonical form of the block type code, block 498 number, and block processing control flags associated with the 499 BIB MUST be calculated and, in that order, appended to the IPPT. 501 5. The canonical form of the security target block-type-specific 502 data MUST be calculated and appended to the IPPT. 504 3.8. Processing 506 3.8.1. Keyed Hash Generation 508 During keyed hash generation, two inputs are prepared for the the 509 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 510 data items MUST be generated as follows. 512 The HMAC key MUST have the appropriate length as required by local 513 security policy. The key can be generated specifically for this 514 integrity service, given as part of local security policy, or 515 through some other key management mechanism as discussed in 516 Section 3.5. 518 Prior to the generation of the IPPT, if a CRC value is present for 519 the target block of the BIB, then that CRC value MUST be removed 520 from the target block. This involves both removing the CRC value 521 from the target block and setting the CRC Type field of the target 522 block to "no CRC is present." 524 Once CRC information is removed, the IPPT MUST be generated as 525 discussed in Section 3.7. 527 Upon successful hash generation the following actions MUST occur. 529 The keyed hash produced by the HMAC/SHA2 variant MUST be added as 530 a security result for the BIB representing the security operation 531 on this security target, as discussed in Section 3.4. 533 Finally, the BIB containing information about this security operation 534 MUST be updated as follows. These operations can occur in any order. 536 The security context identifier for the BIB MUST be set to the 537 context identifier for BIB-HMAC-SHA2. 539 Any local flags used to generate the IPPT MUST be placed in the 540 integrity scope flags security parameter for the BIB unless these 541 flags are expected to be correctly configured at security 542 verifiers and acceptors in the network. 544 The HMAC key MAY be included as a security parameter in which case 545 it MUST be wrapped using the NIST AES-KW algorithm and the results 546 of the wrapping added as the wrapped key security parameter for 547 the BIB. 549 The SHA variant used by this security context SHOULD be added as 550 the SHA variant security parameter for the BIB if it differs from 551 the default key length. Otherwise, this parameter MAY be omitted 552 if doing so provides a useful reduction in message sizes. 554 Problems encountered in the keyed hash generation MUST be processed 555 in accordance with local BPSec security policy. 557 3.8.2. Keyed Hash Verification 559 During keyed hash verification, the input of the security target and 560 a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. 562 During keyed hash verification, two inputs are prepared for the 563 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 564 data items MUST be generated as follows. 566 The HMAC key MUST be derived using the wrapped key security 567 parameter if such a parameter is included in the security context 568 parameters of the BIB. Otherwise, this key MUST be derived in 569 accordance with security policy at the verifying node as discussed 570 in Section 3.5. 572 The IPPT MUST be generated as discussed in Section 3.7 with the 573 value of integrity scope flags being taken from the integrity 574 scope flags security context parameter. If the integrity scope 575 flags parameter is not included in the security context parameters 576 then these flags MAY be derived from local security policy. 578 The calculated HMAC output MUST be compared to the expected HMAC 579 output encoded in the security results of the BIB for the security 580 target. If the calculated HMAC and expected HMAC are identical, the 581 verification MUST be considered a success. Otherwise, the 582 verification MUST be considered a failure. 584 If the verification fails or otherwise experiences an error, or if 585 any needed parameters are missing, then the verification MUST be 586 treated as failed and processed in accordance with local security 587 policy. 589 This security service is removed from the bundle at the security 590 acceptor as required by the BPSec specification. If the security 591 acceptor is not the bundle destination and if no other integrity 592 service is being applied to the target block, then a CRC MUST be 593 included for the target block. The CRC type, as determined by 594 policy, is set in the target block's CRC type field and the 595 corresponding CRC value is added as the CRC field for that block. 597 4. Security Context BCB-AES-GCM 599 4.1. Overview 601 The BCB-AES-GCM security context replaces the block-type-specific 602 data field of its security target with cipher text generated using 603 the Advanced Encryption Standard (AES) cipher operating in Galois/ 604 Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the 605 cipher suite for this confidentiality mechanism for several reasons: 607 1. The selection of a symmetric-key cipher suite allows for 608 relatively smaller keys than asymmetric-key cipher suites. 610 2. The selection of a symmetric-key cipher suite allows this 611 security context to be used in places where an asymmetric-key 612 infrastructure (such as a public key infrastructure) might be 613 impractical. 615 3. The use of the Galois/Counter Mode produces cipher-text with the 616 same size as the plain text making the replacement of target 617 block information easier as length fields do not need to be 618 changed. 620 4. The AES-GCM cipher suite provides authenticated encryption, as 621 required by the BPSec protocol. 623 Additionally, the BCB-AES-GCM security context generates an 624 authentication tag based on the plain text value of the block-type- 625 specific data and other additional authenticated data that might be 626 specified via parameters to this security context. 628 This security context supports two variants of AES-GCM, based on the 629 supported length of the symmetric key. These variants correspond to 630 A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value 631 for AES-GCM. 633 The BCB-AES-GCM security context MUST have the security context 634 identifier specified in Section 5.1. 636 4.2. Scope 638 There are two scopes associated with BCB-AES-GCM: the scope of the 639 confidentiality service and the scope of the authentication service. 640 The first defines the set of information provided to the AES-GCM 641 cipher for the purpose of producing cipher text. The second defines 642 the set of information used to generate an authentication tag. 644 The scope of the confidentiality service defines the set of 645 information provided to the AES-GCM cipher for the purpose of 646 producing cipher text. This MUST be the full set of plain text 647 contained in the block-type-specific data field of the security 648 target. 650 The scope of the authentication service defines the set of 651 information used to generate an authentication tag carried with the 652 security block. This information contains all data protected by the 653 confidentiality service, the scope flags used to identify other 654 optional information, and MAY include other information (additional 655 authenticated data), as follows. 657 Primary block 658 The primary block identifies a bundle and, once created, the 659 contents of this block are immutable. Changes to the primary 660 block associated with the security target indicate that the 661 security target (and BCB) might no longer be in the correct 662 bundle. 664 For example, if a security target and associated BCB are copied 665 from one bundle to another bundle, the BCB might still be able to 666 decrypt the security target even though these blocks were never 667 intended to exist in the copied-to bundle. 669 Including this information as part of additional authenticated 670 data ensures that security target (and security block) appear in 671 the same bundle at the time of decryption as at the time of 672 encryption. 674 Security target other fields 675 The other fields of the security target include block 676 identification and processing information. Changing this 677 information changes how the security target is treated by nodes 678 in the network even when the "user data" of the security target 679 are otherwise unchanged. 681 For example, if the block processing control flags of a security 682 target are different at a security verifier than they were 683 originally set at the security source then the policy for 684 handling the security target has been modified. 686 Including this information as part of additional authenticated 687 data ensures that the cipher text in the security target will not 688 be used with a different set of block policy than originally set 689 at the time of encryption. 691 BCB other fields 692 The other fields of the BCB include block identification and 693 processing information. Changing this information changes how 694 the BCB is treated by nodes in the network, even when other 695 aspects of the BCB are unchanged. 697 For example, if the block processing control flags of the BCB are 698 different at a security acceptor than they were originally set at 699 the security source then the policy for handling the BCB has been 700 modified. 702 Including this information as part of additional authenticated 703 data ensures that the policy and identification of the security 704 service in the bundle has not changed. 706 NOTE: The security context identifier and security context 707 parameters of the security block are not included as additional 708 authenticated data because these parameters, by definition, are 709 those needed to verify or accept the security service. 710 Therefore, it is expected that changes to these values would 711 result in failures at security verifiers and security acceptors. 713 This is the case because keys cannot be re-used across security 714 contexts, and because the AAD scope flags used to identify the 715 AAD are included in the AAD. 717 The scope of the BCB-AES-GCM security context is configured using an 718 optional security context parameter. 720 4.3. Parameters 722 BCB-AES-GCM can be parameterized to specify the AES variant, 723 initialization vector, key information, and identify additional 724 authenticated data. 726 4.3.1. Initialization Vector (IV) 728 This optional parameter identifies the initialization vector (IV) 729 used to initialize the AES-GCM cipher. 731 The length of the initialization vector, prior to any CBOR encoding, 732 MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used 733 unless local security policy requires a different length. 735 This value MUST be encoded as a CBOR byte string. 737 The initialization vector can have any value with the caveat that a 738 value MUST NOT be re-used for multiple encryptions using the same 739 encryption key. This value MAY be re-used when encrypting with 740 different keys. For example, if each encryption operation using BCB- 741 AES-GCM uses a newly generated key, then the same IV can be reused. 743 4.3.2. AES Variant 745 This optional parameter identifies the AES variant being used for the 746 AES-GCM encryption, where the variant is identified by the length of 747 key used. 749 This value MUST be encoded as a CBOR unsigned integer. 751 Valid values for this parameter are as follows. 753 AES Variant Parameter Values 755 +-------+-----------------------------------------------------------+ 756 | Value | Description | 757 +-------+-----------------------------------------------------------+ 758 | 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values | 759 | | for AES-GCM | 760 | 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values | 761 | | for AES-GCM | 762 +-------+-----------------------------------------------------------+ 764 When not provided, implementations SHOULD assume a value of 3 765 (indicating use of A256GCM), unless an alternate default is 766 established by local security policy at the security source, 767 verifier, or acceptor of this integrity service. 769 Regardless of the variant, the generated authentication tag MUST 770 always be 128 bits. 772 4.3.3. Wrapped Key 774 This optional parameter contains the output of the AES key wrap 775 authenticated encryption function (KW-AE) as defined in [RFC5649]. 776 Specifically, this parameter holds the cipher text produced when 777 running the KW-AE algorithm with the input string being the symmetric 778 AES key used to generate the security results present in the security 779 block. The value of this parameter is used as input to the AES key 780 wrap authenticated decryption function (KW-AD) at security verifiers 781 and security acceptors to determine the symmetric AES key needed for 782 the proper decryption of the security results in the security block. 784 This value MUST be encoded as a CBOR byte string. 786 If this parameter is not present then security verifiers and 787 acceptors MUST determine the proper key as a function of their local 788 BPSec policy and configuration. 790 4.3.4. AAD Scope Flags 792 This optional parameter contains a series of flags that describe what 793 information is to be included with the block-type-specific data of 794 the security target as part of additional authenticated data (AAD). 796 This value MUST be represented as a CBOR unsigned integer, the value 797 of which MUST be processed as a 16-bit field. The maximum value of 798 this field, as a CBOR unsigned integer, MUST be 65535. 800 AAD scope flags that are unrecognized MUST be ignored, as future 801 definitions of additional flags might not be integrated 802 simultaneously into security context implementations operating at all 803 nodes. 805 Implementations MUST set reserved and unassigned bits in this field 806 to 0 when constructing these flags at a security source. Once set, 807 the value of this field MUST NOT be altered until the security 808 service is completed at the security acceptor in the network and 809 removed from the bundle. 811 Bits in this field represent additional information to be included 812 when generating an integrity signature over the security target. 813 These bits are defined as follows. 815 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 817 - Bit 1 (0x0002): Target Header Flag. 819 - Bit 2 (0x0004): Security Header Flag. 821 - Bits 3-7 are reserved. 823 - Bits 8-15 are unassigned. 825 4.3.5. Enumerations 827 The BCB-AES-GCM security context parameters are listed in Table 4. 828 In this table, the "Parm Id" column refers to the expected Parameter 829 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 830 and Result Identification". 832 If the default value column is empty, this indicates that the 833 security parameter does not have a default value. 835 BCB-AES-GCM Security Parameters 837 +---------+----------------------+------------------+---------------+ 838 | Parm Id | Parm Name | CBOR Encoding | Default Value | 839 | | | Type | | 840 +---------+----------------------+------------------+---------------+ 841 | 1 | Initialization | Byte String | | 842 | | Vector | | | 843 | 2 | AES Variant | Unsigned Integer | 3 | 844 | 3 | Wrapped Key | Byte String | | 845 | 4 | AAD Scope Flags | Unsigned Integer | 7 | 846 +---------+----------------------+------------------+---------------+ 848 Table 4 850 4.4. Results 852 The BCB-AES-GCM security context produces a single security result 853 carried in the security block: the authentication tag. 855 NOTES: 857 The cipher text generated by the cipher suite is not considered a 858 security result as it is stored in the block-type-specific data 859 field of the security target block. When operating in GCM mode, 860 AES produces cipher text of the same size as its plain text and, 861 therefore, no additional logic is required to handle padding or 862 overflow caused by the encryption in most cases (see below). 864 If the authentication tag can be separated from the cipher text, 865 then the tag MAY be separated and stored in the authentication tag 866 security result field. Otherwise, the security target block MUST 867 be resized to accommodate the additional 128 bits of 868 authentication tag included with the generated cipher text 869 replacing the block-type-specific-data field of the security 870 target block. 872 4.4.1. Authentication Tag 874 The authentication tag is generated by the cipher suite over the 875 security target plain text input to the cipher suite as combined with 876 any optional additional authenticated data. This tag is used to 877 ensure that the plain text (and important information associated with 878 the plain text) is authenticated prior to decryption. 880 If the authentication tag is included in the cipher text placed in 881 the security target block-type-specific data field, then this 882 security result MUST NOT be included in the BCB for that security 883 target. 885 The length of the authentication tag, prior to any CBOR encoding, 886 MUST be 128 bits. 888 This value MUST be encoded as a CBOR byte string. 890 4.4.2. Enumerations 892 The BCB-AES-GCM security context results are listed in Table 5. In 893 this table, the "Result Id" column refers to the expected Result 894 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 895 and Result Identification". 897 BCB-AES-GCM Security Results 899 +-----------+--------------------+--------------------+ 900 | Result Id | Result Name | CBOR Encoding Type | 901 +-----------+--------------------+--------------------+ 902 | 1 | Authentication Tag | Byte String | 903 +-----------+--------------------+--------------------+ 905 Table 5 907 4.5. Key Considerations 909 Keys used with this context MUST be symmetric and MUST have a key 910 length equal to the key length defined in the security context 911 parameters or as defined by local security policy at security 912 verifiers and acceptors. For this reason, content-encrypting key 913 lengths will be integer divisible by 8 bytes and special padding- 914 aware AES key wrap algorithms are not needed. 916 It is assumed that any security verifier or security acceptor can 917 determine the proper key to be used. Potential sources of the key 918 include (but are not limited to) the following. 920 Pre-placed keys selected based on local policy. 922 Keys extracted from material carried in the BCB. 924 Session keys negotiated via a mechanism external to the BCB. 926 When an AES-KW wrapped key is present in a security block, it is 927 assumed that security verifiers and security acceptors can 928 independently determine the key encryption key (KEK) used in the 929 wrapping of the symmetric AES content-encrypting key. 931 The security provided by block ciphers is reduced as more data is 932 processed with the same key. The total number of blocks processed 933 with a single key for AES-GCM is recommended to be less than 2^64, as 934 described in Appendix B of [AES-GCM]. 936 Additionally, there exist limits on the number of encryptions that 937 can be performed with the same key. The total number of invocations 938 of the authenticated encryption function with a single key for AES- 939 GCM is required to not exceed 2^32, as described in Section 8.3 of 940 [AES-GCM]. 942 As discussed in Section 6 and emphasized here, it is strongly 943 recommended that keys be protected once generated, both when they are 944 stored and when they are transmitted. 946 4.6. GCM Considerations 948 The GCM cryptographic mode of AES has specific requirements that MUST 949 be followed by implementers for the secure function of the BCB-AES- 950 GCM security context. While these requirements are well documented 951 in [AES-GCM], some of them are repeated here for emphasis. 953 With the exception of the AES-KW function, the IVs used by the 954 BCB-AES-GCM security context are considered to be per-invocation 955 IVs. The pairing of a per-invocation IV and a security key MUST 956 be unique. A per-invocation IV MUST NOT be used with a security 957 key more than one time. If a per-invocation IV and key pair are 958 repeated then the GCM implementation is vulnerable to forgery 959 attacks. More information regarding the importance of the 960 uniqueness of the IV value can be found in Appendix A of 961 [AES-GCM]. 963 The AES-KW function used to wrap keys for the security contexts in 964 this document uses a single, globally constant IV input to the AES 965 cipher operation and, thus, is distinct from the aforementioned 966 requirement related to per-invocation IVs. 968 While any tag-based authentication mechanism has some likelihood 969 of being forged, this probability is increased when using AES-GCM. 970 In particular, short tag lengths combined with very long messages 971 SHOULD be avoided when using this mode. The BCB-AES-GCM security 972 context requires the use of 128-bit authentication tags at all 973 times. Concerns relating to the size of authentication tags is 974 discussed in Appendices B and C of [AES-GCM]. 976 As discussed in Appendix B of [AES-GCM], implementations SHOULD 977 limit the number of unsuccessful verification attempts for each 978 key to reduce the likelihood of guessing tag values. This type of 979 check has potential state-keeping issues when AES-KW is used, 980 since an attacker could cause a large number of keys to have been 981 used at least once. 983 As discussed in the Security Considerations section of 984 [I-D.ietf-dtn-bpsec], delay-tolerant networks have a higher 985 occurrence of replay attacks due to the store-and-forward nature 986 of the network. Because GCM has no inherent replay attack 987 protection, implementors SHOULD attempt to detect replay attacks 988 by using mechanisms such as those described in Appendix D of 989 [AES-GCM]. 991 4.7. Canonicalization Algorithms 993 This section defines the canonicalization algorithms used to prepare 994 the inputs used to generate both the cipher text and the 995 authentication tag. 997 In all cases, the canonical form of any portion of an extension block 998 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 999 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 1000 the canonical forms for extension blocks defined in 1001 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 1002 are represented in CBOR. 1004 4.7.1. Cipher text related calculations 1006 The BCB operates over the block-type-specific data of a block, but 1007 the BP always encodes these data within a single, definite-length 1008 CBOR byte string. Therefore, the plain text used during encryption 1009 MUST be calculated as the value of the block-type-specific data field 1010 of the security target excluding any CBOR encoding. 1012 Consider the following two CBOR encoded examples and the plain text 1013 that would be extracted from them. The first example is an unsigned 1014 integer, while the second is a byte string. 1016 CBOR Plain Text Extraction Examples 1018 +------------------------------+---------+--------------------------+ 1019 | CBOR Encoding (Hex) | CBOR | Plain Text Part (Hex) | 1020 | | Part | | 1021 | | (Hex) | | 1022 +------------------------------+---------+--------------------------+ 1023 | 18ED | 18 | ED | 1024 +------------------------------+---------+--------------------------+ 1025 | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | 1026 +------------------------------+---------+--------------------------+ 1028 Table 6 1030 Similarly, the cipher text used during decryption MUST be calculated 1031 as the single, definite-length CBOR byte string representing the 1032 block-type-specific data field excluding the CBOR byte string 1033 identifying byte and optional CBOR byte string length field. 1035 All other fields of the security target (such as the block type code, 1036 block number, block processing control flags, or any CRC information) 1037 MUST NOT be considered as part of encryption or decryption. 1039 4.7.2. Additional Authenticated Data 1041 The construction of additional authenticated data depends on the AAD 1042 scope flags that can be provided as part of customizing the behavior 1043 of this security context. 1045 The canonical form of the AAD input to the BCB-AES-GCM mechanism is 1046 constructed using the following process. While the AAD scope flags 1047 might not be included in the BCB representing the security operation, 1048 they MUST be included in the AAD value itself. This process MUST be 1049 followed when generating AAD for either encryption or decryption. 1051 1. The canonical form of the AAD starts as the CBOR encoding of the 1052 AAD scope flags in which all unset flags, reserved bits, and 1053 unassigned bits have been set to 0. For example, if the primary 1054 block flag, target header flag, and security header flag are each 1055 set, then the initial value of the canonical form of the AAD will 1056 be 0x07. 1058 2. If the primary block flag of the AAD scope flags is set to 1, 1059 then a canonical form of the bundle's primary block MUST be 1060 calculated and the result appended to the AAD. 1062 3. If the target header flag of the AAD scope flags is set to 1, 1063 then the canonical form of the block type code, block number, and 1064 block processing control flags associated with the security 1065 target MUST be calculated and, in that order, appended to the 1066 AAD. 1068 4. If the security header flag of the AAD scope flags is set to 1, 1069 then the canonical form of the block type code, block number, and 1070 block processing control flags associated with the BIB MUST be 1071 calculated and, in that order, appended to the AAD. 1073 4.8. Processing 1075 4.8.1. Encryption 1077 During encryption, four inputs are prepared for input to the AES/GCM 1078 cipher: the encryption key, the IV, the security target plain text to 1079 be encrypted, and any additional authenticated data. These data 1080 items MUST be generated as follows. 1082 Prior to encryption, if a CRC value is present for the target block, 1083 then that CRC value MUST be removed. This requires removing the CRC 1084 field from the target block and setting the CRC type field of the 1085 target block to "no CRC is present." 1087 The encryption key MUST have the appropriate length as required by 1088 local security policy. The key might be generated specifically 1089 for this encryption, given as part of local security policy, or 1090 through some other key management mechanism as discussed in 1091 Section 4.5. 1093 The IV selected MUST be of the appropriate length. Because 1094 replaying an IV in counter mode voids the confidentiality of all 1095 messages encrypted with said IV, this context also requires a 1096 unique IV for every encryption performed with the same key. This 1097 means the same key and IV combination MUST NOT be used more than 1098 once. 1100 The security target plain text for encryption MUST be generated as 1101 discussed in Section 4.7.1. 1103 Additional authenticated data MUST be generated as discussed in 1104 Section 4.7.2 with the value of AAD scope flags being taken from 1105 local security policy. 1107 Upon successful encryption the following actions MUST occur. 1109 The cipher text produced by AES/GCM MUST replace the bytes used to 1110 define the plain text in the security target block's block-type- 1111 specific data field. The block length of the security target MUST 1112 be updated if the generated cipher text is larger than the plain 1113 text (which can occur when the authentication tag is included in 1114 the cipher text calculation, as discussed in Section 4.4). 1116 The authentication tag calculated by the AES/GCM cipher MAY be 1117 added as a security result for the security target in the BCB 1118 holding results for this security operation, in which case it MUST 1119 be processed as described in Section 4.4. 1121 The authentication tag MUST be included either as a security 1122 result in the BCB representing the security operation or (with the 1123 cipher text) in the security target block-type-specific data 1124 field. 1126 Finally, the BCB containing information about this security operation 1127 MUST be updated as follows. These operations can occur in any order. 1129 The security context identifier for the BCB MUST be set to the 1130 context identifier for BCB-AES-GCM. 1132 The IV input to the cipher MUST be added as the IV security 1133 parameter for the BCB. 1135 Any local flags used to generated AAD for this cipher MUST be 1136 placed in the AAD scope flags security parameter for the BCB 1137 unless these flags are expected to be correctly configured at 1138 security verifiers and security acceptors in the network. 1140 The encryption key MAY be included as a security parameter in 1141 which case it MUST be wrapped using the NIST AES-KW algorithm and 1142 the results of the wrapping added as the wrapped key security 1143 parameter for the BCB. 1145 The AES variant used by this security context SHOULD be added as 1146 the AES variant security parameter for the BCB if it differs from 1147 the default key length. Otherwise, this parameter MAY be omitted 1148 if doing so provides a useful reduction in message sizes. 1150 Problems encountered in the encryption MUST be processed in 1151 accordance with local security policy. This MAY include restoring a 1152 CRC value removed from the target block prior to encryption, if the 1153 target block is allowed to be transmitted after an encryption error. 1155 4.8.2. Decryption 1157 During decryption, five inputs are prepared for input to the AES/GCM 1158 cipher: the decryption key, the IV, the security target cipher text 1159 to be decrypted, any additional authenticated data, and the 1160 authentication tag generated from the original encryption. These 1161 data items MUST be generated as follows. 1163 The decryption key MUST be derived using the wrapped key security 1164 parameter if such a parameter is included in the security context 1165 parameters of the BCB. Otherwise this key MUST be derived in 1166 accordance with local security policy at the decrypting node as 1167 discussed in Section 4.5. 1169 The IV MUST be set to the value of the IV security parameter 1170 included in the BCB. If the IV parameter is not included as a 1171 security parameter, an IV MAY be derived as a function of local 1172 security policy and other BCB contents or a lack of an IV security 1173 parameter in the BCB MAY be treated as an error by the decrypting 1174 node. 1176 The security target cipher text for decryption MUST be generated 1177 as discussed in Section 4.7.1. 1179 Additional authenticated data MUST be generated as discussed in 1180 Section 4.7.2 with the value of AAD scope flags being taken from 1181 the AAD scope flags security context parameter. If the AAD scope 1182 flags parameter is not included in the security context parameters 1183 then these flags MAY be derived from local security policy in 1184 cases where the set of such flags is determinable in the network. 1186 The authentication tag MUST be present in the BCB security context 1187 parameters field. This tag MUST be 128 bits in length. 1189 Upon successful decryption the following actions MUST occur. 1191 The plain text produced by AES/GCM MUST replace the bytes used to 1192 define the cipher text in the security target block's block-type- 1193 specific data field. Any changes to the security target block 1194 length field MUST be corrected in cases where the plain text has a 1195 different length than the replaced cipher text. 1197 If the security acceptor is not the bundle destination and if no 1198 other integrity or confidentiality service is being applied to the 1199 target block, then a CRC MUST be included for the target block. The 1200 CRC type, as determined by policy, is set in the target block's CRC 1201 type field and the corresponding CRC value is added as the CRC field 1202 for that block. 1204 If the cipher text fails to authenticate, if any needed parameters 1205 are missing, or if there are other problems in the decryption then 1206 the decryption MUST be treated as failed and processed in accordance 1207 with local security policy. 1209 5. IANA Considerations 1211 5.1. Security Context Identifiers 1213 This specification allocates two security context identifiers from 1214 the "BPSec Security Context Identifiers" registry defined in 1215 [I-D.ietf-dtn-bpsec]. 1217 Additional Entries for the BPSec Security Context Identifiers 1218 Registry: 1220 +-------+---------------+---------------+ 1221 | Value | Description | Reference | 1222 +-------+---------------+---------------+ 1223 | TBA | BIB-HMAC-SHA2 | This document | 1224 | TBA | BCB-AES-GCM | This document | 1225 +-------+---------------+---------------+ 1227 Table 7 1229 5.2. Integrity Scope Flags 1231 The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field 1232 for which IANA is requested to create and maintain a new registry 1233 named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle 1234 Protocol registry page. Initial values for this registry are given 1235 below. 1237 The registration policy for this registry is: Specification Required. 1239 The value range is unsigned 16-bit integer. 1241 BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry 1243 +-------------------------+--------------------------+--------------+ 1244 | Bit Position (right to | Description | Reference | 1245 | left) | | | 1246 +-------------------------+--------------------------+--------------+ 1247 | 0 | Include primary block | This | 1248 | | | document | 1249 | 1 | Include target header | This | 1250 | | flag | document | 1251 | 2 | Include security header | This | 1252 | | flag | document | 1253 | 3-7 | reserved | This | 1254 | | | document | 1255 | 8-15 | unassigned | This | 1256 | | | document | 1257 +-------------------------+--------------------------+--------------+ 1259 Table 8 1261 5.3. AAD Scope Flags 1263 The BCB-AES-GCM security context has an AAD Scope Flags field for 1264 which IANA is requested to create and maintain a new registry named 1265 "BPSec BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol registry 1266 page. Initial values for this registry are given below. 1268 The registration policy for this registry is: Specification Required. 1270 The value range is unsigned 16-bit integer. 1272 BPSec BCB-AES-GCM AAD Scope Flags Registry 1274 +-------------------------+--------------------------+--------------+ 1275 | Bit Position (right to | Description | Reference | 1276 | left) | | | 1277 +-------------------------+--------------------------+--------------+ 1278 | 0 | Include primary block | This | 1279 | | | document | 1280 | 1 | Include target header | This | 1281 | | flag | document | 1282 | 2 | Include security header | This | 1283 | | flag | document | 1284 | 3-7 | reserved | This | 1285 | | | document | 1286 | 8-15 | unassigned | This | 1287 | | | document | 1288 +-------------------------+--------------------------+--------------+ 1290 Table 9 1292 5.4. Guidance for Designated Experts 1294 New assignments within the BIB-HMAC-SHA2 Integrity Scope Flags 1295 Registry and the BCB-AES-GCM AAD Scope Flags Registry require review 1296 by a Designated Expert (DE). This section provides guidance to the 1297 DE when performing their reviews. Specifically, a DE is expected to 1298 perform the following activities. 1300 o Ascertain the existence of suitable documentation (a 1301 specification) as described in [RFC8126] and to verify that the 1302 document is permanently and publicly available. 1304 o Ensure that any changes to the Integrity Scope Flags clearly state 1305 how new assignments interact with existing flags and how the 1306 inclusion of new assignments affects the construction of the IPPT 1307 value. 1309 o Ensure that any changes to the AAD Scope Flags clearly state how 1310 new assignments interact with existing flags and how the inclusion 1311 of new assignments affects the construction of the AAD input to 1312 the BCB-AES-GCM mechanism. 1314 o Ensure that any processing changes proposed with new assignments 1315 do not alter any required behavior in this specification. 1317 o Verify that any specification produced in the IETF has been made 1318 available for review by the DTN working group and that any 1319 specification produced outside of the IETF does not conflict with 1320 work that is active or already published within the IETF. 1322 6. Security Considerations 1324 Security considerations specific to a single security context are 1325 provided in the description of that context. This section discusses 1326 security considerations that should be evaluated by implementers of 1327 any security context described in this document. Considerations can 1328 also be found in documents listed as normative references and they 1329 should also be reviewed by security context implementors. 1331 6.1. Key Management 1333 The delayed and disrupted nature of DTNs complicates the process of 1334 key management because there might not be reliable, timely round-trip 1335 exchange between security sources, security verifiers, and security 1336 acceptors in the network. This is true when there is a substantial 1337 signal propagation delay between nodes, when nodes are in a highly 1338 challenged communications environment, and when nodes do not support 1339 bi-directional communication. 1341 In these environments, key establishment protocols that rely on 1342 round-trip information exchange might not converge on a shared secret 1343 in a timely manner (or at all). Also, key revocation or key 1344 verification mechanisms that rely on access to a centralized 1345 authority (such as a certificate authority) might similarly fail in 1346 the stressing conditions of a DTN. 1348 For these reasons, the default security contexts described in this 1349 document rely on symmetric key cryptographic mechanisms because 1350 asymmetric key infrastructure (such as a public key infrastructure) 1351 might be impractical in this environment. 1353 BPSec assumes that "key management is handled as a separate part of 1354 network management" [I-D.ietf-dtn-bpsec]. This assumption is also 1355 made by the security contexts defined in this document which do not 1356 define new protocols for key derivation, exchange of key-encrypting 1357 keys, revocation of existing keys, or the security configuration or 1358 policy used to select certain keys for certain security operations. 1360 Nodes using these security contexts need to perform the following 1361 kinds of activities, independent of the construction, transmission, 1362 and processing of BPSec security blocks. 1364 Establish shared key-encrypting-keys with other nodes in the 1365 network using an out-of-band mechanism. This might include pre- 1366 sharing of key encryption keys or the use of traditional key 1367 establishment mechanisms prior to the exchange of BPsec security 1368 blocks. 1370 Determine when a key is considered exhausted and no longer to be 1371 used in the generation, verification, or acceptance of a security 1372 block. 1374 Determine when a key is considered invalid and no longer to be 1375 used in the generation, verification, or acceptance of a security 1376 block. Such revocations can be based on a variety of mechanisms 1377 to include local security policy, time relative to the generation 1378 or use of the key, or as specified through network management. 1380 Determine, through an out-of-band mechanism such as local security 1381 policy, what keys are to be used for what security blocks. This 1382 includes the selection of which key should be used in the 1383 evaluation of a security block received by a security verifier or 1384 a security acceptor. 1386 The failure to provide effective key management techniques 1387 appropriate for the operational networking environment can result in 1388 the compromise of those unmanaged keys and the loss of security 1389 services in the network. 1391 6.2. Key Handling 1393 Once generated, keys should be handled as follows. 1395 It is strongly RECOMMENDED that implementations protect keys both 1396 when they are stored and when they are transmitted. 1398 In the event that a key is compromised, any security operations 1399 using a security context associated with that key SHOULD also be 1400 considered compromised. This means that the BIB-HMAC-SHA2 1401 security context SHOULD NOT be treated as providing integrity when 1402 used with a compromised key and BCB-AES-GCM SHOULD NOT be treated 1403 as providing confidentiality when used with a compromised key. 1405 The same key, whether a key-encrypting-key or a wrapped key, MUST 1406 NOT be used for different algorithms as doing so might leak 1407 information about the key. 1409 A key-encrypting-key MUST NOT be used to encrypt keys for 1410 different security contexts. Any key-encrypting-key used by a 1411 security context defined in this document MUST only be used to 1412 wrap keys associated with security operations using that security 1413 context. This means that a compliant security source would not 1414 use the same key-encrypting-key to wrap keys for both the BIB- 1415 HMAC-SHA2 and BCB-AES-GCM security contexts. Similarly, any 1416 compliant security verifier or security acceptor would not use the 1417 same key-encrypting-key to unwrap keys for different security 1418 contexts. 1420 6.3. AES GCM 1422 There are a significant number of considerations related to the use 1423 of the GCM mode of AES to provide a confidentiality service. These 1424 considerations are provided in Section 4.6 as part of the 1425 documentation of the BCB-AES-GCM security context. 1427 The length of the cipher text produced by the GCM mode of AES will be 1428 equal to the length of the plain text input to the cipher suite. The 1429 authentication tag also produced by this cipher suite is separate 1430 from the cipher text. However, it should be noted that 1431 implementations of the AES-GCM cipher suite might not separate the 1432 concept of cipher text and authentication tag in their application 1433 programming interface (API). 1435 Implementations of the BCB-AES-GCM security context can either keep 1436 the length of the target block unchanged by holding the 1437 authentication tag in a BCB security result or alter the length of 1438 the target block by including the authentication tag with the cipher 1439 text replacing the block-type-specific-data field of the target 1440 block. Implementations MAY use the authentication tag security 1441 result in cases where keeping target block length unchanged is an 1442 important processing concern. In all cases, the cipher text and 1443 authentication tag MUST be processed in accordance with the API of 1444 the AES-GCM cipher suites at the security source and security 1445 acceptor. 1447 6.4. AES Key Wrap 1449 The AES key wrap (AES-KW) algorithm used by the security contexts in 1450 this document does not use a per-invocation initialization vector and 1451 does not require any key padding. Key padding is not needed because 1452 wrapped keys used by these security contexts will always be multiples 1453 of 8 bytes. The length of the wrapped key can be determined by 1454 inspecting the security context parameters. Therefore, a key can be 1455 unwrapped using only the information present in the security block 1456 and the key encryption key provided by local security policy at the 1457 security verifier or security acceptor. 1459 6.5. Bundle Fragmentation 1461 Bundle fragmentation might prevent security services in a bundle from 1462 being verified after a bundle is fragmented and before the bundle is 1463 re-assembled. Examples of potential issues include the following. 1465 If a security block and its security target do not exist in the 1466 same fragment, then the security block cannot be processed until 1467 the bundle is re-assembled. If a fragment includes an encrypted 1468 target block, but not its BCB, then a receiving bundle processing 1469 agent (BPA) will not know that the target block has been 1470 encrypted. 1472 A security block can be cryptographically bound to a bundle by 1473 setting the Integrity Scope Flags (for BIB-HMAC-SHA2) or the AAD 1474 Scope Flags (for BCB-AES-GCM) to include the bundle primary block. 1475 When a security block is cryptographically bound to a bundle, it 1476 cannot be processed even if the security block and target both 1477 coexist in the fragment. This is because fragments have different 1478 primary blocks than the original bundle. 1480 If security blocks and their target blocks are repeated in 1481 multiple fragments, policy needs to determine how to deal with 1482 issues where a security operation verifies in one fragment but 1483 fails in another fragment. This might happen, for example, if a 1484 BIB block becomes corrupted in one fragment but not in another 1485 fragment. 1487 Implementors should consider how security blocks are processed when a 1488 BPA fragments a received bundle. For example, security blocks and 1489 their targets could be placed in the same fragment if the security 1490 block is not otherwise cryptographically bound to the bundle being 1491 fragmented. Alternatively, if security blocks are cryptographically 1492 bound to a bundle, then a fragmenting BPA should consider 1493 encapsulating the bundle first and then fragmenting the encapsulating 1494 bundle. 1496 7. Normative References 1498 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 1499 Recommendation for Block Cipher Modes of Operation: 1500 Galois/Counter Mode (GCM) and GMAC.", November 2007. 1502 [I-D.ietf-dtn-bpbis] 1503 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1504 Version 7", draft-ietf-dtn-bpbis-31 (work in progress), 1505 January 2021. 1507 [I-D.ietf-dtn-bpsec] 1508 Birrane, E. and K. McKeever, "Bundle Protocol Security 1509 Specification", draft-ietf-dtn-bpsec-27 (work in 1510 progress), February 2021. 1512 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1513 Hashing for Message Authentication", RFC 2104, 1514 DOI 10.17487/RFC2104, February 1997, 1515 . 1517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1518 Requirement Levels", BCP 14, RFC 2119, 1519 DOI 10.17487/RFC2119, March 1997, 1520 . 1522 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1523 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1524 DOI 10.17487/RFC5649, September 2009, 1525 . 1527 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1528 Writing an IANA Considerations Section in RFCs", BCP 26, 1529 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1530 . 1532 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1533 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1534 . 1536 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1537 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1538 May 2017, . 1540 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1541 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1542 . 1544 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1545 Representation (CBOR)", STD 94, RFC 8949, 1546 DOI 10.17487/RFC8949, December 2020, 1547 . 1549 [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- 1550 180-4, Gaithersburg, MD, USA, August 2015. 1552 https://csrc.nist.gov/publications/detail/fips/180/4/final 1554 Appendix A. Examples 1556 This appendix is informative. 1558 This section presents a series of examples of constructing BPSec 1559 security blocks (using the security contexts defined in this 1560 document) and adding those blocks to a sample bundle. 1562 The examples presented in this appendix represent valid constructions 1563 of bundles, security blocks, and the encoding of security context 1564 parameters and results. For this reason, they can inform unit test 1565 suites for individual implementations as well as interoperability 1566 test suites amongst implementations. However, these examples do not 1567 cover every permutation of security parameters, security results, or 1568 use of security blocks in a bundle. 1570 NOTE: The bundle diagrams in this section are patterned after the 1571 bundle diagrams used in [I-D.ietf-dtn-bpsec] Section 3.11 "BSP Block 1572 Examples". 1574 NOTE: Figures in this section identified as "(CBOR Diagnostic 1575 Notation)" are represented using the CBOR diagnostic notation defined 1576 in [RFC8949]. This notation is used to express CBOR data structures 1577 in a manner that enables visual inspection. The bundles, security 1578 blocks, and security context contents in these figures are 1579 represented using CBOR structures. In cases where BP blocks (to 1580 include BPSec security blocks) are comprised of a sequence of CBOR 1581 objects, these objects are represented as a CBOR sequence as defined 1582 in [RFC8742]. 1584 NOTE: Examples in this section use the "ipn" URI scheme for 1585 EndpointID naming, as defined in [I-D.ietf-dtn-bpbis]. 1587 NOTE: The bundle source is presumed to be the security source for all 1588 security blocks in this section, unless otherwise noted. 1590 A.1. Example 1: Simple Integrity 1592 This example shows the addition of a BIB to a sample bundle to 1593 provide integrity for the payload block. 1595 A.1.1. Original Bundle 1597 The following diagram shows the original bundle before the BIB has 1598 been added. 1600 Block Block Block 1601 in Bundle Type Number 1602 +========================================+=======+========+ 1603 | Primary Block | N/A | 0 | 1604 +----------------------------------------+-------+--------+ 1605 | Payload Block | 1 | 1 | 1606 +----------------------------------------+-------+--------+ 1608 Figure 1: Example 1 Original Bundle 1610 A.1.1.1. Primary Block 1612 The BPv7 bundle has no special processing flags and no CRC is 1613 provided because the primary block is expected to be protected by an 1614 integrity service BIB using the BIB-HMAC-SHA2 security context. 1616 The bundle is sourced at the source node ipn:2.1 and destined for the 1617 destination node ipn:1.2. The bundle creation time uses a DTN 1618 creation time of 0 indicating lack of an accurate clock and a 1619 sequence number of 40. The lifetime of the bundle is given as 1620 1,000,000 milliseconds since the bundle creation time. 1622 The primary block is provided as follows. 1624 [ 1625 7, / BP version / 1626 0, / flags / 1627 0, / CRC type / 1628 [2, [1,2]], / destination (ipn:1.2) / 1629 [2, [2,1]], / source (ipn:2.1) / 1630 [2, [2,1]], / report-to (ipn:2.1) / 1631 [0, 40], / timestamp / 1632 1000000 / lifetime / 1633 ] 1635 Figure 2: Primary Block (CBOR Diagnostic Notation) 1637 The CBOR encoding of the primary block is 1638 0x88070000820282010282028202018202820201820018281a000f4240. 1640 A.1.1.2. Payload Block 1642 Other than its use as a source of plaintext for security blocks, the 1643 payload has no required distinguishing characteristic for the purpose 1644 of this example. The sample payload is a 32 byte string whose value 1645 is "Ready Generate a 32 byte payload". 1647 The payload is represented in the payload block as a byte string of 1648 the raw payload string. It is NOT represented as a CBOR text string 1649 wrapped within a CBOR binary string. The hex value of the payload 1650 "Ready Generate a 32 byte payload" is 1651 0x52656164792047656e657261746520612033322062797465207061796c6f6164. 1653 The payload block is provided as follows. 1655 [ 1656 1, / type code: Payload block / 1657 1, / block number / 1658 0, / block processing flags / 1659 0, / CRC Type / 1660 h'52656164792047656e65726174652061 / type-specific-data: payload / 1661 2033322062797465207061796c6f6164' 1662 ] 1664 Payload Block (CBOR Diagnostic Notation) 1666 The CBOR encoding of the payload block is 0x8501010000582052656164792 1667 047656e657261746520612033322062797465207061796c6f6164. 1669 A.1.1.3. Bundle CBOR Representation 1671 A BPv7 bundle is represented as an indefinite-length array consisting 1672 of the blocks comprising the bundle, with a terminator character at 1673 the end. 1675 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1676 28202018202820201820018281a000f42408501010000582052656164792047656e65 1677 7261746520612033322062797465207061796c6f6164ff. 1679 A.1.2. Security Operation Overview 1681 This example adds a BIB to the bundle using the BIB-HMAC-SHA2 1682 security context to provide an integrity mechanism over the payload 1683 block. 1685 The following diagram shows the resulting bundle after the BIB is 1686 added. 1688 Block Block Block 1689 in Bundle Type Number 1690 +========================================+=======+========+ 1691 | Primary Block | N/A | 0 | 1692 +----------------------------------------+-------+--------+ 1693 | Bundle Integrity Block | 11 | 2 | 1694 | OP(bib-integrity, target=1) | | | 1695 +----------------------------------------+-------+--------+ 1696 | Payload Block | 1 | 1 | 1697 +----------------------------------------+-------+--------+ 1699 Figure 3: Example 1 Resulting Bundle 1701 A.1.3. Bundle Integrity Block 1703 In this example, a BIB is used to carry an integrity signature over 1704 the payload block. 1706 A.1.3.1. Configuration, Parameters, and Results 1708 For this example, the following configuration and security parameters 1709 are used to generate the security results indicated. 1711 This BIB has a single target and includes a single security result: 1712 the calculated signature over the payload block. 1714 Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 1715 SHA Variant : HMAC 512/512 1716 Scope Flags : 0x00 1717 Payload Data: h'52656164792047656e65726174652061 1718 2033322062797465207061796c6f6164' 1719 Signature : h'0654d65992803252210e377d66d0a8dc 1720 18a1e8a392269125ae9ac198a9a598be 1721 4b83d5daa8be2f2d16769ec1c30cfc34 1722 8e2205fba4b3be2b219074fdd5ea8ef0' 1724 Figure 4: Example 1: Configuration, Parameters, and Results 1726 A.1.3.2. Abstract Security Block 1728 The abstract security block structure of the BIB's block-type- 1729 specific-data field for this application is as follows. 1731 [1], / Security Target - Payload block / 1732 1, / Security Context ID - BIB-HMAC-SHA2 / 1733 1, / Security Context Flags - Parameters Present / 1734 [2,[2, 1]], / Security Source - ipn:2.1 / 1735 [ / Security Parameters - 2 Parameters / 1736 [1, 7], / SHA Variant - HMAC 512/512 / 1737 [3, 0x00] / Scope Flags - No Additional Scope / 1738 ], 1739 [ / Security Results: 1 Result / 1740 [1, h'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b 1741 e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0'] 1742 ] 1744 Figure 5: Example 1: BIB Abstract Security Block (CBOR Diagnostic 1745 Notation) 1747 The CBOR encoding of the BIB block-type-specific-data field (the 1748 abstract security block) is 0x810101018202820201828201078203008182015 1749 8400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b 1750 83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0. 1752 A.1.3.3. Representations 1754 The BIB wrapping this abstract security block is as follows. 1756 [ 1757 11, / type code / 1758 2, / block number / 1759 0, / flags / 1760 0, / CRC type / 1761 h'8101010182028202018282010782030081820158400654d65992803252210e377d66 1762 d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34 1763 8e2205fba4b3be2b219074fdd5ea8ef0', 1764 ] 1766 Figure 6: Example 1: BIB (CBOR Diagnostic Notation) 1768 The CBOR encoding of the BIB block is 0x850b0200005855810101018202820 1769 2018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392 1770 269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2 1771 b219074fdd5ea8ef0. 1773 A.1.4. Final Bundle 1775 The CBOR encoding of the full output bundle, with the BIB: 0x9f880700 1776 00820282010282028202018202820201820018281a000f4240850b020000585581010 1777 10182028202018282010782030081820158400654d65992803252210e377d66d0a8dc 1778 18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e220 1779 5fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e6572617465 1780 20612033322062797465207061796c6f6164ff. 1782 A.2. Example 2: Simple Confidentiality with Key Wrap 1784 This example shows the addition of a BCB to a sample bundle to 1785 provide confidentiality for the payload block. AES key wrap is used 1786 to transmit the symmetric key used to generate the security results 1787 for this service. 1789 A.2.1. Original Bundle 1791 The following diagram shows the original bundle before the BCB has 1792 been added. 1794 Block Block Block 1795 in Bundle Type Number 1796 +========================================+=======+========+ 1797 | Primary Block | N/A | 0 | 1798 +----------------------------------------+-------+--------+ 1799 | Payload Block | 1 | 1 | 1800 +----------------------------------------+-------+--------+ 1802 Figure 7: Example 2 Original Bundle 1804 A.2.1.1. Primary Block 1806 The primary block used in this example is identical to the primary 1807 block presented in Example 1 Appendix A.1.1.1. 1809 In summary, the CBOR encoding of the primary block is 1810 0x88070000820282010282028202018202820201820018281a000f4240. 1812 A.2.1.2. Payload Block 1814 The payload block used in this example is identical to the payload 1815 block presented in Example 1 Appendix A.1.1.2. 1817 In summary, the CBOR encoding of the payload block is 0x8501010000582 1818 052656164792047656e657261746520612033322062797465207061796c6f6164. 1820 A.2.1.3. Bundle CBOR Representation 1822 A BPv7 bundle is represented as an indefinite-length array consisting 1823 of the blocks comprising the bundle, with a terminator character at 1824 the end. 1826 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1827 28202018202820201820018281a000f42408501010000582052656164792047656e65 1828 7261746520612033322062797465207061796c6f6164ff. 1830 A.2.2. Security Operation Overview 1832 This example adds a BCB using the BCB-AES-GCM security context using 1833 AES key wrap to provide a confidentiality mechanism over the payload 1834 block and transmit the symmetric key. 1836 The following diagram shows the resulting bundle after the BCB is 1837 added. 1839 Block Block Block 1840 in Bundle Type Number 1841 +========================================+=======+========+ 1842 | Primary Block | N/A | 0 | 1843 +----------------------------------------+-------+--------+ 1844 | Bundle Confidentiality Block | 12 | 2 | 1845 | OP(bcb-confidentiality, target=1) | | | 1846 +----------------------------------------+-------+--------+ 1847 | Payload Block (Encrypted) | 1 | 1 | 1848 +----------------------------------------+-------+--------+ 1850 Figure 8: Example 2 Resulting Bundle 1852 A.2.3. Bundle Confidentiality Block 1854 In this example, a BCB is used to encrypt the payload block and uses 1855 AES key wrap to transmit the symmetric key. 1857 A.2.3.1. Configuration, Parameters, and Results 1859 For this example, the following configuration and security parameters 1860 are used to generate the security results indicated. 1862 This BCB has a single target, the payload block. Three security 1863 results are generated: cipher text which replaces the plain text 1864 block-type-specific data to encrypt the payload block, an 1865 authentication tag, and the AES wrapped key. 1867 Content Encryption 1868 Key: h'71776572747975696f70617364666768' 1869 Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' 1870 IV: h'5477656c7665313231323132' 1871 AES Variant: A128GCM 1872 AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 1873 96fabf34d7fae700' 1874 Scope Flags: 0x00 1875 Payload Data: h'52656164792047656e65726174652061 1876 2033322062797465207061796c6f6164' 1877 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 1878 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 1879 a563e32648b700c2784e26a990d91f9d' 1881 Figure 9: Example 2: Configuration, Parameters, and Results 1883 A.2.3.2. Abstract Security Block 1885 The abstract security block structure of the BCB's block-type- 1886 specific-data field for this application is as follows. 1888 [1], / Security Target - Payload block / 1889 2, / Security Context ID - BCB-AES-GCM / 1890 1, / Security Context Flags - Parameters Present / 1891 [2,[2, 1]], / Security Source - ipn:2.1 / 1892 [ / Security Parameters - 4 Parameters / 1893 [1, h'5477656c7665313231323132'], / Initialization Vector / 1894 [2, 1], / AES Variant - A128GCM / 1895 [3, h'69c411276fecddc4780df42c8a / AES wrapped key / 1896 2af89296fabf34d7fae700'], 1897 [4, 0x00] / Scope Flags - No extra scope/ 1898 ], 1899 [ / Security Results: 1 Result / 1900 [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / 1901 ] 1903 Figure 10: Example 2: BCB Abstract Security Block (CBOR Diagnostic 1904 Notation) 1906 The CBOR encoding of the BCB block-type-specific-data field (the 1907 abstract security block) is 0x8101020182028202018482014c5477656c76653 1908 132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa 1909 e70082040081820150da08f4d8936024ad7c6b3b800e73dd97. 1911 A.2.3.3. Representations 1913 The BCB wrapping this abstract security block is as follows. 1915 [ 1916 12, / type code / 1917 2, / block number / 1918 1, / flags - block must be replicated in every fragment / 1919 0, / CRC type / 1920 h'8101020182028202018482014c5477656c766531323132313282020182035818 1921 69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da 1922 08f4d8936024ad7c6b3b800e73dd97' 1923 ] 1925 Figure 11: Example 2: BCB (CBOR Diagnostic Notation) 1927 The CBOR encoding of the BCB block is 0x850c020100584f810102018202820 1928 2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d 1929 f42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e7 1930 3dd97. 1932 A.2.4. Final Bundle 1934 The CBOR encoding of the full output bundle, with the BCB: 0x9f880700 1935 00820282010282028202018202820201820018281a000f4240850c020100584f81010 1936 20182028202018482014c5477656c76653132313231328202018203581869c411276f 1937 ecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7 1938 c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e326 1939 48b700c2784e26a990d91f9dff. 1941 A.3. Example 3: Security Blocks from Multiple Sources 1943 This example shows the addition of a BIB and BCB to a sample bundle. 1944 These two security blocks are added by two different nodes. The BCB 1945 is added by the source endpoint and the BIB is added by a forwarding 1946 node. 1948 The resulting bundle contains a BCB to encrypt the Payload Block and 1949 a BIB to provide integrity to the Primary and Bundle Age Block. 1951 A.3.1. Original Bundle 1953 The following diagram shows the original bundle before the security 1954 blocks have been added. 1956 Block Block Block 1957 in Bundle Type Number 1958 +========================================+=======+========+ 1959 | Primary Block | N/A | 0 | 1960 +----------------------------------------+-------+--------+ 1961 | Extension Block: Bundle Age Block | 7 | 2 | 1962 +----------------------------------------+-------+--------+ 1963 | Payload Block | 1 | 1 | 1964 +----------------------------------------+-------+--------+ 1966 Figure 12: Example 3 Original Bundle 1968 A.3.1.1. Primary Block 1970 The primary block used in this example is identical to the primary 1971 block presented in Example 1 Appendix A.1.1.1. 1973 In summary, the CBOR encoding of the primary block is 1974 0x88070000820282010282028202018202820201820018281a000f4240. 1976 A.3.1.2. Bundle Age Block 1978 A bundle age block is added to the bundle to help other nodes in the 1979 network determine the age of the bundle. The use of this block is as 1980 recommended because the bundle source does not have an accurate clock 1981 (as indicated by the DTN time of 0). 1983 Because this block is specified at the time the bundle is being 1984 forwarded, the bundle age represents the time that has elapsed from 1985 the time the bundle was created to the time it is being prepared for 1986 forwarding. In this case, the value is given as 300 milliseconds. 1988 The bundle age extension block is provided as follows. 1990 [ 1991 7, / type code: Bundle Age block / 1992 2, / block number / 1993 0, / block processing flags / 1994 0, / CRC Type / 1995 <<300>> / type-specific-data: age / 1996 ] 1998 Figure 13: Bundle Age Block (CBOR Diagnostic Notation) 2000 The CBOR encoding of the bundle age block is 0x85070200004319012c. 2002 A.3.1.3. Payload Block 2004 The payload block used in this example is identical to the payload 2005 block presented in Example 1 Appendix A.1.1.2. 2007 In summary, the CBOR encoding of the payload block is 0x8501010000582 2008 052656164792047656e657261746520612033322062797465207061796c6f6164. 2010 A.3.1.4. Bundle CBOR Representation 2012 A BPv7 bundle is represented as an indefinite-length array consisting 2013 of the blocks comprising the bundle, with a terminator character at 2014 the end. 2016 The CBOR encoding of the original bundle is 0x9f880700008202820102820 2017 28202018202820201820018281a000f424085070200004319012c8501010000582052 2018 656164792047656e657261746520612033322062797465207061796c6f6164ff. 2020 A.3.2. Security Operation Overview 2022 This example provides: 2024 a BIB with the BIB-HMAC-SHA2 security context to provide an 2025 integrity mechanism over the primary block and bundle age block. 2027 a BCB with the BCB-AES-GCM security context to provide a 2028 confidentiality mechanism over the payload block. 2030 The following diagram shows the resulting bundle after the security 2031 blocks are added. 2033 Block Block Block 2034 in Bundle Type Number 2035 +========================================+=======+========+ 2036 | Primary Block | N/A | 0 | 2037 +----------------------------------------+-------+--------+ 2038 | Bundle Integrity Block | 11 | 3 | 2039 | OP(bib-integrity, targets=0, 2) | | | 2040 +----------------------------------------+-------+--------+ 2041 | Bundle Confidentiality Block | 12 | 4 | 2042 | OP(bcb-confidentiality, target=1) | | | 2043 +----------------------------------------+-------+--------+ 2044 | Extension Block: Bundle Age Block | 7 | 2 | 2045 +----------------------------------------+-------+--------+ 2046 | Payload Block (Encrypted) | 1 | 1 | 2047 +----------------------------------------+-------+--------+ 2049 Figure 14: Example 3 Resulting Bundle 2051 A.3.3. Bundle Integrity Block 2053 In this example, a BIB is used to carry an integrity signature over 2054 the bundle age block and an additional signature over the payload 2055 block. The BIB is added by a waypoint node, ipn:3.0. 2057 A.3.3.1. Configuration, Parameters, and Results 2059 For this example, the following configuration and security parameters 2060 are used to generate the security results indicated. 2062 This BIB has two security targets and includes two security results, 2063 holding the calculated signatures over the bundle age block and 2064 primary block. 2066 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2067 SHA Variant: HMAC 256/256 2068 Scope Flags: 0x00 2069 Primary Block Data: h'88070000820282010282028202018202 2070 820201820018281a000f4240' 2071 Bundle Age Block 2072 Data: h'85070200004319012c' 2073 Primary Block 2074 Signature: h'8e059b8e71f7218264185a666bf3e453 2075 076f2b883f4dce9b3cdb6464ed0dcf0f' 2076 Bundle Age Block 2077 Signature: h'72dee8eba049a22978e84a95d0496466 2078 8eb131b1ca4800c114206d70d9065c80' 2080 Figure 15: Example 3: Configuration, Parameters, and Results for the 2081 BIB 2083 A.3.3.2. Abstract Security Block 2085 The abstract security block structure of the BIB's block-type- 2086 specific-data field for this application is as follows. 2088 [0, 2], / Security Targets / 2089 1, / Security Context ID - BIB-HMAC-SHA2 / 2090 1, / Security Context Flags - Parameters Present / 2091 [2,[3, 0]], / Security Source - ipn:3.0 / 2092 [ / Security Parameters - 2 Parameters / 2093 [1, 5], / SHA Variant - HMAC 256/256 / 2094 [3, 0x00] / Scope Flags - No Additional Scope / 2095 ], 2096 [ / Security Results: 2 Results / 2097 [1, h'8e059b8e71f7218264185a666bf3e453 2098 076f2b883f4dce9b3cdb6464ed0dcf0f'], / Primary Block / 2099 [1, h'72dee8eba049a22978e84a95d0496466 2100 8eb131b1ca4800c114206d70d9065c80'] / Bundle Age Block / 2101 ] 2103 Figure 16: Example 3: BIB Abstract Security Block (CBOR Diagnostic 2104 Notation) 2106 The CBOR encoding of the BIB block-type-specific-data field (the 2107 abstract security block) is 0x820002010182028203008282010582030082820 2108 158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f 2109 8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065 2110 c80. 2112 A.3.3.3. Representations 2114 The BIB wrapping this abstract security block is as follows. 2116 [ 2117 11, / type code / 2118 3, / block number / 2119 0, / flags / 2120 0, / CRC type / 2121 h'820002010182028203008282010582030082820158208e059b8e71f721826418 2122 5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049 2123 a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80', 2124 ] 2126 Figure 17: Example 3: BIB (CBOR Diagnostic Notation) 2128 The CBOR encoding of the BIB block is 0x850b030000585a820002010182028 2129 203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b88 2130 3f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb13 2131 1b1ca4800c114206d70d9065c80. 2133 A.3.4. Bundle Confidentiality Block 2135 In this example, a BCB is used encrypt the payload block. The BCB is 2136 added by the bundle source node, ipn:2.1. 2138 A.3.4.1. Configuration, Parameters, and Results 2140 For this example, the following configuration and security parameters 2141 are used to generate the security results indicated. 2143 This BCB has a single target, the payload block. Two security 2144 results are generated: cipher text which replaces the plain text 2145 block-type-specific data to encrypt the payload block, and an 2146 authentication tag. 2148 Content Encryption 2149 Key: h'71776572747975696f70617364666768' 2150 IV: h'5477656c7665313231323132' 2151 AES Variant: A128GCM 2152 Scope Flags: 0x00 2153 Payload Data: h'52656164792047656e65726174652061 2154 2033322062797465207061796c6f6164' 2155 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 2156 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 2157 a563e32648b700c2784e26a990d91f9d' 2159 Figure 18: Example 3: Configuration, Parameters, and Results for the 2160 BCB 2162 A.3.4.2. Abstract Security Block 2164 The abstract security block structure of the BCB's block-type- 2165 specific-data field for this application is as follows. 2167 [1], / Security Target - Payload block / 2168 2, / Security Context ID - BCB-AES-GCM / 2169 1, / Security Context Flags - Parameters Present / 2170 [2,[2, 1]], / Security Source - ipn:2.1 / 2171 [ / Security Parameters - 3 Parameters / 2172 [1, h'5477656c7665313231323132'], / Initialization Vector / 2173 [2, 1], / AES Variant - AES 128 / 2174 [4, 0x00] / Scope Flags - No Additional Scope / 2175 ], 2176 [ / Security Results: 1 Result / 2177 [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / 2178 ] 2180 Figure 19: Example 3: BCB Abstract Security Block (CBOR Diagnostic 2181 Notation) 2183 The CBOR encoding of the BCB block-type-specific-data field (the 2184 abstract security block) is 0x8101020182028202018382014c5477656c76653 2185 1323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97. 2187 A.3.4.3. Representations 2189 The BCB wrapping this abstract security block is as follows. 2191 [ 2192 12, / type code / 2193 4, / block number / 2194 1, / flags - block must be replicated in every fragment / 2195 0, / CRC type / 2196 h'8101020182028202018382014c5477656c766531323132313282020182040081 2197 820150da08f4d8936024ad7c6b3b800e73dd97', 2198 ] 2200 Figure 20: Example 3: BCB (CBOR Diagnostic Notation) 2202 The CBOR encoding of the BCB block is 0x850c0401005833810102018202820 2203 2018382014c5477656c766531323132313282020182040081820150da08f4d8936024 2204 ad7c6b3b800e73dd97. 2206 A.3.5. Final Bundle 2208 The CBOR encoding of the full output bundle, with the BIB and BCB 2209 added is: 0x9f88070000820282010282028202018202820201820018281a000f424 2210 0850b030000585a820002010182028203008282010582030082820158208e059b8e71 2211 f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8e 2212 ba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058 2213 338101020182028202018382014c5477656c766531323132313282020182040081820 2214 150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a 2215 09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff. 2217 A.4. Example 4: Security Blocks with Full Scope 2219 This example shows the addition of a BIB and BCB to a sample bundle. 2220 A BIB is added to provide integrity over the payload block and a BCB 2221 is added for confidentiality over the payload and BIB. 2223 The integrity scope and additional authentication data will bind the 2224 primary block, target header, and the security header. 2226 A.4.1. Original Bundle 2228 The following diagram shows the original bundle before the security 2229 blocks have been added. 2231 Block Block Block 2232 in Bundle Type Number 2233 +========================================+=======+========+ 2234 | Primary Block | N/A | 0 | 2235 +----------------------------------------+-------+--------+ 2236 | Payload Block | 1 | 1 | 2237 +----------------------------------------+-------+--------+ 2239 Figure 21: Example 4 Original Bundle 2241 A.4.1.1. Primary Block 2243 The primary block used in this example is identical to the primary 2244 block presented in Example 1 Appendix A.1.1.1. 2246 In summary, the CBOR encoding of the primary block is 2247 0x88070000820282010282028202018202820201820018281a000f4240. 2249 A.4.1.2. Payload Block 2251 The payload block used in this example is identical to the payload 2252 block presented in Example 1 Appendix A.1.1.2. 2254 In summary, the CBOR encoding of the payload block is 0x8501010000582 2255 052656164792047656e657261746520612033322062797465207061796c6f6164. 2257 A.4.1.3. Bundle CBOR Representation 2259 A BPv7 bundle is represented as an indefinite-length array consisting 2260 of the blocks comprising the bundle, with a terminator character at 2261 the end. 2263 The CBOR encoding of the original bundle is 0x9f880700008202820102820 2264 28202018202820201820018281a000f42408501010000582052656164792047656e65 2265 7261746520612033322062797465207061796c6f6164ff. 2267 A.4.2. Security Operation Overview 2269 This example provides: 2271 a BIB with the BIB-HMAC-SHA2 security context to provide an 2272 integrity mechanism over the payload block. 2274 a BCB with the BCB-AES-GCM security context to provide a 2275 confidentiality mechanism over the payload block and BIB. 2277 The following diagram shows the resulting bundle after the security 2278 blocks are added. 2280 Block Block Block 2281 in Bundle Type Number 2282 +========================================+=======+========+ 2283 | Primary Block | N/A | 0 | 2284 +----------------------------------------+-------+--------+ 2285 | Bundle Integrity Block (Encrypted) | 11 | 3 | 2286 | OP(bib-integrity, target=1) | | | 2287 +----------------------------------------+-------+--------+ 2288 | Bundle Confidentiality Block | 12 | 2 | 2289 | OP(bcb-confidentiality, targets=1, 3) | | | 2290 +----------------------------------------+-------+--------+ 2291 | Payload Block (Encrypted) | 1 | 1 | 2292 +----------------------------------------+-------+--------+ 2294 Figure 22: Example 4 Resulting Bundle 2296 A.4.3. Bundle Integrity Block 2298 In this example, a BIB is used to carry an integrity signature over 2299 the payload block. The IPPT contains the payload block block-type- 2300 specific data, primary block data, the payload block header, and the 2301 BIB header. That is, all additional headers are included in the 2302 IPPT. 2304 A.4.3.1. Configuration, Parameters, and Results 2306 For this example, the following configuration and security parameters 2307 are used to generate the security results indicated. 2309 This BIB has a single target and includes a single security result: 2310 the calculated signature over the Payload block. 2312 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2313 SHA Variant: HMAC 384/384 2314 Scope Flags: 0x07 (all additional headers) 2315 Primary Block Data: h'88070000820282010282028202018202 2316 820201820018281a000f4240 2317 Payload Data: h'52656164792047656e65726174652061 2318 2033322062797465207061796c6f6164' 2319 Payload Header: h'85010100005820' 2320 BIB Header: h'850b0300005845' 2321 Payload Signature: h'07c84d929f83bee4690130729d77a1bd 2322 da9611cd6598e73d0659073ea74e8c27 2323 523b02193cb8ba64be58dbc556887aca 2325 Figure 23: Example 4: Configuration, Parameters, and Results for the 2326 BIB 2328 A.4.3.2. Abstract Security Block 2330 The abstract security block structure of the BIB's block-type- 2331 specific-data field for this application is as follows. 2333 [1], / Security Target - Payload block / 2334 1, / Security Context ID - BIB-HMAC-SHA2 / 2335 1, / Security Context Flags - Parameters Present / 2336 [2,[2, 1]], / Security Source - ipn:2.1 / 2337 [ / Security Parameters - 2 Parameters / 2338 [1, 6], / SHA Variant - HMAC 384/384 / 2339 [3, 0x07] / Scope Flags - All additional headers in the SHA Hash / 2340 ], 2341 [ / Security Results: 1 Result / 2342 [1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d 2343 0659073ea74e8c27523b02193cb8ba64be58dbc556887aca'] 2344 ] 2346 Figure 24: Example 4: BIB Abstract Security Block (CBOR Diagnostic 2347 Notation) 2349 The CBOR encoding of the BIB block-type-specific-data field (the 2350 abstract security block) is 0x810101018202820201828201068203078182015 2351 83007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c2752 2352 3b02193cb8ba64be58dbc556887aca. 2354 A.4.3.3. Representations 2356 The BIB wrapping this abstract security block is as follows. 2358 [ 2359 11, / type code / 2360 3, / block number / 2361 0, / flags / 2362 0, / CRC type / 2363 h'81010101820282020182820106820307818201583007c84d929f83bee4690130 2364 729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db 2365 c556887aca', 2366 ] 2368 Figure 25: Example 4: BIB (CBOR Diagnostic Notation) 2370 The CBOR encoding of the BIB block is 0x850b0300005845810101018202820 2371 20182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd65 2372 98e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca. 2374 A.4.4. Bundle Confidentiality Block 2376 In this example, a BCB is used encrypt the payload block and the BIB 2377 that provides integrity over the payload. 2379 A.4.4.1. Configuration, Parameters, and Results 2381 For this example, the following configuration and security parameters 2382 are used to generate the security results indicated. 2384 This BCB has two targets: the payload block and BIB. Four security 2385 results are generated: cipher text which replaces the plain text 2386 block-type-specific data of the payload block, cipher text to encrypt 2387 the BIB, and authentication tags for both the payload block and BIB. 2389 Key: h'71776572747975696f70617364666768 2390 71776572747975696f70617364666768' 2391 IV: h'5477656c7665313231323132' 2392 AES Variant: A256GCM 2393 Scope Flags: 0x07 (All additional headers) 2394 Payload Data: h'52656164792047656e65726174652061 2395 2033322062797465207061796c6f6164' 2396 BIB Data: h'81010101820282020182820106820307 2397 818201583007c84d929f83bee4690130 2398 729d77a1bdda9611cd6598e73d065907 2399 3ea74e8c27523b02193cb8ba64be58db 2400 c556887aca 2401 BIB 2402 Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e' 2403 Payload Block 2404 Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff' 2405 Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 2406 319bb227706000abc8fcac3b9bb9c87e' 2407 BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 2408 902a815f221ebc837a134efc13bfa82a 2409 2d5d317747da3eb54acef4ca839bd961 2410 487284404259b60be12b8aed2f3e8a36 2411 2836529f66' 2413 Figure 26: Example 4: Configuration, Parameters, and Results for the 2414 BCB 2416 A.4.4.2. Abstract Security Block 2418 The abstract security block structure of the BCB's block-type- 2419 specific-data field for this application is as follows. 2421 [3, 1], / Security Targets / 2422 2, / Security Context ID - BCB-AES-GCM / 2423 1, / Security Context Flags - Parameters Present / 2424 [2,[2, 1]], / Security Source - ipn:2.1 / 2425 [ / Security Parameters - 3 Parameters / 2426 [1, h'5477656c7665313231323132'], / Initialization Vector / 2427 [2, 3], / AES Variant - AES 256 / 2428 [4, 0x07] / Scope Flags - All headers in SHA hash / 2429 ], 2430 [ / Security Results: 2 Results / 2431 [1, h'c95ed4534769b046d716e1cdfd00830e'], / BIB Auth. Tag / 2432 [1, h'0e365c700e4bb19c0d991faff5345aff'] / Payload Auth. Tag / 2433 ] 2435 Figure 27: Example 4: BCB Abstract Security Block (CBOR Diagnostic 2436 Notation) 2438 The CBOR encoding of the BCB block-type-specific-data field (the 2439 abstract security block) is 0x820301020182028202018382014c5477656c766 2440 531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201 2441 500e365c700e4bb19c0d991faff5345aff. 2443 A.4.4.3. Representations 2445 The BCB wrapping this abstract security block is as follows. 2447 [ 2448 12, / type code / 2449 2, / block number / 2450 1, / flags - block must be replicated in every fragment / 2451 0, / CRC type / 2452 h'820301020182028202018382014c5477656c7665313231323132820203820407 2453 82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d 2454 991faff5345aff', 2455 ] 2457 Figure 28: Example 4: BCB (CBOR Diagnostic Notation) 2459 The CBOR encoding of the BCB block is 0x850c0201005847820301020182028 2460 202018382014c5477656c766531323132313282020382040782820150c95ed4534769 2461 b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. 2463 A.4.5. Final Bundle 2465 The CBOR encoding of the full output bundle, with the security blocks 2466 added and payload block and BIB encrypted is: 0x9f8807000082028201028 2467 2028202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb9 2468 4d952175167df0902a815f221ebc837a134efc13bfa82a2d5d317747da3eb54acef4c 2469 a839bd961487284404259b60be12b8aed2f3e8a362836529f66 850c0201005847820 2470 301020182028202018382014c5477656c766531323132313282020382040782820150 2471 c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345af 2472 f8501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac 2473 3b9bb9c87eff. 2475 Appendix B. Acknowledgements 2477 Amy Alford of the Johns Hopkins University Applied Physics Laboratory 2478 contributed useful review and analysis of these security contexts. 2480 Authors' Addresses 2481 Edward J. Birrane, III 2482 The Johns Hopkins University Applied 2483 Physics Laboratory 2484 11100 Johns Hopkins Rd. 2485 Laurel, MD 20723 2486 US 2488 Phone: +1 443 778 7423 2489 Email: Edward.Birrane@jhuapl.edu 2491 Alex White 2492 The Johns Hopkins University Applied 2493 Physics Laboratory 2494 11100 Johns Hopkins Rd. 2495 Laurel, MD 20723 2496 US 2498 Phone: +1 443 778 0845 2499 Email: Alex.White@jhuapl.edu 2501 Sarah Heiner 2502 The Johns Hopkins University Applied 2503 Physics Laboratory 2504 11100 Johns Hopkins Rd. 2505 Laurel, MD 20723 2506 US 2508 Phone: +1 240 592 3704 2509 Email: Sarah.Heiner@jhuapl.edu