idnits 2.17.1 draft-ietf-dtn-bpsec-default-sc-06.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 (May 3, 2021) is 1082 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 1898 -- Looks like a reference, but probably isn't: '40' on line 1354 -- Looks like a reference, but probably isn't: '1' on line 2142 -- Looks like a reference, but probably isn't: '7' on line 2149 -- Looks like a reference, but probably isn't: '3' on line 2148 -- Looks like a reference, but probably isn't: '2' on line 2148 -- Looks like a reference, but probably isn't: '4' on line 2149 -- Looks like a reference, but probably isn't: '5' on line 1817 -- Looks like a reference, but probably isn't: '6' on line 2062 -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-GCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-KW' -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC' ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 14 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: November 4, 2021 JHU/APL 6 May 3, 2021 8 BPSec Default Security Contexts 9 draft-ietf-dtn-bpsec-default-sc-06 11 Abstract 13 This document defines default integrity and confidentiality security 14 contexts that may 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 November 4, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 6 61 3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 7 62 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 7 63 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 8 64 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 8 66 3.6. Canonicalization Algorithms . . . . . . . . . . . . . . . 9 67 3.7. Processing . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.7.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 10 69 3.7.2. Keyed Hash Verification . . . . . . . . . . . . . . . 11 70 4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 12 71 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 14 75 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 15 76 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 15 77 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 16 78 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 16 79 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 17 81 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 17 82 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 18 83 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 18 84 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 19 85 4.7.1. Cipher text related calculations . . . . . . . . . . 19 86 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 20 87 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 21 89 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 22 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 5.1. Security Context Identifiers . . . . . . . . . . . . . . 24 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 93 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 24 94 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 25 95 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 6.4. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 26 98 7. Normative References . . . . . . . . . . . . . . . . . . . . 27 99 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28 100 A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 28 101 A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 28 102 A.1.2. Security Operation Overview . . . . . . . . . . . . . 30 103 A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 31 104 A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 32 105 A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 33 106 A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 33 107 A.2.2. Security Operation Overview . . . . . . . . . . . . . 34 108 A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 34 109 A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 36 110 A.3. Example 3: Security Blocks from Multiple Sources . . . . 36 111 A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 36 112 A.3.2. Security Operation Overview . . . . . . . . . . . . . 38 113 A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 39 114 A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 41 115 A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 42 116 A.4. Example 4: Security Blocks with Full Scope . . . . . . . 43 117 A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 43 118 A.4.2. Security Operation Overview . . . . . . . . . . . . . 44 119 A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 44 120 A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 46 121 A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 48 122 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 48 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 125 1. Introduction 127 The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] 128 specification provides inter-bundle integrity and confidentiality 129 operations for networks deploying the Bundle Protocol (BP) 130 [I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry 131 security information produced under the auspices of some security 132 context. 134 This document defines two security contexts (one for an integrity 135 service and one for a confidentiality service) for populating BPSec 136 Block Integrity Blocks (BIBs) and Block Confidentiality Blocks 137 (BCBs). 139 These contexts generate information that MUST be encoded using the 140 CBOR specification documented in [RFC8949]. 142 2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 3. Integrity Security Context BIB-HMAC-SHA2 152 3.1. Overview 154 The BIB-HMAC-SHA2 security context provides a keyed hash over a set 155 of plain text information. This context uses the Secure Hash 156 Algorithm 2 (SHA-2) discussed in [SHS] combined with the HMAC keyed 157 hash discussed in [HMAC]. The combination of HMAC and SHA-2 as the 158 integrity mechanism for this security context was selected for two 159 reasons: 161 1. The use of symmetric keys allows this security context to be used 162 in places where an asymmetric-key infrastructure (such as a 163 public key infrastructure) may be impractical. 165 2. The combination HMAC-SHA2 represents a well-supported and well- 166 understood integrity mechanism with multiple implementations 167 available. 169 BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the 170 supported length of the SHA-2 hash value. These variants correspond 171 to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in 172 [RFC8152] Table 7: HMAC Algorithm Values. The selection of which 173 variant is used by this context is provided as a security context 174 parameter. 176 The output of the HMAC MUST be equal to the size of the SHA2 hashing 177 function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits 178 for SHA-512. 180 The BIB-HMAC-SHA2 security context MUST have the security context 181 identifier specified in Section 5.1. 183 3.2. Scope 185 The scope of BIB-HMAC-SHA2 is the set of information used to produce 186 the plain text over which a keyed hash is calculated. This plain 187 text is termed the "Integrity Protected Plain Text" (IPPT). The 188 content of the IPPT is constructed as the concatenation of 189 information whose integrity is being preserved from the BIB-HMAC-SHA2 190 security source to its security acceptor. There are four types of 191 information that can be used in the generation of the IPPT, based on 192 how broadly the concept of integrity is being applied. These four 193 types of information, whether they are required, and why they are 194 important for integrity, are discussed as follows. 196 Security target contents 197 The contents of the block-type-specific data field of the 198 security target MUST be included in the IPPT. Including this 199 information protects the security target data and is considered 200 the minimal, required set of information for an integrity service 201 on the security target. 203 Primary block 204 The primary block identifies a bundle and, once created, the 205 contents of this block are immutable. Changes to the primary 206 block associated with the security target indicate that the 207 security target (and BIB) may no longer be in the correct bundle. 209 For example, if a security target and associated BIB are copied 210 from one bundle to another bundle, the BIB may still contain a 211 verifiable signature for the security target unless information 212 associated with the bundle primary block is included in the keyed 213 hash carried by the BIB. 215 Including this information in the IPPT protects the integrity of 216 the association of the security target with a specific bundle. 218 Security target other fields 219 The other fields of the security target include block 220 identification and processing information. Changing this 221 information changes how the security target is treated by nodes 222 in the network even when the "user data" of the security target 223 are otherwise unchanged. 225 For example, if the block processing control flags of a security 226 target are different at a security verifier than they were 227 originally set at the security source then the policy for 228 handling the security target has been modified. 230 Including this information in the IPPT protects the integrity of 231 the policy and identification of the security target data. 233 BIB other fields 234 The other fields of the BIB include block identification and 235 processing information. Changing this information changes how 236 the BIB is treated by nodes in the network, even when other 237 aspects of the BIB are unchanged. 239 For example, if the block processing control flags of the BIB are 240 different at a security verifier than they were originally set at 241 the security source, then the policy for handling the BIB has 242 been modified. 244 Including this information in the IPPT protects the integrity of 245 the policy and identification of the security service in the 246 bundle. 248 NOTE: The security context identifier and security context 249 parameters of the security block are not included in the IPPT 250 because these parameters, by definition, are required to verify 251 or accept the security service. Successful verification at 252 security verifiers and security acceptors implies that these 253 parameters were unchanged since being specified at the security 254 source. 256 The scope of the BIB-HMAC-SHA2 security context is configured using 257 an optional security context parameter. 259 3.3. Parameters 261 BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, 262 communicate key information, and define the scope of the IPPT. 264 3.3.1. SHA Variant 266 This optional parameter identifies which variant of the SHA-2 267 algorithm is to be used in the generation of the authentication code. 269 This value MUST be encoded as a CBOR unsigned integer. 271 Valid values for this parameter are as follows. 273 SHA Variant Parameter Values 275 +-------+-----------------------------------------------------------+ 276 | Value | Description | 277 +-------+-----------------------------------------------------------+ 278 | 5 | HMAC 256/256 as defined in [RFC8152] Table 7: HMAC | 279 | | Algorithm Values | 280 | 6 | HMAC 384/384 as defined in [RFC8152] Table 7: HMAC | 281 | | Algorithm Values | 282 | 7 | HMAC 512/512 as defined in [RFC8152] Table 7: HMAC | 283 | | Algorithm Values | 284 +-------+-----------------------------------------------------------+ 286 Table 1 288 When not provided, implementations SHOULD assume a value of 6 289 (indicating use of HMAC 384/384), unless an alternate default is 290 established by local security policy at the security source, 291 verifiers, or acceptor of this integrity service. 293 3.3.2. Wrapped Key 295 This optional parameter contains the output of the AES key wrap 296 authenticated encryption function (KW-AE) as defined in [AES-KW]. 297 Specifically, this parameter holds the cipher text produced when 298 running the KW-AE algorithm with the input string being the symmetric 299 HMAC key used to generate the security results present in the 300 security block. The value of this parameter is used as input to the 301 AES key wrap authenticated decryption function (KW-AD) at security 302 verifiers and security acceptors to determine the symmetric HMAC key 303 needed for the proper validation of the security results in the 304 security block. 306 This value MUST be encoded as a CBOR byte string. 308 If this parameter is not present then security verifiers and 309 acceptors MUST determine the proper key as a function of their local 310 BPSec policy and configuration. 312 3.3.3. Integrity Scope Flags 314 This optional parameter contains a series of flags that describe what 315 information is to be included with the block-type-specific data when 316 constructing the IPPT value. 318 This value MUST be represented as a CBOR unsigned integer, the value 319 of which MUST be processed as a bit field containing no more than 8 320 bits. 322 Bits in this field represent additional information to be included 323 when generating an integrity signature over the security target. 324 These bits are defined as follows. 326 - Bit 0 (the low-order bit, 0x1): Primary Block Flag. 328 - Bit 1 (0x02): Target Header Flag. 330 - Bit 2 (0x03): Security Header Flag. 332 - Bits 3-7 are reserved. 334 3.3.4. Enumerations 336 BIB-HMAC-SHA2 defines the following security context parameters. 338 BIB-HMAC-SHA2 Security Parameters 340 +----+-----------------------+--------------------+---------------+ 341 | Id | Name | CBOR Encoding Type | Default Value | 342 +----+-----------------------+--------------------+---------------+ 343 | 1 | SHA Variant | UINT | 6 | 344 | 2 | Wrapped Key | Byte String | NONE | 345 | 4 | Integrity Scope Flags | UINT | 0x7 | 346 +----+-----------------------+--------------------+---------------+ 348 Table 2 350 3.4. Results 352 BIB-HMAC-SHA2 defines the following security results. 354 BIB-HMAC-SHA2 Security Results 356 +--------+----------+-------------+---------------------------------+ 357 | Result | Result | CBOR | Description | 358 | Id | Name | Encoding | | 359 | | | Type | | 360 +--------+----------+-------------+---------------------------------+ 361 | 1 | Expected | byte string | The output of the HMAC | 362 | | HMAC | | calculation at the security | 363 | | | | source. | 364 +--------+----------+-------------+---------------------------------+ 366 Table 3 368 3.5. Key Considerations 370 HMAC keys used with this context MUST be symmetric and MUST have a 371 key length equal to the output of the HMAC. For this reason, HMAC 372 keys will be integer divisible by 8 bytes and special padding-aware 373 AES key wrap algorithms are not needed. 375 It is assumed that any security verifier or security acceptor 376 performing an integrity verification can determine the proper HMAC 377 key to be used. Potential sources of the HMAC key include (but are 378 not limited to) the following: 380 Pre-placed keys selected based on local policy. 382 Keys extracted from material carried in the BIB. 384 Session keys negotiated via a mechanism external to the BIB. 386 When an AES-KW wrapped key is present in a security block, it is 387 assumed that security verifiers and security acceptors can 388 independently determine the key encryption key (KEK) used in the 389 wrapping of the symmetric HMAC key. 391 As discussed in Section 6 and emphasized here, it is strongly 392 recommended that keys be protected once generated, both when they are 393 stored and when they are transmitted. 395 3.6. Canonicalization Algorithms 397 This section defines the canonicalization algorithm used to prepare 398 the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The 399 construction of the IPPT depends on the settings of the integrity 400 scope flags that may be provided as part of customizing the behavior 401 of this security context. 403 In all cases, the canonical form of any portion of an extension block 404 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 405 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 406 the canonical forms for extension blocks defined in 407 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 408 are represented in CBOR. 410 The IPPT is constructed using the following process. 412 1. The canonical form of the IPPT starts as the empty set with 413 length 0. 415 2. If the integrity scope parameter is present and the primary block 416 flag is set to 1, then a canonical form of the bundle's primary 417 block MUST be calculated and the result appended to the IPPT. 419 3. If the integrity scope parameter is present and the target header 420 flag is set to 1, then the canonical form of the block type code, 421 block number, and block processing control flags associated with 422 the security target MUST be calculated and, in that order, 423 appended to the IPPT. 425 4. If the integrity scope parameter is present and the security 426 header flag is set to 1, then the canonical form of the block 427 type code, block number, and block processing control flags 428 associated with the BIB MUST be calculated and, in that order, 429 appended to the IPPT. 431 5. The canonical form of the security target block-type-specific 432 data MUST be calculated and appended to the IPPT. 434 3.7. Processing 436 3.7.1. Keyed Hash Generation 438 During keyed hash generation, two inputs are prepared for the the 439 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 440 data items MUST be generated as follows. 442 The HMAC key MUST have the appropriate length as required by local 443 security policy. The key can be generated specifically for this 444 integrity service, given as part of local security policy, or 445 through some other key management mechanism as discussed in 446 Section 3.5. 448 Prior to the generation of the IPPT, if a CRC value is present for 449 the target block of the BIB, then that CRC value MUST be removed 450 from the target block. This involves both removing the CRC value 451 from the target block and setting the CRC Type field of the target 452 block to "no CRC is present." 454 Once CRC information is removed, the IPPT MUST be generated as 455 discussed in Section 3.6. 457 Upon successful hash generation the following actions MUST occur. 459 The keyed hash produced by the HMAC/SHA2 variant MUST be added as 460 a security result for the BIB representing the security operation 461 on this security target, as discussed in Section 3.4). 463 Finally, the BIB containing information about this security operation 464 MUST be updated as follows. These operations may occur in any order. 466 The security context identifier for the BIB MUST be set to the 467 context identifier for BIB-HMAC-SHA2. 469 Any local flags used to generate the IPPT SHOULD be placed in the 470 integrity scope flags security parameter for the BIB unless these 471 flags are expected to be correctly configured at security 472 verifiers and acceptors in the network. 474 The HMAC key MAY be wrapped using the NIST AES-KW algorithm and 475 the results of the wrapping added as the wrapped key security 476 parameter for the BIB. 478 The SHA variant used by this security context SHOULD be added as 479 the SHA variant security parameter for the BIB if it differs from 480 the default key length. Otherwise, this parameter MAY be omitted 481 if doing so provides a useful reduction in message sizes. 483 Problems encountered in the keyed hash generation MUST be processed 484 in accordance with local BPSec security policy. 486 3.7.2. Keyed Hash Verification 488 During keyed hash verification, the input of the security target and 489 a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. 491 During keyed hash verification, two inputs are prepared for the 492 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 493 data items MUST be generated as follows. 495 The HMAC key MUST be derived using the wrapped key security 496 parameter if such a parameter is included in the security context 497 parameters of the BIB. Otherwise, this key MUST be derived in 498 accordance with security policy at the verifying node as discussed 499 in Section 3.5. 501 The IPPT MUST be generated as discussed in Section 3.6 with the 502 value of integrity scope flags being taken from the integrity 503 scope flags security context parameter. If the integrity scope 504 flags parameter is not included in the security context parameters 505 then these flags MAY be derived from local security policy. 507 The calculated HMAC output MUST be compared to the expected HMAC 508 output encoded in the security results of the BIB for the security 509 target. If the calculated HMAC and expected HMAC are identical, the 510 verification MUST be considered a success. Otherwise, the 511 verification MUST be considered a failure. 513 If the verification fails or otherwise experiences an error, or if 514 any needed parameters are missing, then the verification MUST be 515 treated as failed and processed in accordance with local security 516 policy. 518 This security service is removed from the bundle at the security 519 acceptor as required by the BPSec specification. If the security 520 acceptor is not the bundle destination and if no other integrity 521 service is being applied to the target block, then a CRC MUST be 522 included for the target block. The CRC type, as determined by 523 policy, is set in the target block's CRC type field and the 524 corresponding CRC value is added as the CRC field for that block. 526 4. Security Context BCB-AES-GCM 528 4.1. Overview 530 The BCB-AES-GCM security context replaces the block-type-specific 531 data field of its security target with cipher text generated using 532 the Advanced Encryption Standard (AES) cipher operating in Galois/ 533 Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the 534 cipher suite for this confidentiality mechanism for several reasons: 536 1. The selection of a symmetric-key cipher suite allows for 537 relatively smaller keys than asymmetric-key cipher suites. 539 2. The selection of a symmetric-key cipher suite allows this 540 security context to be used in places where an asymmetric-key 541 infrastructure (such as a public key infrastructure) may be 542 impractical. 544 3. The use of the Galois/Counter Mode produces cipher-text with the 545 same size as the plain text making the replacement of target 546 block information easier as length fields do not need to be 547 changed. 549 4. The AES-GCM cipher suite provides authenticated encryption, as 550 required by the BPSec protocol. 552 Additionally, the BCB-AES-GCM security context generates an 553 authentication tag based on the plain text value of the block-type- 554 specific data and other additional authenticated data that may be 555 specified via parameters to this security context. 557 This security context supports two variants of AES-GCM, based on the 558 supported length of the symmetric key. These variants correspond to 559 A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value 560 for AES-GCM. 562 The BCB-AES-GCM security context MUST have the security context 563 identifier specified in Section 5.1. 565 4.2. Scope 567 There are two scopes associated with BCB-AES-GCM: the scope of the 568 confidentiality service and the scope of the authentication service. 569 The first defines the set of information provided to the AES-GCM 570 cipher for the purpose of producing cipher text. The second defines 571 the set of information used to generate an authentication tag. 573 The scope of the confidentiality service defines the set of 574 information provided to the AES-GCM cipher for the purpose of 575 producing cipher text. This MUST be the full set of plain text 576 contained in the block-type-specific data field of the security 577 target. 579 The scope of the authentication service defines the set of 580 information used to generate an authentication tag carried with the 581 security block. This information includes the data included in the 582 confidentiality service and MAY include other information (additional 583 authenticated data), as follows. 585 Primary block 586 The primary block identifies a bundle and, once created, the 587 contents of this block are immutable. Changes to the primary 588 block associated with the security target indicate that the 589 security target (and BCB) may no longer be in the correct bundle. 591 For example, if a security target and associated BCB are copied 592 from one bundle to another bundle, the BCB may still be able to 593 decrypt the security target even though these blocks were never 594 intended to exist in the copied-to bundle. 596 Including this information as part of additional authenticated 597 data ensures that security target (and security block) appear in 598 the same bundle at the time of decryption as at the time of 599 encryption. 601 Security target other fields 602 The other fields of the security target include block 603 identification and processing information. Changing this 604 information changes how the security target is treated by nodes 605 in the network even when the "user data" of the security target 606 are otherwise unchanged. 608 For example, if the block processing control flags of a security 609 target are different at a security verifier than they were 610 originally set at the security source then the policy for 611 handling the security target has been modified. 613 Including this information as part of additional authenticated 614 data ensures that the cipher text in the security target will not 615 be used with a different set of block policy than originally set 616 at the time of encryption. 618 BCB other fields 619 The other fields of the BCB include block identification and 620 processing information. Changing this information changes how 621 the BCB is treated by nodes in the network, even when other 622 aspects of the BCB are unchanged. 624 For example, if the block processing control flags of the BCB are 625 different at a security acceptor than they were originally set at 626 the security source then the policy for handling the BCB has been 627 modified. 629 Including this information as part of additional authenticated 630 data ensures that the policy and identification of the security 631 service in the bundle has not changed. 633 NOTE: The security context identifier and security context 634 parameters of the security block are not included as additional 635 authenticated data because these parameters, by definition, are 636 those needed to verify or accept the security service. 637 Therefore, it is expected that changes to these values would 638 result in failures at security verifiers and security acceptors. 640 The scope of the BCB-AES-GCM security context is configured using an 641 optional security context parameter. 643 4.3. Parameters 645 BCB-AES-GCM can be parameterized to specify the AES variant, 646 initialization vector, key information, and identify additional 647 authenticated data. 649 4.3.1. Initialization Vector (IV) 651 This optional parameter identifies the initialization vector (IV) 652 used to initialize the AES-GCM cipher. 654 The length of the initialization vector, prior to any CBOR encoding, 655 MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used 656 unless local security policy requires a different length. 658 This value MUST be encoded as a CBOR byte string. 660 The initialization vector may have any value with the caveat that a 661 value MUST NOT be re-used for multiple encryptions using the same 662 encryption key. This value MAY be re-used when encrypting with 663 different keys. For example, if each encryption operation using BCB- 664 AES-GCM uses a newly generated key, then the same IV may be reused. 666 4.3.2. AES Variant 668 This optional parameter identifies the AES variant being used for the 669 AES-GCM encryption, where the variant is identified by the length of 670 key used. 672 This value MUST be encoded as a CBOR unsigned integer. 674 Valid values for this parameter are as follows. 676 AES Variant Parameter Values 678 +-------+-----------------------------------------------------------+ 679 | Value | Description | 680 +-------+-----------------------------------------------------------+ 681 | 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values | 682 | | for AES-GCM | 683 | 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values | 684 | | for AES-GCM | 685 +-------+-----------------------------------------------------------+ 687 When not provided, implementations SHOULD assume a value of 3 688 (indicating use of A256GCM), unless an alternate default is 689 established by local security policy at the security source, 690 verifier, or acceptor of this integrity service. 692 Regardless of the variant, the generated authentication tag MUST 693 always be 128 bits. 695 4.3.3. Wrapped Key 697 This optional parameter contains the output of the AES key wrap 698 authenticated encryption function (KW-AE) as defined in [AES-KW]. 699 Specifically, this parameter holds the cipher text produced when 700 running the KW-AE algorithm with the input string being the symmetric 701 AES key used to generate the security results present in the security 702 block. The value of this parameter is used as input to the AES key 703 wrap authenticated decryption function (KW-AD) at security verifiers 704 and security acceptors to determine the symmetric AES key needed for 705 the proper decryption of the security results in the security block. 707 This value MUST be encoded as a CBOR byte string. 709 If this parameter is not present then security verifiers and 710 acceptors MUST determine the proper key as a function of their local 711 BPSec policy and configuration. 713 4.3.4. AAD Scope Flags 715 This optional parameter contains a series of flags that describe what 716 information is to be included with the block-type-specific data of 717 the security target as part of additional authenticated data (AAD). 719 This value MUST be represented as a CBOR unsigned integer, the value 720 of which MUST be processed as a bit field containing no more than 8 721 bits. 723 Bits in this field represent additional information to be included 724 when generating an integrity signature over the security target. 725 These bits are defined as follows. 727 - Bit 0 (the low-order bit, 0x1): Primary Block Flag. 729 - Bit 1 (0x02): Target Header Flag. 731 - Bit 2 (0x03): Security Header Flag. 733 - Bits 3-7 are reserved. 735 4.3.5. Enumerations 737 BCB-AES-GCM defines the following security context parameters. 739 BCB-AES-GCM Security Parameters 741 +----+-----------------------+--------------------+---------------+ 742 | Id | Name | CBOR Encoding Type | Default Value | 743 +----+-----------------------+--------------------+---------------+ 744 | 1 | Initialization Vector | Byte String | NONE | 745 | 2 | AES Variant | UINT | 3 | 746 | 3 | Wrapped Key | Byte String | NONE | 747 | 4 | AAD Scope Flags | UINT | 0x7 | 748 +----+-----------------------+--------------------+---------------+ 750 Table 4 752 4.4. Results 754 The BCB-AES-GCM security context produces a single security result 755 carried in the security block: the authentication tag. 757 NOTES: 759 The cipher text generated by the cipher suite is not considered a 760 security result as it is stored in the block-type-specific data 761 field of the security target block. When operating in GCM mode, 762 AES produces cipher text of the same size as its plain text and, 763 therefore, no additional logic is required to handle padding or 764 overflow caused by the encryption in most cases (see below). 766 If the generated cipher text contains the authentication tag and 767 the tag can be separated from the cipher text then the tag MUST be 768 separated and stored in the authentication tag security result 769 field. 771 If the generated cipher text contains the authentication tag and 772 the tag cannot be separated from the cipher text then the tag MUST 773 NOT be included in the authentication tag security result field. 774 Instead the security target block MUST be resized to accommodate 775 the additional 128 bits of authentication tag included in the 776 generated cipher text. 778 4.4.1. Authentication Tag 780 The authentication tag is generated by the cipher suite over the 781 security target plain text input to the cipher suite as combined with 782 any optional additional authenticated data. This tag is used to 783 ensure that the plain text (and important information associated with 784 the plain text) is authenticated prior to decryption. 786 If the authentication tag is included in the cipher text placed in 787 the security target block-type-specific data field, then this 788 security result MUST NOT be included in the BCB for that security 789 target. 791 The length of the authentication tag, prior to any CBOR encoding, 792 MUST be 128 bits. 794 This value MUST be encoded as a CBOR byte string. 796 4.4.2. Enumerations 798 BCB-AES-GCM defines the following security context parameters. 800 BCB-AES-GCM Security Results 802 +-----------+--------------------+--------------------+ 803 | Result Id | Result Name | CBOR Encoding Type | 804 +-----------+--------------------+--------------------+ 805 | 1 | Authentication Tag | Byte String | 806 +-----------+--------------------+--------------------+ 808 Table 5 810 4.5. Key Considerations 812 Keys used with this context MUST be symmetric and MUST have a key 813 length equal to the key length defined in the security context 814 parameters or as defined by local security policy at security 815 verifiers and acceptors. For this reason, content-encrypting keys 816 will be integer divisible by 8 bytes and special padding-aware AES 817 key wrap algorithms are not needed. 819 It is assumed that any security verifier or security acceptor can 820 determine the proper key to be used. Potential sources of the key 821 include (but are not limited to) the following. 823 Pre-placed keys selected based on local policy. 825 Keys extracted from material carried in the BCB. 827 Session keys negotiated via a mechanism external to the BCB. 829 When an AES-KW wrapped key is present in a security block, it is 830 assumed that security verifiers and security acceptors can 831 independently determine the key encryption key (KEK) used in the 832 wrapping of the symmetric AES content-encrypting key. 834 The security provided by block ciphers is reduced as more data is 835 processed with the same key. The total number of bytes processed 836 with a single key for AES-GCM is recommended to be less than 2^64, as 837 described in Appendix B of [AES-GCM]. 839 As discussed in Section 6 and emphasized here, it is strongly 840 recommended that keys be protected once generated, both when they are 841 stored and when they are transmitted. 843 4.6. GCM Considerations 845 The GCM cryptographic mode of AES has specific requirements that MUST 846 be followed by implementers for the secure function of the BCB-AES- 847 GCM security context. While these requirements are well documented 848 in [AES-GCM], some of them are repeated here for emphasis. 850 The pairing of an IV and a security key MUST be unique. An IV 851 MUST NOT be used with a security key more than one time. If an IV 852 and key pair are repeated then the GCM implementation may be 853 vulnerable to forgery attacks. More information regarding the 854 importance of the uniqueness of the IV value can be found in 855 Appendix A of [AES-GCM]. 857 While any tag-based authentication mechanism has some likelihood 858 of being forged, this probability is increased when using AES-GCM. 859 In particular, short tag lengths combined with very long messages 860 SHOULD be avoided when using this mode. The BCB-AES-GCM security 861 context requires the use of 128-bit authentication tags at all 862 times. Concerns relating to the size of authentication tags is 863 discussed in Appendices B and C of [AES-GCM]. 865 As discussed in Appendix B of [AES-GCM], implementations SHOULD 866 limit the number of unsuccessful verification attempts for each 867 key to reduce the likelihood of guessing tag values. 869 As discussed in the Security Considerations section of 870 [I-D.ietf-dtn-bpsec], delay-tolerant networks may have a higher 871 occurrence of replay attacks due to the store-and-forward nature 872 of the network. Because GCM has no inherent replay attack 873 protection, implementors SHOULD attempt to detect replay attacks 874 by using mechanisms such as those described in Appendix D of 875 [AES-GCM]. 877 4.7. Canonicalization Algorithms 879 This section defines the canonicalization algorithms used to prepare 880 the inputs used to generate both the cipher text and the 881 authentication tag. 883 In all cases, the canonical form of any portion of an extension block 884 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 885 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 886 the canonical forms for extension blocks defined in 887 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 888 are represented in CBOR. 890 4.7.1. Cipher text related calculations 892 The plain text used during encryption MUST be calculated as the 893 single, definite-length CBOR byte string representing the block-type- 894 specific data field of the security target excluding the CBOR byte 895 string identifying byte and optional CBOR byte string length field. 897 For example, consider the following two CBOR byte strings and the 898 plain text that would be extracted from them. 900 CBOR Byte String Examples 902 +------------------------------+---------+--------------------------+ 903 | CBOR Byte String (Hex) | CBOR | Plain Text Part (Hex) | 904 | | Part | | 905 | | (Hex) | | 906 +------------------------------+---------+--------------------------+ 907 | 18ED | 18 | ED | 908 +------------------------------+---------+--------------------------+ 909 | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | 910 +------------------------------+---------+--------------------------+ 912 Table 6 914 Similarly, the cipher text used during decryption MUST be calculated 915 as the single, definite-length CBOR byte string representing the 916 block-type-specific data field excluding the CBOR byte string 917 identifying byte and optional CBOR byte string length field. 919 All other fields of the security target (such as the block type code, 920 block number, block processing control flags, or any CRC information) 921 MUST NOT be considered as part of encryption or decryption. 923 4.7.2. Additional Authenticated Data 925 The construction of additional authenticated data depends on the AAD 926 scope flags that may be provided as part of customizing the behavior 927 of this security context. 929 The canonical form of the AAD input to the BCB-AES-GCM mechanism is 930 constructed using the following process. This process MUST be 931 followed when generating AAD for either encryption or decryption. 933 1. The canonical form of the AAD starts as the empty set with length 934 0. 936 2. If the AAD scope parameter is present and the primary block flag 937 is set to 1, then a canonical form of the bundle's primary block 938 MUST be calculated and the result appended to the AAD. 940 3. If the AAD scope parameter is present and the target header flag 941 is set to 1, then the canonical form of the block type code, 942 block number, and block processing control flags associated with 943 the security target MUST be calculated and, in that order, 944 appended to the AAD. 946 4. If the AAD scope parameter is present and the security header 947 flag is set to 1, then the canonical form of the block type code, 948 block number, and block processing control flags associated with 949 the BIB MUST be calculated and, in that order, appended to the 950 AAD. 952 If, after this process, the AAD remains at length 0, then no AAD 953 exists to be input to the cipher suite. 955 4.8. Processing 957 4.8.1. Encryption 959 During encryption, four inputs are prepared for input to the AES/GCM 960 cipher: the encryption key, the IV, the security target plain text to 961 be encrypted, and any additional authenticated data. These data 962 items MUST be generated as follows. 964 Prior to encryption, if a CRC value is present for the target block, 965 then that CRC value MUST be removed. This requires removing the CRC 966 field from the target block and setting the CRC type field of the 967 target block to "no CRC is present." 969 The encryption key MUST have the appropriate length as required by 970 local security policy. The key may be generated specifically for 971 this encryption, given as part of local security policy, or 972 through some other key management mechanism as discussed in 973 Section 4.5. 975 The IV selected MUST be of the appropriate length. Because 976 replaying an IV in counter mode voids the confidentiality of all 977 messages encrypted with said IV, this context also requires a 978 unique IV for every encryption performed with the same key. This 979 means the same key and IV combination MUST NOT be used more than 980 once. 982 The security target plain text for encryption MUST be generated as 983 discussed in Section 4.7.1. 985 Additional authenticated data, if present, MUST be generated as 986 discussed in Section 4.7.2 with the value of AAD scope flags being 987 taken from local security policy. 989 Upon successful encryption the following actions MUST occur. 991 The cipher text produced by AES/GCM MUST replace the bytes used to 992 define the plain text in the security target block's block-type- 993 specific data field. The block length of the security target MUST 994 be updated if the generated cipher text is larger than the plain 995 text (which can occur when the authentication tag is included in 996 the cipher text calculation, as discussed in Section 4.4). 998 The authentication tag calculated by the AES/GCM cipher MUST be 999 added as a security result for the security target in the BCB 1000 holding results for this security operation. 1002 Cases where the authentication tag is generated as part of the 1003 cipher text MUST be processed as described in Section 4.4. 1005 Finally, the BCB containing information about this security operation 1006 MUST be updated as follows. These operations may occur in any order. 1008 The security context identifier for the BCB MUST be set to the 1009 context identifier for BCB-AES-GCM. 1011 The IV input to the cipher MUST be added as the IV security 1012 parameter for the BCB. 1014 Any local flags used to generated AAD for this cipher MUST be 1015 added as the AAD scope flags security parameter for the BCB. 1017 The encryption key MAY be wrapped using the NIST AES-KW algorithm 1018 and the results of the wrapping added as the wrapped key security 1019 parameter for the BCB. 1021 The key length used by this security context MUST be considered 1022 when setting the AES variant security parameter for the BCB if it 1023 differs from the default AES variant. Otherwise, the AES variant 1024 MAY be omitted if doing so provides a useful reduction in message 1025 sizes. 1027 Problems encountered in the encryption MUST be processed in 1028 accordance with local security policy. This MAY include restoring a 1029 CRC value removed from the target block prior to encryption, if the 1030 target block is allowed to be transmitted after an encryption error. 1032 4.8.2. Decryption 1034 During encryption, five inputs are prepared for input to the AES/GCM 1035 cipher: the decryption key, the IV, the security target cipher text 1036 to be decrypted, any additional authenticated data, and the 1037 authentication tag generated from the original encryption. These 1038 data items MUST be generated as follows. 1040 The decryption key MUST be derived using the wrapped key security 1041 parameter if such a parameter is included in the security context 1042 parameters of the BCB. Otherwise this key MUST be derived in 1043 accordance with local security policy at the decrypting node as 1044 discussed in Section 4.5. 1046 The IV MUST be set to the value of the IV security parameter 1047 included in the BCB. If the IV parameter is not included as a 1048 security parameter, an IV MAY be derived as a function of local 1049 security policy and other BCB contents or a lack of an IV security 1050 parameter in the BCB MAY be treated as an error by the decrypting 1051 node. 1053 The security target cipher text for decryption MUST be generated 1054 as discussed in Section 4.7.1. 1056 Additional authenticated data, if present, MUST be generated as 1057 discussed in Section 4.7.2 with the value of AAD scope flags being 1058 taken from the AAD scope flags security context parameter. If the 1059 AAD scope flags parameter is not included in the security context 1060 parameters then these flags MAY be derived from local security 1061 policy in cases where the set of such flags is determinable in the 1062 network. 1064 The authentication tag MUST be present in the BCB security context 1065 parameters field if additional authenticated data are defined for 1066 the BCB (either in the AAD scope flags parameter or as specified 1067 by local policy). This tag MUST be 128 bits in length. 1069 Upon successful decryption the following actions MUST occur. 1071 The plain text produced by AES/GCM MUST replace the bytes used to 1072 define the cipher text in the security target block's block-type- 1073 specific data field. Any changes to the security target block 1074 length field MUST be corrected in cases where the plain text has a 1075 different length than the replaced cipher text. 1077 If the security acceptor is not the bundle destination and if no 1078 other integrity or confidentiality service is being applied to the 1079 target block, then a CRC MUST be included for the target block. The 1080 CRC type, as determined by policy, is set in the target block's CRC 1081 type field and the corresponding CRC value is added as the CRC field 1082 for that block. 1084 If the cipher text fails to authenticate, if any needed parameters 1085 are missing, or if there are other problems in the decryption then 1086 the decryption MUST be treated as failed and processed in accordance 1087 with local security policy. 1089 5. IANA Considerations 1091 5.1. Security Context Identifiers 1093 This specification allocates two security context identifiers from 1094 the "BPSec Security Context Identifier" registry defined in 1095 [I-D.ietf-dtn-bpsec]. 1097 Additional Entries for the BPSec Security Context Identifiers 1098 Registry: 1100 +-------+---------------+---------------+ 1101 | Value | Description | Reference | 1102 +-------+---------------+---------------+ 1103 | TBA | BIB-HMAC-SHA2 | This document | 1104 | TBA | BCB-AES-GCM | This document | 1105 +-------+---------------+---------------+ 1107 Table 7 1109 6. Security Considerations 1111 Security considerations specific to a single security context are 1112 provided in the description of that context. This section discusses 1113 security considerations that should be evaluated by implementers of 1114 any security context described in this document. Considerations may 1115 also be found in documents listed as normative references and they 1116 should also be reviewed by security context implementors. 1118 6.1. Key Management 1120 The delayed and disrupted nature of DTNs complicates the process of 1121 key management because there may not be reliable, timely round-trip 1122 exchange between security sources, security verifiers, and security 1123 acceptors in the network. This is true when there is a substantial 1124 signal propagation delay between nodes, when nodes are in a highly 1125 challenged communications environment, and when nodes do not support 1126 bi-directional communication. 1128 In these environments, key establishment protocols that rely on 1129 round-trip information exchange may not converge on a shared secret 1130 in a timely manner (or at all). Also, key revocation or key 1131 verification mechanisms that rely on access to a centralized 1132 authority (such as a certificate authority) may similarly fail in the 1133 stressing conditions of a DTN. 1135 For these reasons, the default security contexts described in this 1136 document rely on symmetric key cryptographic mechanisms because 1137 asymmetric key infrastructure (such as a public key infrastructure) 1138 is impractical in this environment. This extends to any asymmetric- 1139 key mechanism for key derivation, key exchange, or key revocation. 1141 BPSec assumes that "key management is handled as a separate part of 1142 network management" [I-D.ietf-dtn-bpsec]. This assumption is also 1143 made by the security contexts defined in this document which do not 1144 define new protocols for key derivation, exchange of key-encrypting 1145 keys, revocation of existing keys, or the security configuration or 1146 policy used to select certain keys for certain security operations. 1148 Nodes using these security contexts must be able to perform the 1149 following activities, independent of the construction, transmission, 1150 and processing of BPSec security blocks. 1152 Establish shared key-encrypting-keys with other nodes in the 1153 network using an out-of-band mechanism. This may include pre- 1154 sharing of key encryption keys or the use of traditional key 1155 establishment mechanisms prior to the exchange of BPsec security 1156 blocks. 1158 Determine when a key is considered exhausted and no longer to be 1159 used in the generation, verification, or acceptance of a security 1160 block. 1162 Determine when a key is considered invalid and no longer to be 1163 used in the generation, verification, or acceptance of a security 1164 block. Such revocations can be based on a variety of mechanisms 1165 to include local security policy, time relative to the generation 1166 or use of the key, or as specified through network management. 1168 Determine, through an out-of-band mechanism such as local security 1169 policy, what keys are to be used for what security blocks. This 1170 includes the selection of which key should be used in the 1171 evaluation of a security block received by a security verifier or 1172 a security acceptor. 1174 The failure to provide effective key management techniques 1175 appropriate for the operational networking environment can result in 1176 the compromise of those unmanaged keys and the loss of security 1177 services in the network. 1179 6.2. Key Handling 1181 Once generated, keys should be handled as follows. 1183 It is strongly RECOMMENDED that implementations protect keys both 1184 when they are stored and when they are transmitted. 1186 In the event that a key is compromised, any security operations 1187 using a security context associated with that key SHOULD also be 1188 considered compromised. This means that the BIB-HMAC-SHA2 1189 security context SHOULD NOT provide integrity when used with a 1190 compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality 1191 when used with a compromised key. 1193 The same key SHOULD NOT be used for different algorithms as doing 1194 so may leak information about the key. 1196 6.3. AES GCM 1198 There are a significant number of considerations related to the use 1199 of the GCM mode of AES to provide a confidentiality service. These 1200 considerations are provided in Section 4.6 as part of the 1201 documentation of the BCB-AES-GCM security context. 1203 6.4. Bundle Fragmentation 1205 Bundle fragmentation may prevent security services in a bundle from 1206 being verified after a bundle is fragmented and before the bundle is 1207 re-assembled. Examples of potential issues include the following. 1209 If a security block and its security target do not exist in the 1210 same fragment, then the security block cannot be processed until 1211 the bundle is re-assembled. If a fragment includes an encrypted 1212 target block, but not its BCB, then a receiving bundle processing 1213 agent (BPA) will not know that the target block has been 1214 encrypted. 1216 If a security block is cryptographically bound to a bundle, it 1217 cannot be processed even if the security block and target both 1218 coexist in the fragment. This is because fragments have different 1219 primary blocks than the original bundle. 1221 If security blocks and their target blocks are repeated in 1222 multiple fragments, policy must determine how to deal with issues 1223 where a security operation verifies in one fragment but fails in 1224 another fragment. This may happen, for example, if a BIB block 1225 becomes corrupted in one fragment but not in another fragment. 1227 Implementors should consider how security blocks are processed when a 1228 BPA fragments a received bundle. For example, security blocks and 1229 their targets could be placed in the same fragment if the security 1230 block is not otherwise cryptographically bound to the bundle being 1231 fragmented. Alternatively, if security blocks are cryptographically 1232 bound to a bundle, then a fragmenting BPA should consider 1233 encapsulating the bundle first and then fragmenting the encapsulating 1234 bundle. 1236 7. Normative References 1238 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 1239 Recommendation for Block Cipher Modes of Operation: 1240 Galois/Counter Mode (GCM) and GMAC.", November 2007. 1242 [AES-KW] Dworkin, M., "NIST Special Publication 800-38F: 1243 Recommendation for Block Cipher Modes of Operation: 1244 Methods for Key Wrapping.", December 2012. 1246 [HMAC] US NIST, "The Keyed-Hash Message Authentication Code 1247 (HMAC).", FIPS-198-1, Gaithersburg, MD, USA, July 2008. 1249 https://csrc.nist.gov/publications/detail/fips/198/1/final 1251 [I-D.ietf-dtn-bpbis] 1252 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1253 Version 7", draft-ietf-dtn-bpbis-31 (work in progress), 1254 January 2021. 1256 [I-D.ietf-dtn-bpsec] 1257 Birrane, E. and K. McKeever, "Bundle Protocol Security 1258 Specification", draft-ietf-dtn-bpsec-27 (work in 1259 progress), February 2021. 1261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1262 Requirement Levels", BCP 14, RFC 2119, 1263 DOI 10.17487/RFC2119, March 1997, 1264 . 1266 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1267 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1268 . 1270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1272 May 2017, . 1274 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1275 Representation (CBOR)", STD 94, RFC 8949, 1276 DOI 10.17487/RFC8949, December 2020, 1277 . 1279 [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- 1280 180-4, Gaithersburg, MD, USA, August 2015. 1282 https://csrc.nist.gov/publications/detail/fips/180/4/final 1284 Appendix A. Examples 1286 This appendix is informative. 1288 This section presents a series of examples of constructing BPSec 1289 security blocks (using the security contexts defined in this 1290 document) and adding those blocks to a sample bundle. 1292 The examples presented in this appendix represent valid constructions 1293 of bundles, security blocks, and the encoding of security context 1294 parameters and results. For this reason, they may inform unit test 1295 suites for individual implementations as well as interoperability 1296 test suites amongst implementations. However, these examples do not 1297 cover every permutation of security parameters, security results, or 1298 use of security blocks in a bundle. 1300 NOTE: Figures in this section identified as "(CBOR Diagnostic 1301 Notation)" are represented using the CBOR diagnostic notation defined 1302 in [RFC8949]. This notation is used to express CBOR data structures 1303 in a manner that enables visual inspection. The bundles, security 1304 blocks, and security context contents in these figures are 1305 represented using CBOR structures. 1307 NOTE: Examples in this section use the "ipn" URI scheme for 1308 EndpointID naming, as defined in [I-D.ietf-dtn-bpbis]. 1310 NOTE: The bundle source is presumed to be the security source for all 1311 security blocks in this section, unless otherwise noted. 1313 A.1. Example 1: Simple Integrity 1315 This example shows the addition of a BIB to a sample bundle to 1316 provide integrity for the payload block. 1318 A.1.1. Original Bundle 1320 The following diagram shows the original bundle before the BIB has 1321 been added. 1323 Block Block Block 1324 in Bundle Type Number 1325 +========================================+=======+========+ 1326 | Primary Block | N/A | 0 | 1327 +----------------------------------------+-------+--------+ 1328 | Payload Block | 0 | 1 | 1329 +----------------------------------------+-------+--------+ 1331 Figure 1: Example 1 Original Bundle 1333 A.1.1.1. Primary Block 1335 The BPv7 bundle has no special processing flags and no CRC is 1336 provided because the primary block is expected to be protected by an 1337 integrity service BIB using the BIB-HMAC-SHA2 security context. 1339 The bundle is sourced at the source node ipn:2.1 and destined for the 1340 destination node ipn:1.2. The bundle creation time uses a DTN 1341 creation time of 0 indicating lack of an accurate clock and a 1342 sequence number of 40. The lifetime of the bundle is given as 1343 1,000,000 milliseconds since the bundle creation time. 1345 The primary block is provided as follows. 1347 [ 1348 7, / BP version / 1349 0, / flags / 1350 0, / CRC type / 1351 [2, [1,2]], / destination (ipn:1.2) / 1352 [2, [2,1]], / source (ipn:2.1) / 1353 [2, [2,1]], / report-to (ipn:2.1) / 1354 [0, 40], / timestamp / 1355 1000000 / lifetime / 1356 ] 1358 Figure 2: Primary Block (CBOR Diagnostic Notation) 1360 The CBOR encoding of the primary block is 1361 0x88070000820282010282028202018202820201820018281a000f4240. 1363 A.1.1.2. Payload Block 1365 Other than its use as a source of plaintext for security blocks, the 1366 payload has no required distinguishing characteristic for the purpose 1367 of this example. The sample payload is a 32 byte string whose value 1368 is "Ready Generate a 32 byte payload". 1370 The payload is represented in the payload block as a byte string of 1371 the raw payload string. It is NOT represented as a CBOR text string 1372 wrapped within a CBOR binary string. The hex value of the payload 1373 "Ready Generate a 32 byte payload" is 1374 0x52656164792047656e657261746520612033322062797465207061796c6f6164. 1376 The payload block is provided as follows. 1378 [ 1379 1, / type code: Payload block / 1380 1, / block number / 1381 0, / block processing flags / 1382 0, / CRC Type / 1383 h'52656164792047656e65726174652061 / type-specific-data: payload / 1384 2033322062797465207061796c6f6164' 1386 ] 1388 Payload Block (CBOR Diagnostic Notation) 1390 The CBOR encoding of the payload block is 0x8501010000582052656164792 1391 047656e657261746520612033322062797465207061796c6f6164. 1393 A.1.1.3. Bundle CBOR Representation 1395 A BPv7 bundle is represented as an indefinite-length array consisting 1396 of the blocks comprising the bundle, with a terminator character at 1397 the end. 1399 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1400 28202018202820201820018281a000f42408501010000582052656164792047656e65 1401 7261746520612033322062797465207061796c6f6164ff. 1403 A.1.2. Security Operation Overview 1405 This example adds a BIB to the bundle using the BIB-HMAC-SHA2 1406 security context to provide an integrity mechanism over the payload 1407 block. 1409 The following diagram shows the resulting bundle after the BIB is 1410 added. 1412 Block Block Block 1413 in Bundle Type Number 1414 +========================================+=======+========+ 1415 | Primary Block | N/A | 0 | 1416 +----------------------------------------+-------+--------+ 1417 | Bundle Integrity Block | 11 | 2 | 1418 | OP(bib-integrity, target=1) | | | 1419 +----------------------------------------+-------+--------+ 1420 | Payload Block | 0 | 1 | 1421 +----------------------------------------+-------+--------+ 1423 Figure 3: Example 1 Resulting Bundle 1425 A.1.3. Bundle Integrity Block 1427 In this example, a BIB is used to carry an integrity signature over 1428 the payload block. 1430 A.1.3.1. Configuration, Parameters, and Results 1432 For this example, the following configuration and security parameters 1433 are used to generate the security results indicated. 1435 This BIB has a single target and includes a single security result: 1436 the calculated signature over the payload block. 1438 Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 1439 SHA Variant : HMAC 512/512 1440 Scope Flags : 0 1441 Payload Data: h'52656164792047656e65726174652061 1442 2033322062797465207061796c6f6164' 1443 Signature : h'd8e7c3be29effa8779e7dcb0d3cadf53 1444 39df50ebd27b9054f197c8ea9864b0a3 1445 35a0636213e5d4a9c95504f261d91a2f 1446 22757112c95e3587a76b4228361803e8' 1448 Figure 4: Example 1: Configuration, Parameters, and Results 1450 A.1.3.2. Abstract Security Block 1452 The abstract security block structure of the BIB's block-type- 1453 specific-data field for this application is as follows. 1455 [1], / Security Target / 1456 1, / Security Context ID - BIB-HMAC-SHA2 / 1457 1, / Security Context Flags - Parameters Present / 1458 [2,[2, 1]], / Security Source - ipn:2.1 / 1459 [ / Security Parameters - 2 Parameters / 1460 [1, 7], / SHA Variant - HMAC 512/512 / 1461 [3, 0] / Scope Flags - No Additional Scope / 1462 ], 1463 [ / Security Results: 1 Result / 1464 [1, h'd8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864 1465 b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228 1466 361803e8'] 1467 ] 1469 Figure 5: Example 1: BIB Abstract Security Block (CBOR Diagnostic 1470 Notation) 1472 The CBOR encoding of the BIB block-type-specific-data field (the 1473 abstract security block) is 0x810101018202820201828201078203008182015 1474 840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864b0a335 1475 a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228361803e8. 1477 A.1.3.3. Representations 1479 The BIB wrapping this abstract security block is as follows. 1481 [ 1482 11, / type code / 1483 2, / block number / 1484 0, / flags / 1485 0, / CRC type / 1486 h'810101018202820201828201078203008182015840d8e7c3be29effa8779e7dcb 1487 0d3cadf5339df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f2 1488 61d91a2f22757112c95e3587a76b4228361803e8', 1489 ] 1491 Figure 6: Example 1: BIB (CBOR Diagnostic Notation) 1493 The CBOR encoding of the BIB block is 0x850b0200005855810101018202820 1494 201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd2 1495 7b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e358 1496 7a76b4228361803e8. 1498 A.1.4. Final Bundle 1500 The CBOR encoding of the full output bundle, with the BIB: 0x9F880700 1501 00820282010282028202018202820201820018281a000f4240850b020000585581010 1502 1018202820201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf53 1503 39df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757 1504 112c95e3587a76b4228361803e8ff. 1506 A.2. Example 2: Simple Confidentiality with Key Wrap 1508 This example shows the addition of a BCB to a sample bundle to 1509 provide confidentiality for the payload block. AES key wrap is used 1510 to transmit the symmetric key used to generate the security results 1511 for this service. 1513 A.2.1. Original Bundle 1515 The following diagram shows the original bundle before the BCB has 1516 been added. 1518 Block Block Block 1519 in Bundle Type Number 1520 +========================================+=======+========+ 1521 | Primary Block | N/A | 0 | 1522 +----------------------------------------+-------+--------+ 1523 | Payload Block | 0 | 1 | 1524 +----------------------------------------+-------+--------+ 1526 Figure 7: Example 2 Original Bundle 1528 A.2.1.1. Primary Block 1530 The primary block used in this example is identical to the primary 1531 block presented in Example 1 Appendix A.1.1.1. 1533 In summary, the CBOR encoding of the primary block is 1534 0x88070000820282010282028202018202820201820018281a000f4240. 1536 A.2.1.2. Payload Block 1538 The payload block used in this example is identical to the payload 1539 block presented in Example 1 Appendix A.1.1.2. 1541 In summary, the CBOR encoding of the payload block is 0x8501010000582 1542 052656164792047656e657261746520612033322062797465207061796c6f6164. 1544 A.2.1.3. Bundle CBOR Representation 1546 A BPv7 bundle is represented as an indefinite-length array consisting 1547 of the blocks comprising the bundle, with a terminator character at 1548 the end. 1550 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1551 28202018202820201820018281a000f42408501010000582052656164792047656e65 1552 7261746520612033322062797465207061796c6f6164ff. 1554 A.2.2. Security Operation Overview 1556 This example adds a BCB using the BCB-AES-GCM security context using 1557 AES key wrap to provide a confidentiality mechanism over the payload 1558 block and transmit the symmetric key. 1560 The following diagram shows the resulting bundle after the BCB is 1561 added. 1563 Block Block Block 1564 in Bundle Type Number 1565 +========================================+=======+========+ 1566 | Primary Block | N/A | 0 | 1567 +----------------------------------------+-------+--------+ 1568 | Bundle Confidentiality Block | 12 | 2 | 1569 | OP(bcb-confidentiality, target=1) | | | 1570 +----------------------------------------+-------+--------+ 1571 | Payload Block (Encrypted) | 0 | 1 | 1572 +----------------------------------------+-------+--------+ 1574 Figure 8: Example 2 Resulting Bundle 1576 A.2.3. Bundle Confidentiality Block 1578 In this example, a BCB is used to encrypt the payload block and uses 1579 AES key wrap to transmit the symmetric key. 1581 A.2.3.1. Configuration, Parameters, and Results 1583 For this example, the following configuration and security parameters 1584 are used to generate the security results indicated. 1586 This BCB has a single target, the payload block. Three security 1587 results are generated: cipher text which replaces the plain text 1588 block-type-specific data to encrypt the payload block, an 1589 authentication tag, and the AES wrapped key. 1591 Content Encryption 1592 Key: h'71776572747975696f70617364666768' 1593 Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' 1594 IV: h'5477656c7665313231323132' 1595 AES Variant: A128GCM 1596 AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 1597 96fabf34d7fae700' 1598 Scope Flags: 0 1599 Payload Data: h'52656164792047656e65726174652061 1600 2033322062797465207061796c6f6164' 1601 Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb' 1602 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 1603 a563e32648b700c2784e26a990d91f9d' 1605 Figure 9: Example 2: Configuration, Parameters, and Results 1607 A.2.3.2. Abstract Security Block 1609 The abstract security block structure of the BCB's block-type- 1610 specific-data field for this application is as follows. 1612 [1], / Security Target / 1613 2, / Security Context ID - BCB-AES-GCM / 1614 1, / Security Context Flags - Parameters Present / 1615 [2,[2, 1]], / Security Source - ipn:2.1 / 1616 [ / Security Parameters - 4 Parameters / 1617 [1, h'5477656c7665313231323132'], / Initialization Vector / 1618 [2, 1], / AES Variant - A128GCM / 1619 [3, h'69c411276fecddc4780df42c8a / AES wrapped key / 1620 2af89296fabf34d7fae700'], 1621 [4, 0] / Scope Flags - No extra scope/ 1622 ], 1623 [ / Security Results: 1 Result / 1624 [1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag / 1625 ] 1627 Figure 10: Example 2: BCB Abstract Security Block (CBOR Diagnostic 1628 Notation) 1630 The CBOR encoding of the BCB block-type-specific-data field (the 1631 abstract security block) is 0x8101020182028202018482014c5477656c76653 1632 132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa 1633 e70082040081820150689b98e649ae3b554e98aa2ae8f801eb. 1635 A.2.3.3. Representations 1637 The BCB wrapping this abstract security block is as follows. 1639 [ 1640 12, / type code / 1641 2, / block number / 1642 1, / flags - block must be replicated in every fragment / 1643 0, / CRC type / 1644 h'8101020182028202018482014c5477656c766531323132313282020182035818 1645 69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008182015068 1646 9b98e649ae3b554e98aa2ae8f801eb' 1647 ] 1649 Figure 11: Example 2: BCB (CBOR Diagnostic Notation) 1651 The CBOR encoding of the BCB block is 0x850c020100584f810102018202820 1652 2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d 1653 f42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554e98aa2ae8f 1654 801eb. 1656 A.2.4. Final Bundle 1658 The CBOR encoding of the full output bundle, with the BCB: 0x9f880700 1659 00820282010282028202018202820201820018281a000f4240850c020100584f81010 1660 20182028202018482014c5477656c76653132313231328202018203581869c411276f 1661 ecddc4780df42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554 1662 e98aa2ae8f801eb850101000058203a09c1e63fe2097528a78b7c12943354a563e326 1663 48b700c2784e26a990d91f9dff. 1665 A.3. Example 3: Security Blocks from Multiple Sources 1667 This example shows the addition of a BIB and BCB to a sample bundle. 1668 These two security blocks are added by two different nodes. The BCB 1669 is added by the source endpoint and the BIB is added by a forwarding 1670 node. 1672 The resulting bundle contains a BCB to encrypt the Payload Block and 1673 a BIB to provide integrity to the Primary and Bundle Age Block. 1675 A.3.1. Original Bundle 1677 The following diagram shows the original bundle before the security 1678 blocks have been added. 1680 Block Block Block 1681 in Bundle Type Number 1682 +========================================+=======+========+ 1683 | Primary Block | N/A | 0 | 1684 +----------------------------------------+-------+--------+ 1685 | Extension Block: Bundle Age Block | 7 | 2 | 1686 +----------------------------------------+-------+--------+ 1687 | Payload Block | 0 | 1 | 1688 +----------------------------------------+-------+--------+ 1690 Figure 12: Example 3 Original Bundle 1692 A.3.1.1. Primary Block 1694 The primary block used in this example is identical to the primary 1695 block presented in Example 1 Appendix A.1.1.1. 1697 In summary, the CBOR encoding of the primary block is 1698 0x88070000820282010282028202018202820201820018281a000f4240. 1700 A.3.1.2. Bundle Age Block 1702 A bundle age block is added to the bundle to help other nodes in the 1703 network determine the age of the bundle. The use of this block is as 1704 recommended because the bundle source does not have an accurate clock 1705 (as indicated by the DTN time of 0). 1707 Because this block is specified at the time the bundle is being 1708 forwarded, the bundle age represents the time that has elapsed from 1709 the time the bundle was created to the time it is being prepared for 1710 forwarding. In this case, the value is given as 300 milliseconds. 1712 The bundle age extension block is provided as follows. 1714 [ 1715 7, / type code: Bundle Age block / 1716 2, / block number / 1717 0, / block processing flags / 1718 0, / CRC Type / 1719 <<300>> / type-specific-data: age / 1720 ] 1722 Figure 13: Bundle Age Block (CBOR Diagnostic Notation) 1724 The CBOR encoding of the bundle age block is 0x85070200004319012c. 1726 A.3.1.3. Payload Block 1728 The payload block used in this example is identical to the payload 1729 block presented in Example 1 Appendix A.1.1.2. 1731 In summary, the CBOR encoding of the payload block is 0x8501010000582 1732 052656164792047656e657261746520612033322062797465207061796c6f6164. 1734 A.3.1.4. Bundle CBOR Representation 1736 A BPv7 bundle is represented as an indefinite-length array consisting 1737 of the blocks comprising the bundle, with a terminator character at 1738 the end. 1740 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1741 28202018202820201820018281a000f424085070200004319012c8501010000582052 1742 656164792047656e657261746520612033322062797465207061796c6f6164ff. 1744 A.3.2. Security Operation Overview 1746 This example provides: 1748 a BIB with the BIB-HMAC-SHA2 security context to provide an 1749 integrity mechanism over the primary block and bundle age block. 1751 a BCB with the BCB-AES-GCM security context to provide a 1752 confidentiality mechanism over the payload block. 1754 The following diagram shows the resulting bundle after the security 1755 blocks are added. 1757 Block Block Block 1758 in Bundle Type Number 1759 +========================================+=======+========+ 1760 | Primary Block | N/A | 0 | 1761 +----------------------------------------+-------+--------+ 1762 | Bundle Integrity Block | 11 | 3 | 1763 | OP(bib-integrity, targets=0, 2) | | | 1764 +----------------------------------------+-------+--------+ 1765 | Bundle Confidentiality Block | 12 | 4 | 1766 | OP(bcb-confidentiality, target=1) | | | 1767 +----------------------------------------+-------+--------+ 1768 | Extension Block: Bundle Age Block | 7 | 2 | 1769 +----------------------------------------+-------+--------+ 1770 | Payload Block (Encrypted) | 0 | 1 | 1771 +----------------------------------------+-------+--------+ 1773 Figure 14: Example 3 Resulting Bundle 1775 A.3.3. Bundle Integrity Block 1777 In this example, a BIB is used to carry an integrity signature over 1778 the bundle age block and an additional signature over the payload 1779 block. The BIB is added by a waypoint node, ipn:3.0. 1781 A.3.3.1. Configuration, Parameters, and Results 1783 For this example, the following configuration and security parameters 1784 are used to generate the security results indicated. 1786 This BIB has two security targets and includes two security results, 1787 holding the calculated signatures over the bundle age block and 1788 primary block. 1790 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 1791 SHA Variant: HMAC 256/256 1792 Scope Flags: 0 1793 Primary Block Data: h'8807000082028201028202820201820282020182001 1794 8281a000f4240' 1795 Bundle Age Block 1796 Data: h'85070200004319012c' 1797 Primary Block 1798 Signature: h'2f74b42d88234f0a8a98a6c72775ec6511aff3cb5bf 1799 c06aa648f5fc40f31ec0d' 1800 Bundle Age Block 1801 Signature: h'e61385353ce2b4cce5319bc33326cdc26f4061e76cb 1802 21b434c89199a36b00de3' 1804 Figure 15: Example 3: Configuration, Parameters, and Results for the 1805 BIB 1807 A.3.3.2. Abstract Security Block 1809 The abstract security block structure of the BIB's block-type- 1810 specific-data field for this application is as follows. 1812 [0, 2], / Security Target / 1813 1, / Security Context ID - BIB-HMAC-SHA2 / 1814 1, / Security Context Flags - Parameters Present / 1815 [2,[3, 0]], / Security Source - ipn:3.0 / 1816 [ / Security Parameters - 2 Parameters / 1817 [1, 5], / SHA Variant - HMAC 256/256 / 1818 [3, 0] / Scope Flags - No Additional Scope / 1819 ], 1820 [ / Security Results: 2 Results / 1821 [1, h'2f74b42d88234f0a8a98a6c72775ec6511aff3 / Primary Block / 1822 cb5bfc06aa648f5fc40f31ec0d'], 1823 [1, h'e61385353ce2b4cce5319bc33326cdc26f4061 / Bundle Age Block / 1824 e76cb21b434c89199a36b00de3'] 1825 ] 1827 Figure 16: Example 3: BIB Abstract Security Block (CBOR Diagnostic 1828 Notation) 1830 The CBOR encoding of the BIB block-type-specific-data field (the 1831 abstract security block) is 0x820002010182028203008282010582030082820 1832 158202f74b42d88234f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d 1833 82015820e61385353ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00 1834 de3. 1836 A.3.3.3. Representations 1838 The BIB wrapping this abstract security block is as follows. 1840 [ 1841 11, / type code / 1842 3, / block number / 1843 0, / flags / 1844 0, / CRC type / 1845 h'820002010182028203008282010582030082820158202f74b42d88234f0a8a98 1846 a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353ce2 1847 b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3', 1848 ] 1850 Figure 17: Example 3: BIB (CBOR Diagnostic Notation) 1852 The CBOR encoding of the BIB block is 0x850b030000585a820002010182028 1853 203008282010582030082820158202f74b42d88234f0a8a98a6c72775ec6511aff3cb 1854 5bfc06aa648f5fc40f31ec0d82015820e61385353ce2b4cce5319bc33326cdc26f406 1855 1e76cb21b434c89199a36b00de3. 1857 A.3.4. Bundle Confidentiality Block 1859 In this example, a BCB is used encrypt the payload block. The BCB is 1860 added by the bundle source node, ipn:2.1. 1862 A.3.4.1. Configuration, Parameters, and Results 1864 For this example, the following configuration and security parameters 1865 are used to generate the security results indicated. 1867 This BCB has a single target, the payload block. Two security 1868 results are generated: cipher text which replaces the plain text 1869 block-type-specific data to encrypt the payload block, and an 1870 authentication tag. 1872 Content Encryption 1873 Key: h'71776572747975696f70617364666768' 1874 IV: h'5477656c7665313231323132' 1875 AES Variant: A128GCM 1876 Scope Flags: 0 1877 Payload Data: h'52656164792047656e65726174652061 1878 2033322062797465207061796c6f6164' 1879 Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb' 1880 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 1881 a563e32648b700c2784e26a990d91f9d' 1883 Figure 18: Example 3: Configuration, Parameters, and Results for the 1884 BCB 1886 A.3.4.2. Abstract Security Block 1888 The abstract security block structure of the BCB's block-type- 1889 specific-data field for this application is as follows. 1891 [1], / Security Target / 1892 2, / Security Context ID - BCB-AES-GCM / 1893 1, / Security Context Flags - Parameters Present / 1894 [2,[2, 1]], / Security Source - ipn:2.1 / 1895 [ / Security Parameters - 3 Parameters / 1896 [1, b'Twelve121212'] / Initialization Vector /, 1897 [2, 1] / AES Variant - AES 128 /, 1898 [4, 0] / Scope Flags - No Additional Scope / 1899 ], 1900 [ / Security Results: 1 Result / 1901 [1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag / 1902 ] 1904 Figure 19: Example 3: BCB Abstract Security Block (CBOR Diagnostic 1905 Notation) 1907 The CBOR encoding of the BCB block-type-specific-data field (the 1908 abstract security block) is 0x8101020182028202018382014c5477656C76653 1909 1323132313282020182040081820150689b98e649ae3b554e98aa2ae8f801eb. 1911 A.3.4.3. Representations 1913 The BCB wrapping this abstract security block is as follows. 1915 [ 1916 12, / type code / 1917 4, / block number / 1918 1, / flags - block must be replicated in every fragment / 1919 0, / CRC type / 1920 h'8101020182028202018382014c5477656C766531323132313282020182040081 1921 820150689b98e649ae3b554e98aa2ae8f801eb', 1922 ] 1924 Figure 20: Example 3: BCB (CBOR Diagnostic Notation) 1926 The CBOR encoding of the BCB block is 0x850c0401005833810102018202820 1927 2018382014c5477656C766531323132313282020182040081820150689b98e649ae3b 1928 554e98aa2ae8f801eb. 1930 A.3.5. Final Bundle 1932 The CBOR encoding of the full output bundle, with the BIB and BCB 1933 added is: 9F88070000820282010282028202018202820201820018281a000f42408 1934 50b030000585a820002010182028203008282010582030082820158202f74b42d8823 1935 4f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353 1936 ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3850c0401005833 1937 8101020182028202018382014c5477656C76653132313231328202018204008182015 1938 0689b98e649ae3b554e98aa2ae8f801eb85070200004319012c850101000058203a09 1939 c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dFF. 1941 A.4. Example 4: Security Blocks with Full Scope 1943 This example shows the addition of a BIB and BCB to a sample bundle. 1944 A BIB is added to provide integrity over the payload block and a BCB 1945 is added for confidentiality over the payload and BIB. 1947 The integrity scope and additional authentication data will bind the 1948 primary block, target header, and the security header. 1950 A.4.1. Original Bundle 1952 The following diagram shows the original bundle before the security 1953 blocks have been added. 1955 Block Block Block 1956 in Bundle Type Number 1957 +========================================+=======+========+ 1958 | Primary Block | N/A | 0 | 1959 +----------------------------------------+-------+--------+ 1960 | Payload Block | 0 | 1 | 1961 +----------------------------------------+-------+--------+ 1963 Figure 21: Example 4 Original Bundle 1965 A.4.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.4.1.2. Payload Block 1975 The payload block used in this example is identical to the payload 1976 block presented in Example 1 Appendix A.1.1.2. 1978 In summary, the CBOR encoding of the payload block is 0x8501010000582 1979 052656164792047656e657261746520612033322062797465207061796c6f6164. 1981 A.4.1.3. Bundle CBOR Representation 1983 A BPv7 bundle is represented as an indefinite-length array consisting 1984 of the blocks comprising the bundle, with a terminator character at 1985 the end. 1987 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1988 28202018202820201820018281a000f42408501010000582052656164792047656e65 1989 7261746520612033322062797465207061796c6f6164ff. 1991 A.4.2. Security Operation Overview 1993 This example provides: 1995 a BIB with the BIB-HMAC-SHA2 security context to provide an 1996 integrity mechanism over the payload block. 1998 a BCB with the BCB-AES-GCM security context to provide a 1999 confidentiality mechanism over the payload block and BIB. 2001 The following diagram shows the resulting bundle after the security 2002 blocks are added. 2004 Block Block Block 2005 in Bundle Type Number 2006 +========================================+=======+========+ 2007 | Primary Block | N/A | 0 | 2008 +----------------------------------------+-------+--------+ 2009 | Bundle Integrity Block (Encrypted) | 11 | 3 | 2010 | OP(bib-integrity, target=1) | | | 2011 +----------------------------------------+-------+--------+ 2012 | Bundle Confidentiality Block | 12 | 4 | 2013 | OP(bcb-confidentiality, targets=1, 3) | | | 2014 +----------------------------------------+-------+--------+ 2015 | Payload Block (Encrypted) | 0 | 1 | 2016 +----------------------------------------+-------+--------+ 2018 Figure 22: Example 4 Resulting Bundle 2020 A.4.3. Bundle Integrity Block 2022 In this example, a BIB is used to carry an integrity signature over 2023 the payload block. The IPPT contains the payload block block-type- 2024 specific data, primary block data, the payload block header, and the 2025 BIB header. That is, all additional headers are included in the 2026 IPPT. 2028 A.4.3.1. Configuration, Parameters, and Results 2030 For this example, the following configuration and security parameters 2031 are used to generate the security results indicated. 2033 This BIB has a single target and includes a single security result: 2034 the calculated signature over the Payload block. 2036 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2037 SHA Variant: HMAC 384/384 2038 Scope Flags: 7 (all additional headers) 2039 Primary Block Data: h'88070000820282010282028202018202 2040 820201820018281a000f4240 2041 Payload Data: h'52656164792047656e65726174652061 2042 2033322062797465207061796c6f6164' 2043 Payload Header: h'85010100005820' 2044 BIB Header: h'850b0300005845' 2045 Payload Signature: h'6f56e0f58ec584df34603c75cc055939 2046 00b1a938f23883f119772e1230441d86 2047 9bce6ac9559f721260314424ab14b981 2049 Figure 23: Example 4: Configuration, Parameters, and Results for the 2050 BIB 2052 A.4.3.2. Abstract Security Block 2054 The abstract security block structure of the BIB's block-type- 2055 specific-data field for this application is as follows. 2057 [1], / Security Target / 2058 1, / Security Context ID - BIB-HMAC-SHA2 / 2059 1, / Security Context Flags - Parameters Present / 2060 [2,[2, 1]], / Security Source: ipn:2.1 / 2061 [ / Security Parameters: 2 Parameters / 2062 [1, 6], / SHA Variant - HMAC 384/384 / 2063 [3, 7] / Scope Flags - All additional headers in the SHA Hash / 2064 ], 2065 [ / Security Results: 1 Result / 2066 [1, h'6f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e123044 2067 1d869bce6ac9559f721260314424ab14b981'] 2068 ] 2070 Figure 24: Example 4: BIB Abstract Security Block (CBOR Diagnostic 2071 Notation) 2073 The CBOR encoding of the BIB block-type-specific-data field (the 2074 abstract security block) is 0x810101018202820201828201068203078182015 2075 8306f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e1230441d869b 2076 ce6ac9559f721260314424ab14b981. 2078 A.4.3.3. Representations 2080 The BIB wrapping this abstract security block is as follows. 2082 [ 2083 11, / type code / 2084 3, / block number / 2085 0, / flags / 2086 0, / CRC type / 2087 h'8101010182028202018282010682030781820158306f56e0f58ec584df34603c 2088 75cc05593900b1a938f23883f119772e1230441d869bce6ac9559f7212603144 2089 24ab14b981', 2090 ] 2092 Figure 25: Example 4: BIB (CBOR Diagnostic Notation) 2094 The CBOR encoding of the BIB block is 0x850b0300005845810101018202820 2095 2018282010682030781820158306f56e0f58ec584df34603c75cc05593900b1a938f2 2096 3883f119772e1230441d869bce6ac9559f721260314424ab14b981. 2098 A.4.4. Bundle Confidentiality Block 2100 In this example, a BCB is used encrypt the payload block and the BIB 2101 that provides integrity over the payload. 2103 A.4.4.1. Configuration, Parameters, and Results 2105 For this example, the following configuration and security parameters 2106 are used to generate the security results indicated. 2108 This BCB has two targets: the payload block and BIB. Four security 2109 results are generated: cipher text which replaces the plain text 2110 block-type-specific data of the payload block, cipher text to encrypt 2111 the BIB, and authentication tags for both the payload block and BIB. 2113 Key: h'71776572747975696f70617364666768 2114 71776572747975696f70617364666768' 2115 IV: h'5477656c7665313231323132' 2116 AES Variant: A256GCM 2117 Scope Flags: 7 (All additional headers) 2118 Payload Data: h'52656164792047656e65726174652061 2119 2033322062797465207061796c6f6164' 2120 BIB Data: h'52656164792047656E65726174652061 2121 2033322062797465207061796C6F6164' 2122 BIB 2123 Authentication Tag: h'92bc2665e9f04350c5974f023929dd62' 2124 Payload Block 2125 Authentication Tag: h'865bc14b3910d6c53e95fdc65aa601fd' 2126 Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 2127 319bb227706000abc8fcac3b9bb9c87e' 2128 BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 2129 902a815f2276222e1d0208c628e2c926 2130 2a0c438fc300190dbf5954ae4f84f748 2131 64e58ed1e39043633142ad2559e0e3a9 2132 c9cbce5c2d' 2134 Figure 26: Example 4: Configuration, Parameters, and Results for the 2135 BCB 2137 A.4.4.2. Abstract Security Block 2139 The abstract security block structure of the BCB's block-type- 2140 specific-data field for this application is as follows. 2142 [3, 1], / Security Target / 2143 2, / Security Context ID - BCB-AES-GCM / 2144 1, / Security Context Flags - Parameters Present / 2145 [2,[2, 1]], / Security Source - ipn:2.1 / 2146 [ / Security Parameters - 3 Parameters / 2147 [1, h'5477656c7665313231323132'] / Initialization Vector /, 2148 [2, 3] / AES Variant - AES 256 /, 2149 [4, 7] / Scope Flags - All headers in SHA hash / 2150 ], 2151 [ / Security Results: 2 Results / 2152 [1, h'865bc14b3910d6c53e95fdc65aa601fd'], / Payload Auth. Tag / 2153 [1, h'92bc2665e9f04350c5974f023929dd62'] / BIB Auth. Tag / 2154 ] 2156 Figure 27: Example 4: BCB Abstract Security Block (CBOR Diagnostic 2157 Notation) 2159 The CBOR encoding of the BCB block-type-specific-data field (the 2160 abstract security block) is 0x820301020182028202018382014c5477656C766 2161 531323132313282020382040782820150d0b506cc2e5ede57b36e6c52791457008201 2162 50865bc14b3910d6c53e95fdc65aa601fd. 2164 A.4.4.3. Representations 2166 The BCB wrapping this abstract security block is as follows. 2168 [ 2169 12, / type code / 2170 2, / block number / 2171 1, / flags - block must be replicated in every fragment / 2172 0, / CRC type / 2173 h'820301020182028202018382014c5477656C7665313231323132820203820407 2174 82820150d0b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e 2175 95fdc65aa601fd', 2176 ] 2178 Figure 28: Example 4: BCB (CBOR Diagnostic Notation) 2180 The CBOR encoding of the BCB block is 0x850c0201005847820301020182028 2181 202018382014c5477656C766531323132313282020382040782820150d0b506cc2e5e 2182 de57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd. 2184 A.4.5. Final Bundle 2186 The CBOR encoding of the full output bundle, with the security blocks 2187 added and payload block and BIB encrypted is: 9F880700008202820102820 2188 28202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb94d 2189 952175167df0902a815f2276222e1d0208c628e2c9262a0c438fc300190dbf5954ae4 2190 f84f74864e58ed1e39043633142ad2559e0e3a9c9cbce5c2d 850c020100584782030 2191 1020182028202018382014c5477656C766531323132313282020382040782820150d0 2192 b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd8 2193 501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac3b 2194 9bb9c87eFF. 2196 Appendix B. Acknowledgements 2198 The following participants contributed useful review and analysis of 2199 these security contexts: Amy Alford of the Johns Hopkins University 2200 Applied Physics Laboratory. 2202 Authors' Addresses 2203 Edward J. Birrane, III 2204 The Johns Hopkins University Applied 2205 Physics Laboratory 2206 11100 Johns Hopkins Rd. 2207 Laurel, MD 20723 2208 US 2210 Phone: +1 443 778 7423 2211 Email: Edward.Birrane@jhuapl.edu 2213 Alex White 2214 The Johns Hopkins University Applied 2215 Physics Laboratory 2216 11100 Johns Hopkins Rd. 2217 Laurel, MD 20723 2218 US 2220 Phone: +1 443 778 0845 2221 Email: Alex.White@jhuapl.edu 2223 Sarah Heiner 2224 The Johns Hopkins University Applied 2225 Physics Laboratory 2226 11100 Johns Hopkins Rd. 2227 Laurel, MD 20723 2228 US 2230 Phone: +1 240 592 3704 2231 Email: Sarah.Heiner@jhuapl.edu