idnits 2.17.1 draft-ietf-dtn-bpsec-default-sc-09.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 8, 2021) is 1022 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 2085 -- Looks like a reference, but probably isn't: '40' on line 1628 -- Looks like a reference, but probably isn't: '1' on line 2418 -- Looks like a reference, but probably isn't: '7' on line 1733 -- Looks like a reference, but probably isn't: '2' on line 2424 -- Looks like a reference, but probably isn't: '5' on line 2090 -- Looks like a reference, but probably isn't: '6' on line 2335 -- Looks like a reference, but probably isn't: '3' on line 2424 -- 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 (~~), 1 warning (==), 11 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 9, 2022 JHU/APL 6 July 8, 2021 8 BPSec Default Security Contexts 9 draft-ietf-dtn-bpsec-default-sc-09 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 9, 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 . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . 23 89 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 23 90 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 25 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 5.1. Security Context Identifiers . . . . . . . . . . . . . . 26 93 5.2. Integrity Scope Flags . . . . . . . . . . . . . . . . . . 27 94 5.3. AAD Scope Flags . . . . . . . . . . . . . . . . . . . . . 27 95 5.4. Guidance for Designated Experts . . . . . . . . . . . . . 28 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 97 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 29 98 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 30 99 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 31 101 6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 32 102 7. Normative References . . . . . . . . . . . . . . . . . . . . 32 103 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 34 104 A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 34 105 A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 34 106 A.1.2. Security Operation Overview . . . . . . . . . . . . . 36 107 A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 37 108 A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 38 109 A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 39 110 A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 39 111 A.2.2. Security Operation Overview . . . . . . . . . . . . . 40 112 A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 40 113 A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 42 114 A.3. Example 3: Security Blocks from Multiple Sources . . . . 42 115 A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 42 116 A.3.2. Security Operation Overview . . . . . . . . . . . . . 44 117 A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 45 118 A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 47 119 A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 48 120 A.4. Example 4: Security Blocks with Full Scope . . . . . . . 49 121 A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 49 122 A.4.2. Security Operation Overview . . . . . . . . . . . . . 50 123 A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 50 124 A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 52 125 A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 54 126 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 54 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 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 bit field. 339 Integrity scope flags that are unrecognized MUST be ignored, as 340 future definitions of additional flags might not be integrated 341 simultaneously into security context implementations operating at all 342 nodes. 344 Implementations MUST set reserved and unassigned bits in this field 345 to 0 when constructing these flags at a security source. Once set, 346 the value of this field MUST NOT be altered until the security 347 service is completed at the security acceptor in the network and 348 removed from the bundle. 350 Bits in this field represent additional information to be included 351 when generating an integrity signature over the security target. 352 These bits are defined as follows. 354 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 356 - Bit 1 (0x0002): Target Header Flag. 358 - Bit 2 (0x0004): Security Header Flag. 360 - Bits 3-7 are reserved. 362 - Bits 8-15 are unassigned. 364 3.3.4. Enumerations 366 The BIB-HMAC-SHA2 security context parameters are listed in Table 2. 367 In this table, the "Parm Id" column refers to the expected Parameter 368 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 369 and Result Identification". 371 If the default value column is empty, this indicates that the 372 security parameter does not have a default value. 374 BIB-HMAC-SHA2 Security Parameters 376 +---------+---------------------+-------------------+---------------+ 377 | Parm Id | Parm Name | CBOR Encoding | Default Value | 378 | | | Type | | 379 +---------+---------------------+-------------------+---------------+ 380 | 1 | SHA Variant | unsigned integer | 6 | 381 | 2 | Wrapped Key | Byte String | | 382 | 3 | Integrity Scope | unsigned integer | 7 | 383 | | Flags | | | 384 +---------+---------------------+-------------------+---------------+ 386 Table 2 388 3.4. Results 390 The BIB-HMAC-SHA2 security context results are listed in Table 3. In 391 this table, the "Result Id" column refers to the expected Result 392 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 393 and Result Identification". 395 BIB-HMAC-SHA2 Security Results 397 +--------+----------+-------------+---------------------------------+ 398 | Result | Result | CBOR | Description | 399 | Id | Name | Encoding | | 400 | | | Type | | 401 +--------+----------+-------------+---------------------------------+ 402 | 1 | Expected | byte string | The output of the HMAC | 403 | | HMAC | | calculation at the security | 404 | | | | source. | 405 +--------+----------+-------------+---------------------------------+ 407 Table 3 409 3.5. Key Considerations 411 HMAC keys used with this context MUST be symmetric and MUST have a 412 key length equal to the output of the HMAC. For this reason, HMAC 413 key lengths will be integer divisible by 8 bytes and special padding- 414 aware AES key wrap algorithms are not needed. 416 It is assumed that any security verifier or security acceptor 417 performing an integrity verification can determine the proper HMAC 418 key to be used. Potential sources of the HMAC key include (but are 419 not limited to) the following: 421 Pre-placed keys selected based on local policy. 423 Keys extracted from material carried in the BIB. 425 Session keys negotiated via a mechanism external to the BIB. 427 When an AES-KW wrapped key is present in a security block, it is 428 assumed that security verifiers and security acceptors can 429 independently determine the key encryption key (KEK) used in the 430 wrapping of the symmetric HMAC key. 432 As discussed in Section 6 and emphasized here, it is strongly 433 recommended that keys be protected once generated, both when they are 434 stored and when they are transmitted. 436 3.6. Security Processing Considerations 438 An HMAC calculated over the same IPPT with the same key will always 439 have the same value. This regularity can lead to practical side- 440 channel attacks whereby an attacker could produce known plain text 441 and a guess at an HMAC tag and observe the behavior of a verifier. 442 With a modest number of trials, a side-channel attack could produce 443 an HMAC tag for attacher-provided plain text without the attacker 444 ever knowing the HMAC key. 446 A common method of observing the behavior of a verifier is precise 447 analysis of the timing associated with comparisons. Therefore, one 448 way to prevent behavior analysis of this type is to ensure that any 449 comparisons of the supplied and expected authentication tag occur in 450 constant time. 452 A constant-time comparison function SHOULD be used for the comparison 453 of authentication tags by any implementation of this security 454 context. In cases where such a function is difficult or impossible 455 to use, the impact of side-channel (in general) and timing attacks 456 (specifically) need to be considered as part of the implementation. 458 3.7. Canonicalization Algorithms 460 This section defines the canonicalization algorithm used to prepare 461 the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The 462 construction of the IPPT depends on the settings of the integrity 463 scope flags that can be provided as part of customizing the behavior 464 of this security context. 466 In all cases, the canonical form of any portion of an extension block 467 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 468 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 469 the canonical forms for extension blocks defined in 471 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 472 are represented in CBOR. 474 The IPPT is constructed using the following process. While integrity 475 scope flags might not be included in the BIB representing the 476 security operation, they MUST be included in the IPPT value itself. 478 1. The canonical form of the IPPT starts as the CBOR encoding of the 479 integrity scope flags in which all unset flags, reserved bits, 480 and unassigned bits have been set to 0. For example, if the 481 primary block flag, target header flag, and security header flag 482 are each set, then the initial value of the canonical form of the 483 IPPT will be 0x07. 485 2. If the primary block flag of the integrity scope flags is set to 486 1, then a canonical form of the bundle's primary block MUST be 487 calculated and the result appended to the IPPT. 489 3. If the target header flag of the integrity scope flags is set to 490 1, then the canonical form of the block type code, block number, 491 and block processing control flags associated with the security 492 target MUST be calculated and, in that order, appended to the 493 IPPT. 495 4. If the security header flag of the integrity scope flags is set 496 to 1, then the canonical form of the block type code, block 497 number, and block processing control flags associated with the 498 BIB MUST be calculated and, in that order, appended to the IPPT. 500 5. The canonical form of the security target block-type-specific 501 data MUST be calculated and appended to the IPPT. 503 3.8. Processing 505 3.8.1. Keyed Hash Generation 507 During keyed hash generation, two inputs are prepared for the the 508 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 509 data items MUST be generated as follows. 511 The HMAC key MUST have the appropriate length as required by local 512 security policy. The key can be generated specifically for this 513 integrity service, given as part of local security policy, or 514 through some other key management mechanism as discussed in 515 Section 3.5. 517 Prior to the generation of the IPPT, if a CRC value is present for 518 the target block of the BIB, then that CRC value MUST be removed 519 from the target block. This involves both removing the CRC value 520 from the target block and setting the CRC Type field of the target 521 block to "no CRC is present." 523 Once CRC information is removed, the IPPT MUST be generated as 524 discussed in Section 3.7. 526 Upon successful hash generation the following actions MUST occur. 528 The keyed hash produced by the HMAC/SHA2 variant MUST be added as 529 a security result for the BIB representing the security operation 530 on this security target, as discussed in Section 3.4. 532 Finally, the BIB containing information about this security operation 533 MUST be updated as follows. These operations can occur in any order. 535 The security context identifier for the BIB MUST be set to the 536 context identifier for BIB-HMAC-SHA2. 538 Any local flags used to generate the IPPT MUST be placed in the 539 integrity scope flags security parameter for the BIB unless these 540 flags are expected to be correctly configured at security 541 verifiers and acceptors in the network. 543 The HMAC key MAY be included as a security parameter in which case 544 it MUST be wrapped using the NIST AES-KW algorithm and the results 545 of the wrapping added as the wrapped key security parameter for 546 the BIB. 548 The SHA variant used by this security context SHOULD be added as 549 the SHA variant security parameter for the BIB if it differs from 550 the default key length. Otherwise, this parameter MAY be omitted 551 if doing so provides a useful reduction in message sizes. 553 Problems encountered in the keyed hash generation MUST be processed 554 in accordance with local BPSec security policy. 556 3.8.2. Keyed Hash Verification 558 During keyed hash verification, the input of the security target and 559 a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. 561 During keyed hash verification, two inputs are prepared for the 562 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 563 data items MUST be generated as follows. 565 The HMAC key MUST be derived using the wrapped key security 566 parameter if such a parameter is included in the security context 567 parameters of the BIB. Otherwise, this key MUST be derived in 568 accordance with security policy at the verifying node as discussed 569 in Section 3.5. 571 The IPPT MUST be generated as discussed in Section 3.7 with the 572 value of integrity scope flags being taken from the integrity 573 scope flags security context parameter. If the integrity scope 574 flags parameter is not included in the security context parameters 575 then these flags MAY be derived from local security policy. 577 The calculated HMAC output MUST be compared to the expected HMAC 578 output encoded in the security results of the BIB for the security 579 target. If the calculated HMAC and expected HMAC are identical, the 580 verification MUST be considered a success. Otherwise, the 581 verification MUST be considered a failure. 583 If the verification fails or otherwise experiences an error, or if 584 any needed parameters are missing, then the verification MUST be 585 treated as failed and processed in accordance with local security 586 policy. 588 This security service is removed from the bundle at the security 589 acceptor as required by the BPSec specification. If the security 590 acceptor is not the bundle destination and if no other integrity 591 service is being applied to the target block, then a CRC MUST be 592 included for the target block. The CRC type, as determined by 593 policy, is set in the target block's CRC type field and the 594 corresponding CRC value is added as the CRC field for that block. 596 4. Security Context BCB-AES-GCM 598 4.1. Overview 600 The BCB-AES-GCM security context replaces the block-type-specific 601 data field of its security target with cipher text generated using 602 the Advanced Encryption Standard (AES) cipher operating in Galois/ 603 Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the 604 cipher suite for this confidentiality mechanism for several reasons: 606 1. The selection of a symmetric-key cipher suite allows for 607 relatively smaller keys than asymmetric-key cipher suites. 609 2. The selection of a symmetric-key cipher suite allows this 610 security context to be used in places where an asymmetric-key 611 infrastructure (such as a public key infrastructure) might be 612 impractical. 614 3. The use of the Galois/Counter Mode produces cipher-text with the 615 same size as the plain text making the replacement of target 616 block information easier as length fields do not need to be 617 changed. 619 4. The AES-GCM cipher suite provides authenticated encryption, as 620 required by the BPSec protocol. 622 Additionally, the BCB-AES-GCM security context generates an 623 authentication tag based on the plain text value of the block-type- 624 specific data and other additional authenticated data that might be 625 specified via parameters to this security context. 627 This security context supports two variants of AES-GCM, based on the 628 supported length of the symmetric key. These variants correspond to 629 A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value 630 for AES-GCM. 632 The BCB-AES-GCM security context MUST have the security context 633 identifier specified in Section 5.1. 635 4.2. Scope 637 There are two scopes associated with BCB-AES-GCM: the scope of the 638 confidentiality service and the scope of the authentication service. 639 The first defines the set of information provided to the AES-GCM 640 cipher for the purpose of producing cipher text. The second defines 641 the set of information used to generate an authentication tag. 643 The scope of the confidentiality service defines the set of 644 information provided to the AES-GCM cipher for the purpose of 645 producing cipher text. This MUST be the full set of plain text 646 contained in the block-type-specific data field of the security 647 target. 649 The scope of the authentication service defines the set of 650 information used to generate an authentication tag carried with the 651 security block. This information contains all data protected by the 652 confidentiality service, the scope flags used to identify other 653 optional information, and MAY include other information (additional 654 authenticated data), as follows. 656 Primary block 657 The primary block identifies a bundle and, once created, the 658 contents of this block are immutable. Changes to the primary 659 block associated with the security target indicate that the 660 security target (and BCB) might no longer be in the correct 661 bundle. 663 For example, if a security target and associated BCB are copied 664 from one bundle to another bundle, the BCB might still be able to 665 decrypt the security target even though these blocks were never 666 intended to exist in the copied-to bundle. 668 Including this information as part of additional authenticated 669 data ensures that security target (and security block) appear in 670 the same bundle at the time of decryption as at the time of 671 encryption. 673 Security target other fields 674 The other fields of the security target include block 675 identification and processing information. Changing this 676 information changes how the security target is treated by nodes 677 in the network even when the "user data" of the security target 678 are otherwise unchanged. 680 For example, if the block processing control flags of a security 681 target are different at a security verifier than they were 682 originally set at the security source then the policy for 683 handling the security target has been modified. 685 Including this information as part of additional authenticated 686 data ensures that the cipher text in the security target will not 687 be used with a different set of block policy than originally set 688 at the time of encryption. 690 BCB other fields 691 The other fields of the BCB include block identification and 692 processing information. Changing this information changes how 693 the BCB is treated by nodes in the network, even when other 694 aspects of the BCB are unchanged. 696 For example, if the block processing control flags of the BCB are 697 different at a security acceptor than they were originally set at 698 the security source then the policy for handling the BCB has been 699 modified. 701 Including this information as part of additional authenticated 702 data ensures that the policy and identification of the security 703 service in the bundle has not changed. 705 NOTE: The security context identifier and security context 706 parameters of the security block are not included as additional 707 authenticated data because these parameters, by definition, are 708 those needed to verify or accept the security service. 709 Therefore, it is expected that changes to these values would 710 result in failures at security verifiers and security acceptors. 712 This is the case because keys cannot be re-used across security 713 contexts, and because the AAD scope flags used to identify the 714 AAD are included in the AAD. 716 The scope of the BCB-AES-GCM security context is configured using an 717 optional security context parameter. 719 4.3. Parameters 721 BCB-AES-GCM can be parameterized to specify the AES variant, 722 initialization vector, key information, and identify additional 723 authenticated data. 725 4.3.1. Initialization Vector (IV) 727 This optional parameter identifies the initialization vector (IV) 728 used to initialize the AES-GCM cipher. 730 The length of the initialization vector, prior to any CBOR encoding, 731 MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used 732 unless local security policy requires a different length. 734 This value MUST be encoded as a CBOR byte string. 736 The initialization vector can have any value with the caveat that a 737 value MUST NOT be re-used for multiple encryptions using the same 738 encryption key. This value MAY be re-used when encrypting with 739 different keys. For example, if each encryption operation using BCB- 740 AES-GCM uses a newly generated key, then the same IV can be reused. 742 4.3.2. AES Variant 744 This optional parameter identifies the AES variant being used for the 745 AES-GCM encryption, where the variant is identified by the length of 746 key used. 748 This value MUST be encoded as a CBOR unsigned integer. 750 Valid values for this parameter are as follows. 752 AES Variant Parameter Values 754 +-------+-----------------------------------------------------------+ 755 | Value | Description | 756 +-------+-----------------------------------------------------------+ 757 | 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values | 758 | | for AES-GCM | 759 | 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values | 760 | | for AES-GCM | 761 +-------+-----------------------------------------------------------+ 763 When not provided, implementations SHOULD assume a value of 3 764 (indicating use of A256GCM), unless an alternate default is 765 established by local security policy at the security source, 766 verifier, or acceptor of this integrity service. 768 Regardless of the variant, the generated authentication tag MUST 769 always be 128 bits. 771 4.3.3. Wrapped Key 773 This optional parameter contains the output of the AES key wrap 774 authenticated encryption function (KW-AE) as defined in [RFC5649]. 775 Specifically, this parameter holds the cipher text produced when 776 running the KW-AE algorithm with the input string being the symmetric 777 AES key used to generate the security results present in the security 778 block. The value of this parameter is used as input to the AES key 779 wrap authenticated decryption function (KW-AD) at security verifiers 780 and security acceptors to determine the symmetric AES key needed for 781 the proper decryption of the security results in the security block. 783 This value MUST be encoded as a CBOR byte string. 785 If this parameter is not present then security verifiers and 786 acceptors MUST determine the proper key as a function of their local 787 BPSec policy and configuration. 789 4.3.4. AAD Scope Flags 791 This optional parameter contains a series of flags that describe what 792 information is to be included with the block-type-specific data of 793 the security target as part of additional authenticated data (AAD). 795 This value MUST be represented as a CBOR unsigned integer, the value 796 of which MUST be processed as a bit field. 798 AAD scope flags that are unrecognized MUST be ignored, as future 799 definitions of additional flags might not be integrated 800 simultaneously into security context implementations operating at all 801 nodes. 803 Implementations MUST set reserved and unassigned bits in this field 804 to 0 when constructing these flags at a security source. Once set, 805 the value of this field MUST NOT be altered until the security 806 service is completed at the security acceptor in the network and 807 removed from the bundle. 809 Bits in this field represent additional information to be included 810 when generating an integrity signature over the security target. 811 These bits are defined as follows. 813 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 815 - Bit 1 (0x0002): Target Header Flag. 817 - Bit 2 (0x0004): Security Header Flag. 819 - Bits 3-7 are reserved. 821 - Bits 8-15 are unassigned. 823 4.3.5. Enumerations 825 The BCB-AES-GCM security context parameters are listed in Table 4. 826 In this table, the "Parm Id" column refers to the expected Parameter 827 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 828 and Result Identification". 830 If the default value column is empty, this indicates that the 831 security parameter does not have a default value. 833 BCB-AES-GCM Security Parameters 835 +---------+----------------------+------------------+---------------+ 836 | Parm Id | Parm Name | CBOR Encoding | Default Value | 837 | | | Type | | 838 +---------+----------------------+------------------+---------------+ 839 | 1 | Initialization | Byte String | | 840 | | Vector | | | 841 | 2 | AES Variant | Unsigned Integer | 3 | 842 | 3 | Wrapped Key | Byte String | | 843 | 4 | AAD Scope Flags | Unsigned Integer | 7 | 844 +---------+----------------------+------------------+---------------+ 846 Table 4 848 4.4. Results 850 The BCB-AES-GCM security context produces a single security result 851 carried in the security block: the authentication tag. 853 NOTES: 855 The cipher text generated by the cipher suite is not considered a 856 security result as it is stored in the block-type-specific data 857 field of the security target block. When operating in GCM mode, 858 AES produces cipher text of the same size as its plain text and, 859 therefore, no additional logic is required to handle padding or 860 overflow caused by the encryption in most cases (see below). 862 If the authentication tag can be separated from the cipher text, 863 then the tag MAY be separated and stored in the authentication tag 864 security result field. Otherwise, the security target block MUST 865 be resized to accommodate the additional 128 bits of 866 authentication tag included with the generated cipher text 867 replacing the block-type-specific-data field of the security 868 target block. 870 4.4.1. Authentication Tag 872 The authentication tag is generated by the cipher suite over the 873 security target plain text input to the cipher suite as combined with 874 any optional additional authenticated data. This tag is used to 875 ensure that the plain text (and important information associated with 876 the plain text) is authenticated prior to decryption. 878 If the authentication tag is included in the cipher text placed in 879 the security target block-type-specific data field, then this 880 security result MUST NOT be included in the BCB for that security 881 target. 883 The length of the authentication tag, prior to any CBOR encoding, 884 MUST be 128 bits. 886 This value MUST be encoded as a CBOR byte string. 888 4.4.2. Enumerations 890 The BCB-AES-GCM security context results are listed in Table 5. In 891 this table, the "Result Id" column refers to the expected Result 892 Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter 893 and Result Identification". 895 BCB-AES-GCM Security Results 897 +-----------+--------------------+--------------------+ 898 | Result Id | Result Name | CBOR Encoding Type | 899 +-----------+--------------------+--------------------+ 900 | 1 | Authentication Tag | Byte String | 901 +-----------+--------------------+--------------------+ 903 Table 5 905 4.5. Key Considerations 907 Keys used with this context MUST be symmetric and MUST have a key 908 length equal to the key length defined in the security context 909 parameters or as defined by local security policy at security 910 verifiers and acceptors. For this reason, content-encrypting key 911 lengths will be integer divisible by 8 bytes and special padding- 912 aware AES key wrap algorithms are not needed. 914 It is assumed that any security verifier or security acceptor can 915 determine the proper key to be used. Potential sources of the key 916 include (but are not limited to) the following. 918 Pre-placed keys selected based on local policy. 920 Keys extracted from material carried in the BCB. 922 Session keys negotiated via a mechanism external to the BCB. 924 When an AES-KW wrapped key is present in a security block, it is 925 assumed that security verifiers and security acceptors can 926 independently determine the key encryption key (KEK) used in the 927 wrapping of the symmetric AES content-encrypting key. 929 The security provided by block ciphers is reduced as more data is 930 processed with the same key. The total number of blocks processed 931 with a single key for AES-GCM is recommended to be less than 2^64, as 932 described in Appendix B of [AES-GCM]. 934 Additionally, there exist limits on the number of encryptions that 935 can be performed with the same key. The total number of invocations 936 of the authenticated encryption function with a single key for AES- 937 GCM is required to not exceed 2^32, as described in Section 8.3 of 938 [AES-GCM]. 940 As discussed in Section 6 and emphasized here, it is strongly 941 recommended that keys be protected once generated, both when they are 942 stored and when they are transmitted. 944 4.6. GCM Considerations 946 The GCM cryptographic mode of AES has specific requirements that MUST 947 be followed by implementers for the secure function of the BCB-AES- 948 GCM security context. While these requirements are well documented 949 in [AES-GCM], some of them are repeated here for emphasis. 951 With the exception of the AES-KW function, the IVs used by the 952 BCB-AES-GCM security context are considered to be per-invocation 953 IVs. The pairing of a per-invocation IV and a security key MUST 954 be unique. A per-invocation IV MUST NOT be used with a security 955 key more than one time. If a per-invocation IV and key pair are 956 repeated then the GCM implementation is vulnerable to forgery 957 attacks. More information regarding the importance of the 958 uniqueness of the IV value can be found in Appendix A of 959 [AES-GCM]. 961 The AES-KW function used to wrap keys for the security contexts in 962 this document uses a single, globally constant IV input to the AES 963 cipher operation and, thus, is distinct from the aforementioned 964 requirement related to per-invocation IVs. 966 While any tag-based authentication mechanism has some likelihood 967 of being forged, this probability is increased when using AES-GCM. 968 In particular, short tag lengths combined with very long messages 969 SHOULD be avoided when using this mode. The BCB-AES-GCM security 970 context requires the use of 128-bit authentication tags at all 971 times. Concerns relating to the size of authentication tags is 972 discussed in Appendices B and C of [AES-GCM]. 974 As discussed in Appendix B of [AES-GCM], implementations SHOULD 975 limit the number of unsuccessful verification attempts for each 976 key to reduce the likelihood of guessing tag values. This type of 977 check has potential state-keeping issues when AES-KW is used, 978 since an attacker could cause a large number of keys to have been 979 used at least once. 981 As discussed in the Security Considerations section of 982 [I-D.ietf-dtn-bpsec], delay-tolerant networks have a higher 983 occurrence of replay attacks due to the store-and-forward nature 984 of the network. Because GCM has no inherent replay attack 985 protection, implementors SHOULD attempt to detect replay attacks 986 by using mechanisms such as those described in Appendix D of 987 [AES-GCM]. 989 4.7. Canonicalization Algorithms 991 This section defines the canonicalization algorithms used to prepare 992 the inputs used to generate both the cipher text and the 993 authentication tag. 995 In all cases, the canonical form of any portion of an extension block 996 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 997 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 998 the canonical forms for extension blocks defined in 999 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 1000 are represented in CBOR. 1002 4.7.1. Cipher text related calculations 1004 The BCB operates over the block-type-specific data of a block, but 1005 the BP always encodes these data within a single, definite-length 1006 CBOR byte string. Therefore, the plain text used during encryption 1007 MUST be calculated as the value of the block-type-specific data field 1008 of the security target excluding any CBOR encoding. 1010 Consider the following two CBOR encoded examples and the plain text 1011 that would be extracted from them. The first example is an unsigned 1012 integer, while the second is a byte string. 1014 CBOR Plain Text Extraction Examples 1016 +------------------------------+---------+--------------------------+ 1017 | CBOR Encoding (Hex) | CBOR | Plain Text Part (Hex) | 1018 | | Part | | 1019 | | (Hex) | | 1020 +------------------------------+---------+--------------------------+ 1021 | 18ED | 18 | ED | 1022 +------------------------------+---------+--------------------------+ 1023 | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | 1024 +------------------------------+---------+--------------------------+ 1026 Table 6 1028 Similarly, the cipher text used during decryption MUST be calculated 1029 as the single, definite-length CBOR byte string representing the 1030 block-type-specific data field excluding the CBOR byte string 1031 identifying byte and optional CBOR byte string length field. 1033 All other fields of the security target (such as the block type code, 1034 block number, block processing control flags, or any CRC information) 1035 MUST NOT be considered as part of encryption or decryption. 1037 4.7.2. Additional Authenticated Data 1039 The construction of additional authenticated data depends on the AAD 1040 scope flags that can be provided as part of customizing the behavior 1041 of this security context. 1043 The canonical form of the AAD input to the BCB-AES-GCM mechanism is 1044 constructed using the following process. While the AAD scope flags 1045 might not be included in the BCB representing the security operation, 1046 they MUST be included in the AAD value itself. This process MUST be 1047 followed when generating AAD for either encryption or decryption. 1049 1. The canonical form of the AAD starts as the CBOR encoding of the 1050 AAD scope flags in which all unset flags, reserved bits, and 1051 unassigned bits have been set to 0. For example, if the primary 1052 block flag, target header flag, and security header flag are each 1053 set, then the initial value of the canonical form of the AAD will 1054 be 0x07. 1056 2. If the primary block flag of the AAD scope flags is set to 1, 1057 then a canonical form of the bundle's primary block MUST be 1058 calculated and the result appended to the AAD. 1060 3. If the target header flag of the AAD scope flags is set to 1, 1061 then the canonical form of the block type code, block number, and 1062 block processing control flags associated with the security 1063 target MUST be calculated and, in that order, appended to the 1064 AAD. 1066 4. If the security header flag of the AAD scope flags is set to 1, 1067 then the canonical form of the block type code, block number, and 1068 block processing control flags associated with the BIB MUST be 1069 calculated and, in that order, appended to the AAD. 1071 4.8. Processing 1073 4.8.1. Encryption 1075 During encryption, four inputs are prepared for input to the AES/GCM 1076 cipher: the encryption key, the IV, the security target plain text to 1077 be encrypted, and any additional authenticated data. These data 1078 items MUST be generated as follows. 1080 Prior to encryption, if a CRC value is present for the target block, 1081 then that CRC value MUST be removed. This requires removing the CRC 1082 field from the target block and setting the CRC type field of the 1083 target block to "no CRC is present." 1084 The encryption key MUST have the appropriate length as required by 1085 local security policy. The key might be generated specifically 1086 for this encryption, given as part of local security policy, or 1087 through some other key management mechanism as discussed in 1088 Section 4.5. 1090 The IV selected MUST be of the appropriate length. Because 1091 replaying an IV in counter mode voids the confidentiality of all 1092 messages encrypted with said IV, this context also requires a 1093 unique IV for every encryption performed with the same key. This 1094 means the same key and IV combination MUST NOT be used more than 1095 once. 1097 The security target plain text for encryption MUST be generated as 1098 discussed in Section 4.7.1. 1100 Additional authenticated data MUST be generated as discussed in 1101 Section 4.7.2 with the value of AAD scope flags being taken from 1102 local security policy. 1104 Upon successful encryption the following actions MUST occur. 1106 The cipher text produced by AES/GCM MUST replace the bytes used to 1107 define the plain text in the security target block's block-type- 1108 specific data field. The block length of the security target MUST 1109 be updated if the generated cipher text is larger than the plain 1110 text (which can occur when the authentication tag is included in 1111 the cipher text calculation, as discussed in Section 4.4). 1113 The authentication tag calculated by the AES/GCM cipher MAY be 1114 added as a security result for the security target in the BCB 1115 holding results for this security operation, in which case it MUST 1116 be processed as described in Section 4.4. 1118 The authentication tag MUST be included either as a security 1119 result in the BCB representing the security operation or (with the 1120 cipher text) in the security target block-type-specific data 1121 field. 1123 Finally, the BCB containing information about this security operation 1124 MUST be updated as follows. These operations can occur in any order. 1126 The security context identifier for the BCB MUST be set to the 1127 context identifier for BCB-AES-GCM. 1129 The IV input to the cipher MUST be added as the IV security 1130 parameter for the BCB. 1132 Any local flags used to generated AAD for this cipher MUST be 1133 placed in the AAD scope flags security parameter for the BCB 1134 unless these flags are expected to be correctly configured at 1135 security verifiers and security acceptors in the network. 1137 The encryption key MAY be included as a security parameter in 1138 which case it MUST be wrapped using the NIST AES-KW algorithm and 1139 the results of the wrapping added as the wrapped key security 1140 parameter for the BCB. 1142 The AES variant used by this security context SHOULD be added as 1143 the AES variant security parameter for the BCB if it differs from 1144 the default key length. Otherwise, this parameter MAY be omitted 1145 if doing so provides a useful reduction in message sizes. 1147 Problems encountered in the encryption MUST be processed in 1148 accordance with local security policy. This MAY include restoring a 1149 CRC value removed from the target block prior to encryption, if the 1150 target block is allowed to be transmitted after an encryption error. 1152 4.8.2. Decryption 1154 During decryption, five inputs are prepared for input to the AES/GCM 1155 cipher: the decryption key, the IV, the security target cipher text 1156 to be decrypted, any additional authenticated data, and the 1157 authentication tag generated from the original encryption. These 1158 data items MUST be generated as follows. 1160 The decryption key MUST be derived using the wrapped key security 1161 parameter if such a parameter is included in the security context 1162 parameters of the BCB. Otherwise this key MUST be derived in 1163 accordance with local security policy at the decrypting node as 1164 discussed in Section 4.5. 1166 The IV MUST be set to the value of the IV security parameter 1167 included in the BCB. If the IV parameter is not included as a 1168 security parameter, an IV MAY be derived as a function of local 1169 security policy and other BCB contents or a lack of an IV security 1170 parameter in the BCB MAY be treated as an error by the decrypting 1171 node. 1173 The security target cipher text for decryption MUST be generated 1174 as discussed in Section 4.7.1. 1176 Additional authenticated data MUST be generated as discussed in 1177 Section 4.7.2 with the value of AAD scope flags being taken from 1178 the AAD scope flags security context parameter. If the AAD scope 1179 flags parameter is not included in the security context parameters 1180 then these flags MAY be derived from local security policy in 1181 cases where the set of such flags is determinable in the network. 1183 The authentication tag MUST be present in the BCB security context 1184 parameters field. This tag MUST be 128 bits in length. 1186 Upon successful decryption the following actions MUST occur. 1188 The plain text produced by AES/GCM MUST replace the bytes used to 1189 define the cipher text in the security target block's block-type- 1190 specific data field. Any changes to the security target block 1191 length field MUST be corrected in cases where the plain text has a 1192 different length than the replaced cipher text. 1194 If the security acceptor is not the bundle destination and if no 1195 other integrity or confidentiality service is being applied to the 1196 target block, then a CRC MUST be included for the target block. The 1197 CRC type, as determined by policy, is set in the target block's CRC 1198 type field and the corresponding CRC value is added as the CRC field 1199 for that block. 1201 If the cipher text fails to authenticate, if any needed parameters 1202 are missing, or if there are other problems in the decryption then 1203 the decryption MUST be treated as failed and processed in accordance 1204 with local security policy. 1206 5. IANA Considerations 1208 5.1. Security Context Identifiers 1210 This specification allocates two security context identifiers from 1211 the "BPSec Security Context Identifiers" registry defined in 1212 [I-D.ietf-dtn-bpsec]. 1214 Additional Entries for the BPSec Security Context Identifiers 1215 Registry: 1217 +-------+---------------+---------------+ 1218 | Value | Description | Reference | 1219 +-------+---------------+---------------+ 1220 | TBA | BIB-HMAC-SHA2 | This document | 1221 | TBA | BCB-AES-GCM | This document | 1222 +-------+---------------+---------------+ 1224 Table 7 1226 5.2. Integrity Scope Flags 1228 The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field 1229 for which IANA is requested to create and maintain a new registry 1230 named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle 1231 Protocol registry page. Initial values for this registry are given 1232 below. 1234 The registration policy for this registry is: Specification Required. 1236 The value range is unsigned 16-bit integer. 1238 BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry 1240 +-------------------------+--------------------------+--------------+ 1241 | Bit Position (right to | Description | Reference | 1242 | left) | | | 1243 +-------------------------+--------------------------+--------------+ 1244 | 0 | Include primary block | This | 1245 | | | document | 1246 | 1 | Include target header | This | 1247 | | flag | document | 1248 | 2 | Include security header | This | 1249 | | flag | document | 1250 | 3-7 | reserved | This | 1251 | | | document | 1252 | 8-15 | unassigned | This | 1253 | | | document | 1254 +-------------------------+--------------------------+--------------+ 1256 Table 8 1258 5.3. AAD Scope Flags 1260 The BCB-AES-GCM security context has an AAD Scope Flags field for 1261 which IANA is requested to create and maintain a new registry named 1262 "BPSec BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol registry 1263 page. Initial values for this registry are given below. 1265 The registration policy for this registry is: Specification Required. 1267 The value range is unsigned 16-bit integer. 1269 BPSec BCB-AES-GCM AAD Scope Flags Registry 1271 +-------------------------+--------------------------+--------------+ 1272 | Bit Position (right to | Description | Reference | 1273 | left) | | | 1274 +-------------------------+--------------------------+--------------+ 1275 | 0 | Include primary block | This | 1276 | | | document | 1277 | 1 | Include target header | This | 1278 | | flag | document | 1279 | 2 | Include security header | This | 1280 | | flag | document | 1281 | 3-7 | reserved | This | 1282 | | | document | 1283 | 8-15 | unassigned | This | 1284 | | | document | 1285 +-------------------------+--------------------------+--------------+ 1287 Table 9 1289 5.4. Guidance for Designated Experts 1291 New assignments within the BIB-HMAC-SHA2 Integrity Scope Flags 1292 Registry and the BCB-AES-GCM AAD Scope Flags Registry require review 1293 by a Designated Expert (DE). This section provides guidance to the 1294 DE when performing their reviews. Specifically, a DE is expected to 1295 perform the following activities. 1297 o Ascertain the existence of suitable documentation (a 1298 specification) as described in [RFC8126] and to verify that the 1299 document is permanently and publicly available. 1301 o Ensure that any changes to the Integrity Scope Flags clearly state 1302 how new assignments interact with existing flags and how the 1303 inclusion of new assignments affects the construction of the IPPT 1304 value. 1306 o Ensure that any changes to the AAD Scope Flags clearly state how 1307 new assignments interact with existing flags and how the inclusion 1308 of new assignments affects the construction of the AAD input to 1309 the BCB-AES-GCM mechanism. 1311 o Ensure that any processing changes proposed with new assignments 1312 do not alter any required behavior in this specification. 1314 o Verify that any specification produced in the IETF has been made 1315 available for review by the DTN working group and that any 1316 specification produced outside of the IETF does not conflict with 1317 work that is active or already published within the IETF. 1319 6. Security Considerations 1321 Security considerations specific to a single security context are 1322 provided in the description of that context. This section discusses 1323 security considerations that should be evaluated by implementers of 1324 any security context described in this document. Considerations can 1325 also be found in documents listed as normative references and they 1326 should also be reviewed by security context implementors. 1328 6.1. Key Management 1330 The delayed and disrupted nature of DTNs complicates the process of 1331 key management because there might not be reliable, timely round-trip 1332 exchange between security sources, security verifiers, and security 1333 acceptors in the network. This is true when there is a substantial 1334 signal propagation delay between nodes, when nodes are in a highly 1335 challenged communications environment, and when nodes do not support 1336 bi-directional communication. 1338 In these environments, key establishment protocols that rely on 1339 round-trip information exchange might not converge on a shared secret 1340 in a timely manner (or at all). Also, key revocation or key 1341 verification mechanisms that rely on access to a centralized 1342 authority (such as a certificate authority) might similarly fail in 1343 the stressing conditions of a DTN. 1345 For these reasons, the default security contexts described in this 1346 document rely on symmetric key cryptographic mechanisms because 1347 asymmetric key infrastructure (such as a public key infrastructure) 1348 might be impractical in this environment. 1350 BPSec assumes that "key management is handled as a separate part of 1351 network management" [I-D.ietf-dtn-bpsec]. This assumption is also 1352 made by the security contexts defined in this document which do not 1353 define new protocols for key derivation, exchange of key-encrypting 1354 keys, revocation of existing keys, or the security configuration or 1355 policy used to select certain keys for certain security operations. 1357 Nodes using these security contexts need to perform the following 1358 kinds of activities, independent of the construction, transmission, 1359 and processing of BPSec security blocks. 1361 Establish shared key-encrypting-keys with other nodes in the 1362 network using an out-of-band mechanism. This might include pre- 1363 sharing of key encryption keys or the use of traditional key 1364 establishment mechanisms prior to the exchange of BPsec security 1365 blocks. 1367 Determine when a key is considered exhausted and no longer to be 1368 used in the generation, verification, or acceptance of a security 1369 block. 1371 Determine when a key is considered invalid and no longer to be 1372 used in the generation, verification, or acceptance of a security 1373 block. Such revocations can be based on a variety of mechanisms 1374 to include local security policy, time relative to the generation 1375 or use of the key, or as specified through network management. 1377 Determine, through an out-of-band mechanism such as local security 1378 policy, what keys are to be used for what security blocks. This 1379 includes the selection of which key should be used in the 1380 evaluation of a security block received by a security verifier or 1381 a security acceptor. 1383 The failure to provide effective key management techniques 1384 appropriate for the operational networking environment can result in 1385 the compromise of those unmanaged keys and the loss of security 1386 services in the network. 1388 6.2. Key Handling 1390 Once generated, keys should be handled as follows. 1392 It is strongly RECOMMENDED that implementations protect keys both 1393 when they are stored and when they are transmitted. 1395 In the event that a key is compromised, any security operations 1396 using a security context associated with that key SHOULD also be 1397 considered compromised. This means that the BIB-HMAC-SHA2 1398 security context SHOULD NOT be treated as providing integrity when 1399 used with a compromised key and BCB-AES-GCM SHOULD NOT be treated 1400 as providing confidentiality when used with a compromised key. 1402 The same key, whether a key-encrypting-key or a wrapped key, MUST 1403 NOT be used for different algorithms as doing so might leak 1404 information about the key. 1406 A key-encrypting-key MUST NOT be used to encrypt keys for 1407 different security contexts. Any key-encrypting-key used by a 1408 security context defined in this document MUST only be used to 1409 wrap keys associated with security operations using that security 1410 context. This means that a compliant security source would not 1411 use the same key-encrypting-key to wrap keys for both the BIB- 1412 HMAC-SHA2 and BCB-AES-GCM security contexts. Similarly, any 1413 compliant security verifier or security acceptor would not use the 1414 same key-encrypting-key to unwrap keys for different security 1415 contexts. 1417 6.3. AES GCM 1419 There are a significant number of considerations related to the use 1420 of the GCM mode of AES to provide a confidentiality service. These 1421 considerations are provided in Section 4.6 as part of the 1422 documentation of the BCB-AES-GCM security context. 1424 The length of the cipher text produced by the GCM mode of AES will be 1425 equal to the length of the plain text input to the cipher suite. The 1426 authentication tag also produced by this cipher suite is separate 1427 from the cipher text. However, it should be noted that 1428 implementations of the AES-GCM cipher suite might not separate the 1429 concept of cipher text and authentication tag in their application 1430 programming interface (API). 1432 Implementations of the BCB-AES-GCM security context can either keep 1433 the length of the target block unchanged by holding the 1434 authentication tag in a BCB security result or alter the length of 1435 the target block by including the authentication tag with the cipher 1436 text replacing the block-type-specific-data field of the target 1437 block. Implementations MAY use the authentication tag security 1438 result in cases where keeping target block length unchanged is an 1439 important processing concern. In all cases, the cipher text and 1440 authentication tag MUST be processed in accordance with the API of 1441 the AES-GCM cipher suites at the security source and security 1442 acceptor. 1444 6.4. AES Key Wrap 1446 The AES key wrap (AES-KW) algorithm used by the security contexts in 1447 this document does not use a per-invocation initialization vector and 1448 does not require any key padding. Key padding is not needed because 1449 wrapped keys used by these security contexts will always be multiples 1450 of 8 bytes. The length of the wrapped key can be determined by 1451 inspecting the security context parameters. Therefore, a key can be 1452 unwrapped using only the information present in the security block 1453 and the key encryption key provided by local security policy at the 1454 security verifier or security acceptor. 1456 6.5. Bundle Fragmentation 1458 Bundle fragmentation might prevent security services in a bundle from 1459 being verified after a bundle is fragmented and before the bundle is 1460 re-assembled. Examples of potential issues include the following. 1462 If a security block and its security target do not exist in the 1463 same fragment, then the security block cannot be processed until 1464 the bundle is re-assembled. If a fragment includes an encrypted 1465 target block, but not its BCB, then a receiving bundle processing 1466 agent (BPA) will not know that the target block has been 1467 encrypted. 1469 A security block can be cryptographically bound to a bundle by 1470 setting the Integrity Scope Flags (for BIB-HMAC-SHA2) or the AAD 1471 Scope Flags (for BCB-AES-GCM) to include the bundle primary block. 1472 When a security block is cryptographically bound to a bundle, it 1473 cannot be processed even if the security block and target both 1474 coexist in the fragment. This is because fragments have different 1475 primary blocks than the original bundle. 1477 If security blocks and their target blocks are repeated in 1478 multiple fragments, policy needs to determine how to deal with 1479 issues where a security operation verifies in one fragment but 1480 fails in another fragment. This might happen, for example, if a 1481 BIB block becomes corrupted in one fragment but not in another 1482 fragment. 1484 Implementors should consider how security blocks are processed when a 1485 BPA fragments a received bundle. For example, security blocks and 1486 their targets could be placed in the same fragment if the security 1487 block is not otherwise cryptographically bound to the bundle being 1488 fragmented. Alternatively, if security blocks are cryptographically 1489 bound to a bundle, then a fragmenting BPA should consider 1490 encapsulating the bundle first and then fragmenting the encapsulating 1491 bundle. 1493 7. Normative References 1495 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 1496 Recommendation for Block Cipher Modes of Operation: 1497 Galois/Counter Mode (GCM) and GMAC.", November 2007. 1499 [I-D.ietf-dtn-bpbis] 1500 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1501 Version 7", draft-ietf-dtn-bpbis-31 (work in progress), 1502 January 2021. 1504 [I-D.ietf-dtn-bpsec] 1505 Birrane, E. and K. McKeever, "Bundle Protocol Security 1506 Specification", draft-ietf-dtn-bpsec-27 (work in 1507 progress), February 2021. 1509 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1510 Hashing for Message Authentication", RFC 2104, 1511 DOI 10.17487/RFC2104, February 1997, 1512 . 1514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1515 Requirement Levels", BCP 14, RFC 2119, 1516 DOI 10.17487/RFC2119, March 1997, 1517 . 1519 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1520 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1521 DOI 10.17487/RFC5649, September 2009, 1522 . 1524 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1525 Writing an IANA Considerations Section in RFCs", BCP 26, 1526 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1527 . 1529 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1530 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1531 . 1533 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1534 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1535 May 2017, . 1537 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1538 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1539 . 1541 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1542 Representation (CBOR)", STD 94, RFC 8949, 1543 DOI 10.17487/RFC8949, December 2020, 1544 . 1546 [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- 1547 180-4, Gaithersburg, MD, USA, August 2015. 1549 https://csrc.nist.gov/publications/detail/fips/180/4/final 1551 Appendix A. Examples 1553 This appendix is informative. 1555 This section presents a series of examples of constructing BPSec 1556 security blocks (using the security contexts defined in this 1557 document) and adding those blocks to a sample bundle. 1559 The examples presented in this appendix represent valid constructions 1560 of bundles, security blocks, and the encoding of security context 1561 parameters and results. For this reason, they can inform unit test 1562 suites for individual implementations as well as interoperability 1563 test suites amongst implementations. However, these examples do not 1564 cover every permutation of security parameters, security results, or 1565 use of security blocks in a bundle. 1567 NOTE: The bundle diagrams in this section are patterned after the 1568 bundle diagrams used in [I-D.ietf-dtn-bpsec] Section 3.11 "BSP Block 1569 Examples". 1571 NOTE: Figures in this section identified as "(CBOR Diagnostic 1572 Notation)" are represented using the CBOR diagnostic notation defined 1573 in [RFC8949]. This notation is used to express CBOR data structures 1574 in a manner that enables visual inspection. The bundles, security 1575 blocks, and security context contents in these figures are 1576 represented using CBOR structures. In cases where BP blocks (to 1577 include BPSec security blocks) are comprised of a sequence of CBOR 1578 objects, these objects are represented as a CBOR sequence as defined 1579 in [RFC8742]. 1581 NOTE: Examples in this section use the "ipn" URI scheme for 1582 EndpointID naming, as defined in [I-D.ietf-dtn-bpbis]. 1584 NOTE: The bundle source is presumed to be the security source for all 1585 security blocks in this section, unless otherwise noted. 1587 A.1. Example 1: Simple Integrity 1589 This example shows the addition of a BIB to a sample bundle to 1590 provide integrity for the payload block. 1592 A.1.1. Original Bundle 1594 The following diagram shows the original bundle before the BIB has 1595 been added. 1597 Block Block Block 1598 in Bundle Type Number 1599 +========================================+=======+========+ 1600 | Primary Block | N/A | 0 | 1601 +----------------------------------------+-------+--------+ 1602 | Payload Block | 1 | 1 | 1603 +----------------------------------------+-------+--------+ 1605 Figure 1: Example 1 Original Bundle 1607 A.1.1.1. Primary Block 1609 The BPv7 bundle has no special processing flags and no CRC is 1610 provided because the primary block is expected to be protected by an 1611 integrity service BIB using the BIB-HMAC-SHA2 security context. 1613 The bundle is sourced at the source node ipn:2.1 and destined for the 1614 destination node ipn:1.2. The bundle creation time uses a DTN 1615 creation time of 0 indicating lack of an accurate clock and a 1616 sequence number of 40. The lifetime of the bundle is given as 1617 1,000,000 milliseconds since the bundle creation time. 1619 The primary block is provided as follows. 1621 [ 1622 7, / BP version / 1623 0, / flags / 1624 0, / CRC type / 1625 [2, [1,2]], / destination (ipn:1.2) / 1626 [2, [2,1]], / source (ipn:2.1) / 1627 [2, [2,1]], / report-to (ipn:2.1) / 1628 [0, 40], / timestamp / 1629 1000000 / lifetime / 1630 ] 1632 Figure 2: Primary Block (CBOR Diagnostic Notation) 1634 The CBOR encoding of the primary block is 1635 0x88070000820282010282028202018202820201820018281a000f4240. 1637 A.1.1.2. Payload Block 1639 Other than its use as a source of plaintext for security blocks, the 1640 payload has no required distinguishing characteristic for the purpose 1641 of this example. The sample payload is a 32 byte string whose value 1642 is "Ready Generate a 32 byte payload". 1644 The payload is represented in the payload block as a byte string of 1645 the raw payload string. It is NOT represented as a CBOR text string 1646 wrapped within a CBOR binary string. The hex value of the payload 1647 "Ready Generate a 32 byte payload" is 1648 0x52656164792047656e657261746520612033322062797465207061796c6f6164. 1650 The payload block is provided as follows. 1652 [ 1653 1, / type code: Payload block / 1654 1, / block number / 1655 0, / block processing flags / 1656 0, / CRC Type / 1657 h'52656164792047656e65726174652061 / type-specific-data: payload / 1658 2033322062797465207061796c6f6164' 1659 ] 1661 Payload Block (CBOR Diagnostic Notation) 1663 The CBOR encoding of the payload block is 0x8501010000582052656164792 1664 047656e657261746520612033322062797465207061796c6f6164. 1666 A.1.1.3. Bundle CBOR Representation 1668 A BPv7 bundle is represented as an indefinite-length array consisting 1669 of the blocks comprising the bundle, with a terminator character at 1670 the end. 1672 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1673 28202018202820201820018281a000f42408501010000582052656164792047656e65 1674 7261746520612033322062797465207061796c6f6164ff. 1676 A.1.2. Security Operation Overview 1678 This example adds a BIB to the bundle using the BIB-HMAC-SHA2 1679 security context to provide an integrity mechanism over the payload 1680 block. 1682 The following diagram shows the resulting bundle after the BIB is 1683 added. 1685 Block Block Block 1686 in Bundle Type Number 1687 +========================================+=======+========+ 1688 | Primary Block | N/A | 0 | 1689 +----------------------------------------+-------+--------+ 1690 | Bundle Integrity Block | 11 | 2 | 1691 | OP(bib-integrity, target=1) | | | 1692 +----------------------------------------+-------+--------+ 1693 | Payload Block | 1 | 1 | 1694 +----------------------------------------+-------+--------+ 1696 Figure 3: Example 1 Resulting Bundle 1698 A.1.3. Bundle Integrity Block 1700 In this example, a BIB is used to carry an integrity signature over 1701 the payload block. 1703 A.1.3.1. Configuration, Parameters, and Results 1705 For this example, the following configuration and security parameters 1706 are used to generate the security results indicated. 1708 This BIB has a single target and includes a single security result: 1709 the calculated signature over the payload block. 1711 Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 1712 SHA Variant : HMAC 512/512 1713 Scope Flags : h'00' 1714 Payload Data: h'52656164792047656e65726174652061 1715 2033322062797465207061796c6f6164' 1716 Signature : h'0654d65992803252210e377d66d0a8dc 1717 18a1e8a392269125ae9ac198a9a598be 1718 4b83d5daa8be2f2d16769ec1c30cfc34 1719 8e2205fba4b3be2b219074fdd5ea8ef0' 1721 Figure 4: Example 1: Configuration, Parameters, and Results 1723 A.1.3.2. Abstract Security Block 1725 The abstract security block structure of the BIB's block-type- 1726 specific-data field for this application is as follows. 1728 [1], / Security Target - Payload block / 1729 1, / Security Context ID - BIB-HMAC-SHA2 / 1730 1, / Security Context Flags - Parameters Present / 1731 [2,[2, 1]], / Security Source - ipn:2.1 / 1732 [ / Security Parameters - 2 Parameters / 1733 [1, 7], / SHA Variant - HMAC 512/512 / 1734 [3, h'00'] / Scope Flags - No Additional Scope / 1735 ], 1736 [ / Security Results: 1 Result / 1737 [1, h'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b 1738 e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0'] 1739 ] 1741 Figure 5: Example 1: BIB Abstract Security Block (CBOR Diagnostic 1742 Notation) 1744 The CBOR encoding of the BIB block-type-specific-data field (the 1745 abstract security block) is 0x810101018202820201828201078203008182015 1746 8400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b 1747 83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0. 1749 A.1.3.3. Representations 1751 The BIB wrapping this abstract security block is as follows. 1753 [ 1754 11, / type code / 1755 2, / block number / 1756 0, / flags / 1757 0, / CRC type / 1758 h'8101010182028202018282010782030081820158400654d65992803252210e377d66 1759 d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34 1760 8e2205fba4b3be2b219074fdd5ea8ef0', 1761 ] 1763 Figure 6: Example 1: BIB (CBOR Diagnostic Notation) 1765 The CBOR encoding of the BIB block is 0x850b0200005855810101018202820 1766 2018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392 1767 269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2 1768 b219074fdd5ea8ef0. 1770 A.1.4. Final Bundle 1772 The CBOR encoding of the full output bundle, with the BIB: 0x9f880700 1773 00820282010282028202018202820201820018281a000f4240850b020000585581010 1774 10182028202018282010782030081820158400654d65992803252210e377d66d0a8dc 1775 18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e220 1776 5fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e6572617465 1777 20612033322062797465207061796c6f6164ff. 1779 A.2. Example 2: Simple Confidentiality with Key Wrap 1781 This example shows the addition of a BCB to a sample bundle to 1782 provide confidentiality for the payload block. AES key wrap is used 1783 to transmit the symmetric key used to generate the security results 1784 for this service. 1786 A.2.1. Original Bundle 1788 The following diagram shows the original bundle before the BCB has 1789 been added. 1791 Block Block Block 1792 in Bundle Type Number 1793 +========================================+=======+========+ 1794 | Primary Block | N/A | 0 | 1795 +----------------------------------------+-------+--------+ 1796 | Payload Block | 1 | 1 | 1797 +----------------------------------------+-------+--------+ 1799 Figure 7: Example 2 Original Bundle 1801 A.2.1.1. Primary Block 1803 The primary block used in this example is identical to the primary 1804 block presented in Example 1 Appendix A.1.1.1. 1806 In summary, the CBOR encoding of the primary block is 1807 0x88070000820282010282028202018202820201820018281a000f4240. 1809 A.2.1.2. Payload Block 1811 The payload block used in this example is identical to the payload 1812 block presented in Example 1 Appendix A.1.1.2. 1814 In summary, the CBOR encoding of the payload block is 0x8501010000582 1815 052656164792047656e657261746520612033322062797465207061796c6f6164. 1817 A.2.1.3. Bundle CBOR Representation 1819 A BPv7 bundle is represented as an indefinite-length array consisting 1820 of the blocks comprising the bundle, with a terminator character at 1821 the end. 1823 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1824 28202018202820201820018281a000f42408501010000582052656164792047656e65 1825 7261746520612033322062797465207061796c6f6164ff. 1827 A.2.2. Security Operation Overview 1829 This example adds a BCB using the BCB-AES-GCM security context using 1830 AES key wrap to provide a confidentiality mechanism over the payload 1831 block and transmit the symmetric key. 1833 The following diagram shows the resulting bundle after the BCB is 1834 added. 1836 Block Block Block 1837 in Bundle Type Number 1838 +========================================+=======+========+ 1839 | Primary Block | N/A | 0 | 1840 +----------------------------------------+-------+--------+ 1841 | Bundle Confidentiality Block | 12 | 2 | 1842 | OP(bcb-confidentiality, target=1) | | | 1843 +----------------------------------------+-------+--------+ 1844 | Payload Block (Encrypted) | 1 | 1 | 1845 +----------------------------------------+-------+--------+ 1847 Figure 8: Example 2 Resulting Bundle 1849 A.2.3. Bundle Confidentiality Block 1851 In this example, a BCB is used to encrypt the payload block and uses 1852 AES key wrap to transmit the symmetric key. 1854 A.2.3.1. Configuration, Parameters, and Results 1856 For this example, the following configuration and security parameters 1857 are used to generate the security results indicated. 1859 This BCB has a single target, the payload block. Three security 1860 results are generated: cipher text which replaces the plain text 1861 block-type-specific data to encrypt the payload block, an 1862 authentication tag, and the AES wrapped key. 1864 Content Encryption 1865 Key: h'71776572747975696f70617364666768' 1866 Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' 1867 IV: h'5477656c7665313231323132' 1868 AES Variant: A128GCM 1869 AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 1870 96fabf34d7fae700' 1871 Scope Flags: h'00' 1872 Payload Data: h'52656164792047656e65726174652061 1873 2033322062797465207061796c6f6164' 1874 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 1875 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 1876 a563e32648b700c2784e26a990d91f9d' 1878 Figure 9: Example 2: Configuration, Parameters, and Results 1880 A.2.3.2. Abstract Security Block 1882 The abstract security block structure of the BCB's block-type- 1883 specific-data field for this application is as follows. 1885 [1], / Security Target - Payload block / 1886 2, / Security Context ID - BCB-AES-GCM / 1887 1, / Security Context Flags - Parameters Present / 1888 [2,[2, 1]], / Security Source - ipn:2.1 / 1889 [ / Security Parameters - 4 Parameters / 1890 [1, h'5477656c7665313231323132'], / Initialization Vector / 1891 [2, 1], / AES Variant - A128GCM / 1892 [3, h'69c411276fecddc4780df42c8a / AES wrapped key / 1893 2af89296fabf34d7fae700'], 1894 [4, h'00'] / Scope Flags - No extra scope/ 1895 ], 1896 [ / Security Results: 1 Result / 1897 [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / 1898 ] 1900 Figure 10: Example 2: BCB Abstract Security Block (CBOR Diagnostic 1901 Notation) 1903 The CBOR encoding of the BCB block-type-specific-data field (the 1904 abstract security block) is 0x8101020182028202018482014c5477656c76653 1905 132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa 1906 e70082040081820150da08f4d8936024ad7c6b3b800e73dd97. 1908 A.2.3.3. Representations 1910 The BCB wrapping this abstract security block is as follows. 1912 [ 1913 12, / type code / 1914 2, / block number / 1915 1, / flags - block must be replicated in every fragment / 1916 0, / CRC type / 1917 h'8101020182028202018482014c5477656c766531323132313282020182035818 1918 69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da 1919 08f4d8936024ad7c6b3b800e73dd97' 1920 ] 1922 Figure 11: Example 2: BCB (CBOR Diagnostic Notation) 1924 The CBOR encoding of the BCB block is 0x850c020100584f810102018202820 1925 2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d 1926 f42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e7 1927 3dd97. 1929 A.2.4. Final Bundle 1931 The CBOR encoding of the full output bundle, with the BCB: 0x9f880700 1932 00820282010282028202018202820201820018281a000f4240850c020100584f81010 1933 20182028202018482014c5477656c76653132313231328202018203581869c411276f 1934 ecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7 1935 c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e326 1936 48b700c2784e26a990d91f9dff. 1938 A.3. Example 3: Security Blocks from Multiple Sources 1940 This example shows the addition of a BIB and BCB to a sample bundle. 1941 These two security blocks are added by two different nodes. The BCB 1942 is added by the source endpoint and the BIB is added by a forwarding 1943 node. 1945 The resulting bundle contains a BCB to encrypt the Payload Block and 1946 a BIB to provide integrity to the Primary and Bundle Age Block. 1948 A.3.1. Original Bundle 1950 The following diagram shows the original bundle before the security 1951 blocks have been added. 1953 Block Block Block 1954 in Bundle Type Number 1955 +========================================+=======+========+ 1956 | Primary Block | N/A | 0 | 1957 +----------------------------------------+-------+--------+ 1958 | Extension Block: Bundle Age Block | 7 | 2 | 1959 +----------------------------------------+-------+--------+ 1960 | Payload Block | 1 | 1 | 1961 +----------------------------------------+-------+--------+ 1963 Figure 12: Example 3 Original Bundle 1965 A.3.1.1. Primary Block 1967 The primary block used in this example is identical to the primary 1968 block presented in Example 1 Appendix A.1.1.1. 1970 In summary, the CBOR encoding of the primary block is 1971 0x88070000820282010282028202018202820201820018281a000f4240. 1973 A.3.1.2. Bundle Age Block 1975 A bundle age block is added to the bundle to help other nodes in the 1976 network determine the age of the bundle. The use of this block is as 1977 recommended because the bundle source does not have an accurate clock 1978 (as indicated by the DTN time of 0). 1980 Because this block is specified at the time the bundle is being 1981 forwarded, the bundle age represents the time that has elapsed from 1982 the time the bundle was created to the time it is being prepared for 1983 forwarding. In this case, the value is given as 300 milliseconds. 1985 The bundle age extension block is provided as follows. 1987 [ 1988 7, / type code: Bundle Age block / 1989 2, / block number / 1990 0, / block processing flags / 1991 0, / CRC Type / 1992 <<300>> / type-specific-data: age / 1993 ] 1995 Figure 13: Bundle Age Block (CBOR Diagnostic Notation) 1997 The CBOR encoding of the bundle age block is 0x85070200004319012c. 1999 A.3.1.3. Payload Block 2001 The payload block used in this example is identical to the payload 2002 block presented in Example 1 Appendix A.1.1.2. 2004 In summary, the CBOR encoding of the payload block is 0x8501010000582 2005 052656164792047656e657261746520612033322062797465207061796c6f6164. 2007 A.3.1.4. Bundle CBOR Representation 2009 A BPv7 bundle is represented as an indefinite-length array consisting 2010 of the blocks comprising the bundle, with a terminator character at 2011 the end. 2013 The CBOR encoding of the original bundle is 0x9f880700008202820102820 2014 28202018202820201820018281a000f424085070200004319012c8501010000582052 2015 656164792047656e657261746520612033322062797465207061796c6f6164ff. 2017 A.3.2. Security Operation Overview 2019 This example provides: 2021 a BIB with the BIB-HMAC-SHA2 security context to provide an 2022 integrity mechanism over the primary block and bundle age block. 2024 a BCB with the BCB-AES-GCM security context to provide a 2025 confidentiality mechanism over the payload block. 2027 The following diagram shows the resulting bundle after the security 2028 blocks are added. 2030 Block Block Block 2031 in Bundle Type Number 2032 +========================================+=======+========+ 2033 | Primary Block | N/A | 0 | 2034 +----------------------------------------+-------+--------+ 2035 | Bundle Integrity Block | 11 | 3 | 2036 | OP(bib-integrity, targets=0, 2) | | | 2037 +----------------------------------------+-------+--------+ 2038 | Bundle Confidentiality Block | 12 | 4 | 2039 | OP(bcb-confidentiality, target=1) | | | 2040 +----------------------------------------+-------+--------+ 2041 | Extension Block: Bundle Age Block | 7 | 2 | 2042 +----------------------------------------+-------+--------+ 2043 | Payload Block (Encrypted) | 1 | 1 | 2044 +----------------------------------------+-------+--------+ 2046 Figure 14: Example 3 Resulting Bundle 2048 A.3.3. Bundle Integrity Block 2050 In this example, a BIB is used to carry an integrity signature over 2051 the bundle age block and an additional signature over the payload 2052 block. The BIB is added by a waypoint node, ipn:3.0. 2054 A.3.3.1. Configuration, Parameters, and Results 2056 For this example, the following configuration and security parameters 2057 are used to generate the security results indicated. 2059 This BIB has two security targets and includes two security results, 2060 holding the calculated signatures over the bundle age block and 2061 primary block. 2063 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2064 SHA Variant: HMAC 256/256 2065 Scope Flags: h'00' 2066 Primary Block Data: h'88070000820282010282028202018202 2067 820201820018281a000f4240' 2068 Bundle Age Block 2069 Data: h'85070200004319012c' 2070 Primary Block 2071 Signature: h'8e059b8e71f7218264185a666bf3e453 2072 076f2b883f4dce9b3cdb6464ed0dcf0f' 2073 Bundle Age Block 2074 Signature: h'72dee8eba049a22978e84a95d0496466 2075 8eb131b1ca4800c114206d70d9065c80' 2077 Figure 15: Example 3: Configuration, Parameters, and Results for the 2078 BIB 2080 A.3.3.2. Abstract Security Block 2082 The abstract security block structure of the BIB's block-type- 2083 specific-data field for this application is as follows. 2085 [0, 2], / Security Targets / 2086 1, / Security Context ID - BIB-HMAC-SHA2 / 2087 1, / Security Context Flags - Parameters Present / 2088 [2,[3, 0]], / Security Source - ipn:3.0 / 2089 [ / Security Parameters - 2 Parameters / 2090 [1, 5], / SHA Variant - HMAC 256/256 / 2091 [3, h'00'] / Scope Flags - No Additional Scope / 2092 ], 2093 [ / Security Results: 2 Results / 2094 [1, h'8e059b8e71f7218264185a666bf3e453 2095 076f2b883f4dce9b3cdb6464ed0dcf0f'], / Primary Block / 2096 [1, h'72dee8eba049a22978e84a95d0496466 2097 8eb131b1ca4800c114206d70d9065c80'] / Bundle Age Block / 2098 ] 2100 Figure 16: Example 3: BIB Abstract Security Block (CBOR Diagnostic 2101 Notation) 2103 The CBOR encoding of the BIB block-type-specific-data field (the 2104 abstract security block) is 0x820002010182028203008282010582030082820 2105 158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f 2106 8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065 2107 c80. 2109 A.3.3.3. Representations 2111 The BIB wrapping this abstract security block is as follows. 2113 [ 2114 11, / type code / 2115 3, / block number / 2116 0, / flags / 2117 0, / CRC type / 2118 h'820002010182028203008282010582030082820158208e059b8e71f721826418 2119 5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049 2120 a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80', 2121 ] 2123 Figure 17: Example 3: BIB (CBOR Diagnostic Notation) 2125 The CBOR encoding of the BIB block is 0x850b030000585a820002010182028 2126 203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b88 2127 3f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb13 2128 1b1ca4800c114206d70d9065c80. 2130 A.3.4. Bundle Confidentiality Block 2132 In this example, a BCB is used encrypt the payload block. The BCB is 2133 added by the bundle source node, ipn:2.1. 2135 A.3.4.1. Configuration, Parameters, and Results 2137 For this example, the following configuration and security parameters 2138 are used to generate the security results indicated. 2140 This BCB has a single target, the payload block. Two security 2141 results are generated: cipher text which replaces the plain text 2142 block-type-specific data to encrypt the payload block, and an 2143 authentication tag. 2145 Content Encryption 2146 Key: h'71776572747975696f70617364666768' 2147 IV: h'5477656c7665313231323132' 2148 AES Variant: A128GCM 2149 Scope Flags: h'00' 2150 Payload Data: h'52656164792047656e65726174652061 2151 2033322062797465207061796c6f6164' 2152 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 2153 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 2154 a563e32648b700c2784e26a990d91f9d' 2156 Figure 18: Example 3: Configuration, Parameters, and Results for the 2157 BCB 2159 A.3.4.2. Abstract Security Block 2161 The abstract security block structure of the BCB's block-type- 2162 specific-data field for this application is as follows. 2164 [1], / Security Target - Payload block / 2165 2, / Security Context ID - BCB-AES-GCM / 2166 1, / Security Context Flags - Parameters Present / 2167 [2,[2, 1]], / Security Source - ipn:2.1 / 2168 [ / Security Parameters - 3 Parameters / 2169 [1, h'5477656c7665313231323132'], / Initialization Vector / 2170 [2, 1], / AES Variant - AES 128 / 2171 [4, h'00'] / Scope Flags - No Additional Scope / 2172 ], 2173 [ / Security Results: 1 Result / 2174 [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / 2175 ] 2177 Figure 19: Example 3: BCB Abstract Security Block (CBOR Diagnostic 2178 Notation) 2180 The CBOR encoding of the BCB block-type-specific-data field (the 2181 abstract security block) is 0x8101020182028202018382014c5477656c76653 2182 1323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97. 2184 A.3.4.3. Representations 2186 The BCB wrapping this abstract security block is as follows. 2188 [ 2189 12, / type code / 2190 4, / block number / 2191 1, / flags - block must be replicated in every fragment / 2192 0, / CRC type / 2193 h'8101020182028202018382014c5477656c766531323132313282020182040081 2194 820150da08f4d8936024ad7c6b3b800e73dd97', 2195 ] 2197 Figure 20: Example 3: BCB (CBOR Diagnostic Notation) 2199 The CBOR encoding of the BCB block is 0x850c0401005833810102018202820 2200 2018382014c5477656c766531323132313282020182040081820150da08f4d8936024 2201 ad7c6b3b800e73dd97. 2203 A.3.5. Final Bundle 2205 The CBOR encoding of the full output bundle, with the BIB and BCB 2206 added is: 0x9f88070000820282010282028202018202820201820018281a000f424 2207 0850b030000585a820002010182028203008282010582030082820158208e059b8e71 2208 f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8e 2209 ba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058 2210 338101020182028202018382014c5477656c766531323132313282020182040081820 2211 150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a 2212 09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff. 2214 A.4. Example 4: Security Blocks with Full Scope 2216 This example shows the addition of a BIB and BCB to a sample bundle. 2217 A BIB is added to provide integrity over the payload block and a BCB 2218 is added for confidentiality over the payload and BIB. 2220 The integrity scope and additional authentication data will bind the 2221 primary block, target header, and the security header. 2223 A.4.1. Original Bundle 2225 The following diagram shows the original bundle before the security 2226 blocks have been added. 2228 Block Block Block 2229 in Bundle Type Number 2230 +========================================+=======+========+ 2231 | Primary Block | N/A | 0 | 2232 +----------------------------------------+-------+--------+ 2233 | Payload Block | 1 | 1 | 2234 +----------------------------------------+-------+--------+ 2236 Figure 21: Example 4 Original Bundle 2238 A.4.1.1. Primary Block 2240 The primary block used in this example is identical to the primary 2241 block presented in Example 1 Appendix A.1.1.1. 2243 In summary, the CBOR encoding of the primary block is 2244 0x88070000820282010282028202018202820201820018281a000f4240. 2246 A.4.1.2. Payload Block 2248 The payload block used in this example is identical to the payload 2249 block presented in Example 1 Appendix A.1.1.2. 2251 In summary, the CBOR encoding of the payload block is 0x8501010000582 2252 052656164792047656e657261746520612033322062797465207061796c6f6164. 2254 A.4.1.3. Bundle CBOR Representation 2256 A BPv7 bundle is represented as an indefinite-length array consisting 2257 of the blocks comprising the bundle, with a terminator character at 2258 the end. 2260 The CBOR encoding of the original bundle is 0x9f880700008202820102820 2261 28202018202820201820018281a000f42408501010000582052656164792047656e65 2262 7261746520612033322062797465207061796c6f6164ff. 2264 A.4.2. Security Operation Overview 2266 This example provides: 2268 a BIB with the BIB-HMAC-SHA2 security context to provide an 2269 integrity mechanism over the payload block. 2271 a BCB with the BCB-AES-GCM security context to provide a 2272 confidentiality mechanism over the payload block and BIB. 2274 The following diagram shows the resulting bundle after the security 2275 blocks are added. 2277 Block Block Block 2278 in Bundle Type Number 2279 +========================================+=======+========+ 2280 | Primary Block | N/A | 0 | 2281 +----------------------------------------+-------+--------+ 2282 | Bundle Integrity Block (Encrypted) | 11 | 3 | 2283 | OP(bib-integrity, target=1) | | | 2284 +----------------------------------------+-------+--------+ 2285 | Bundle Confidentiality Block | 12 | 2 | 2286 | OP(bcb-confidentiality, targets=1, 3) | | | 2287 +----------------------------------------+-------+--------+ 2288 | Payload Block (Encrypted) | 1 | 1 | 2289 +----------------------------------------+-------+--------+ 2291 Figure 22: Example 4 Resulting Bundle 2293 A.4.3. Bundle Integrity Block 2295 In this example, a BIB is used to carry an integrity signature over 2296 the payload block. The IPPT contains the payload block block-type- 2297 specific data, primary block data, the payload block header, and the 2298 BIB header. That is, all additional headers are included in the 2299 IPPT. 2301 A.4.3.1. Configuration, Parameters, and Results 2303 For this example, the following configuration and security parameters 2304 are used to generate the security results indicated. 2306 This BIB has a single target and includes a single security result: 2307 the calculated signature over the Payload block. 2309 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2310 SHA Variant: HMAC 384/384 2311 Scope Flags: h'07' (all additional headers) 2312 Primary Block Data: h'88070000820282010282028202018202 2313 820201820018281a000f4240 2314 Payload Data: h'52656164792047656e65726174652061 2315 2033322062797465207061796c6f6164' 2316 Payload Header: h'85010100005820' 2317 BIB Header: h'850b0300005845' 2318 Payload Signature: h'07c84d929f83bee4690130729d77a1bd 2319 da9611cd6598e73d0659073ea74e8c27 2320 523b02193cb8ba64be58dbc556887aca 2322 Figure 23: Example 4: Configuration, Parameters, and Results for the 2323 BIB 2325 A.4.3.2. Abstract Security Block 2327 The abstract security block structure of the BIB's block-type- 2328 specific-data field for this application is as follows. 2330 [1], / Security Target - Payload block / 2331 1, / Security Context ID - BIB-HMAC-SHA2 / 2332 1, / Security Context Flags - Parameters Present / 2333 [2,[2, 1]], / Security Source - ipn:2.1 / 2334 [ / Security Parameters - 2 Parameters / 2335 [1, 6], / SHA Variant - HMAC 384/384 / 2336 [3, h'07'] / Scope Flags - All additional headers in the SHA Hash / 2337 ], 2338 [ / Security Results: 1 Result / 2339 [1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d 2340 0659073ea74e8c27523b02193cb8ba64be58dbc556887aca'] 2341 ] 2343 Figure 24: Example 4: BIB Abstract Security Block (CBOR Diagnostic 2344 Notation) 2346 The CBOR encoding of the BIB block-type-specific-data field (the 2347 abstract security block) is 0x810101018202820201828201068203078182015 2348 83007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c2752 2349 3b02193cb8ba64be58dbc556887aca. 2351 A.4.3.3. Representations 2353 The BIB wrapping this abstract security block is as follows. 2355 [ 2356 11, / type code / 2357 3, / block number / 2358 0, / flags / 2359 0, / CRC type / 2360 h'81010101820282020182820106820307818201583007c84d929f83bee4690130 2361 729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db 2362 c556887aca', 2363 ] 2365 Figure 25: Example 4: BIB (CBOR Diagnostic Notation) 2367 The CBOR encoding of the BIB block is 0x850b0300005845810101018202820 2368 20182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd65 2369 98e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca. 2371 A.4.4. Bundle Confidentiality Block 2373 In this example, a BCB is used encrypt the payload block and the BIB 2374 that provides integrity over the payload. 2376 A.4.4.1. Configuration, Parameters, and Results 2378 For this example, the following configuration and security parameters 2379 are used to generate the security results indicated. 2381 This BCB has two targets: the payload block and BIB. Four security 2382 results are generated: cipher text which replaces the plain text 2383 block-type-specific data of the payload block, cipher text to encrypt 2384 the BIB, and authentication tags for both the payload block and BIB. 2386 Key: h'71776572747975696f70617364666768 2387 71776572747975696f70617364666768' 2388 IV: h'5477656c7665313231323132' 2389 AES Variant: A256GCM 2390 Scope Flags: h'07' (All additional headers) 2391 Payload Data: h'52656164792047656e65726174652061 2392 2033322062797465207061796c6f6164' 2393 BIB Data: h'81010101820282020182820106820307 2394 818201583007c84d929f83bee4690130 2395 729d77a1bdda9611cd6598e73d065907 2396 3ea74e8c27523b02193cb8ba64be58db 2397 c556887aca 2398 BIB 2399 Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e' 2400 Payload Block 2401 Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff' 2402 Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 2403 319bb227706000abc8fcac3b9bb9c87e' 2404 BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 2405 902a815f221ebc837a134efc13bfa82a 2406 2d5d317747da3eb54acef4ca839bd961 2407 487284404259b60be12b8aed2f3e8a36 2408 2836529f66' 2410 Figure 26: Example 4: Configuration, Parameters, and Results for the 2411 BCB 2413 A.4.4.2. Abstract Security Block 2415 The abstract security block structure of the BCB's block-type- 2416 specific-data field for this application is as follows. 2418 [3, 1], / Security Targets / 2419 2, / Security Context ID - BCB-AES-GCM / 2420 1, / Security Context Flags - Parameters Present / 2421 [2,[2, 1]], / Security Source - ipn:2.1 / 2422 [ / Security Parameters - 3 Parameters / 2423 [1, h'5477656c7665313231323132'], / Initialization Vector / 2424 [2, 3], / AES Variant - AES 256 / 2425 [4, h'07'] / Scope Flags - All headers in SHA hash / 2426 ], 2427 [ / Security Results: 2 Results / 2428 [1, h'c95ed4534769b046d716e1cdfd00830e'], / BIB Auth. Tag / 2429 [1, h'0e365c700e4bb19c0d991faff5345aff'] / Payload Auth. Tag / 2430 ] 2432 Figure 27: Example 4: BCB Abstract Security Block (CBOR Diagnostic 2433 Notation) 2435 The CBOR encoding of the BCB block-type-specific-data field (the 2436 abstract security block) is 0x820301020182028202018382014c5477656c766 2437 531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201 2438 500e365c700e4bb19c0d991faff5345aff. 2440 A.4.4.3. Representations 2442 The BCB wrapping this abstract security block is as follows. 2444 [ 2445 12, / type code / 2446 2, / block number / 2447 1, / flags - block must be replicated in every fragment / 2448 0, / CRC type / 2449 h'820301020182028202018382014c5477656c7665313231323132820203820407 2450 82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d 2451 991faff5345aff', 2452 ] 2454 Figure 28: Example 4: BCB (CBOR Diagnostic Notation) 2456 The CBOR encoding of the BCB block is 0x850c0201005847820301020182028 2457 202018382014c5477656c766531323132313282020382040782820150c95ed4534769 2458 b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. 2460 A.4.5. Final Bundle 2462 The CBOR encoding of the full output bundle, with the security blocks 2463 added and payload block and BIB encrypted is: 0x9f8807000082028201028 2464 2028202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb9 2465 4d952175167df0902a815f221ebc837a134efc13bfa82a2d5d317747da3eb54acef4c 2466 a839bd961487284404259b60be12b8aed2f3e8a362836529f66 850c0201005847820 2467 301020182028202018382014c5477656c766531323132313282020382040782820150 2468 c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345af 2469 f8501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac 2470 3b9bb9c87eff. 2472 Appendix B. Acknowledgements 2474 Amy Alford of the Johns Hopkins University Applied Physics Laboratory 2475 contributed useful review and analysis of these security contexts. 2477 Authors' Addresses 2478 Edward J. Birrane, III 2479 The Johns Hopkins University Applied 2480 Physics Laboratory 2481 11100 Johns Hopkins Rd. 2482 Laurel, MD 20723 2483 US 2485 Phone: +1 443 778 7423 2486 Email: Edward.Birrane@jhuapl.edu 2488 Alex White 2489 The Johns Hopkins University Applied 2490 Physics Laboratory 2491 11100 Johns Hopkins Rd. 2492 Laurel, MD 20723 2493 US 2495 Phone: +1 443 778 0845 2496 Email: Alex.White@jhuapl.edu 2498 Sarah Heiner 2499 The Johns Hopkins University Applied 2500 Physics Laboratory 2501 11100 Johns Hopkins Rd. 2502 Laurel, MD 20723 2503 US 2505 Phone: +1 240 592 3704 2506 Email: Sarah.Heiner@jhuapl.edu