idnits 2.17.1 draft-ietf-dtn-bpsec-default-sc-08.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 (June 8, 2021) is 1051 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 2012 -- Looks like a reference, but probably isn't: '40' on line 1468 -- Looks like a reference, but probably isn't: '1' on line 2256 -- Looks like a reference, but probably isn't: '7' on line 2263 -- Looks like a reference, but probably isn't: '3' on line 2262 -- Looks like a reference, but probably isn't: '2' on line 2262 -- Looks like a reference, but probably isn't: '4' on line 2263 -- Looks like a reference, but probably isn't: '5' on line 1931 -- Looks like a reference, but probably isn't: '6' on line 2176 -- 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: December 10, 2021 JHU/APL 6 June 8, 2021 8 BPSec Default Security Contexts 9 draft-ietf-dtn-bpsec-default-sc-08 11 Abstract 13 This document defines default integrity and confidentiality security 14 contexts that can be used with the Bundle Protocol Security Protocol 15 (BPSec) implementations. These security contexts are intended to be 16 used for both testing the interoperability of BPSec implementations 17 and for providing basic security operations when no other security 18 contexts are defined or otherwise required for a network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 10, 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 15 75 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 15 76 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 16 77 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 16 78 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 17 79 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 18 81 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 18 82 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 18 83 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 19 84 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 20 85 4.7.1. Cipher text related calculations . . . . . . . . . . 20 86 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 21 87 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 21 89 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 23 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 5.1. Security Context Identifiers . . . . . . . . . . . . . . 24 92 5.2. Integrity Scope Flags . . . . . . . . . . . . . . . . . . 25 93 5.3. AAD Scope Flags . . . . . . . . . . . . . . . . . . . . . 25 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 26 96 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 27 97 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28 99 6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 29 100 7. Normative References . . . . . . . . . . . . . . . . . . . . 29 101 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 30 102 A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 31 103 A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 31 104 A.1.2. Security Operation Overview . . . . . . . . . . . . . 33 105 A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 34 106 A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 35 107 A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 35 108 A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 35 109 A.2.2. Security Operation Overview . . . . . . . . . . . . . 36 110 A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 37 111 A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 39 112 A.3. Example 3: Security Blocks from Multiple Sources . . . . 39 113 A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 39 114 A.3.2. Security Operation Overview . . . . . . . . . . . . . 41 115 A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 41 116 A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 43 117 A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 45 118 A.4. Example 4: Security Blocks with Full Scope . . . . . . . 45 119 A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 45 120 A.4.2. Security Operation Overview . . . . . . . . . . . . . 46 121 A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 47 122 A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 49 123 A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 50 124 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 51 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 127 1. Introduction 129 The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] 130 specification provides inter-bundle integrity and confidentiality 131 operations for networks deploying the Bundle Protocol (BP) 132 [I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry 133 security information produced under the auspices of some security 134 context. 136 This document defines two security contexts (one for an integrity 137 service and one for a confidentiality service) for populating BPSec 138 Block Integrity Blocks (BIBs) and Block Confidentiality Blocks 139 (BCBs). 141 These contexts generate information that MUST be encoded using the 142 CBOR specification documented in [RFC8949]. 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 3. Integrity Security Context BIB-HMAC-SHA2 154 3.1. Overview 156 The BIB-HMAC-SHA2 security context provides a keyed hash over a set 157 of plain text information. This context uses the Secure Hash 158 Algorithm 2 (SHA-2) discussed in [SHS] combined with the HMAC keyed 159 hash discussed in [HMAC]. The combination of HMAC and SHA-2 as the 160 integrity mechanism for this security context was selected for two 161 reasons: 163 1. The use of symmetric keys allows this security context to be used 164 in places where an asymmetric-key infrastructure (such as a 165 public key infrastructure) might be impractical. 167 2. The combination HMAC-SHA2 represents a well-supported and well- 168 understood integrity mechanism with multiple implementations 169 available. 171 BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the 172 supported length of the SHA-2 hash value. These variants correspond 173 to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in 174 [RFC8152] Table 7: HMAC Algorithm Values. The selection of which 175 variant is used by this context is provided as a security context 176 parameter. 178 The output of the HMAC MUST be equal to the size of the SHA2 hashing 179 function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits 180 for SHA-512. 182 The BIB-HMAC-SHA2 security context MUST have the security context 183 identifier specified in Section 5.1. 185 3.2. Scope 187 The scope of BIB-HMAC-SHA2 is the set of information used to produce 188 the plain text over which a keyed hash is calculated. This plain 189 text is termed the "Integrity Protected Plain Text" (IPPT). The 190 content of the IPPT is constructed as the concatenation of 191 information whose integrity is being preserved from the BIB-HMAC-SHA2 192 security source to its security acceptor. There are four types of 193 information that can be used in the generation of the IPPT, based on 194 how broadly the concept of integrity is being applied. These four 195 types of information, whether they are required, and why they are 196 important for integrity, are discussed as follows. 198 Security target contents 199 The contents of the block-type-specific data field of the 200 security target MUST be included in the IPPT. Including this 201 information protects the security target data and is considered 202 the minimal, required set of information for an integrity service 203 on the security target. 205 Primary block 206 The primary block identifies a bundle and, once created, the 207 contents of this block are immutable. Changes to the primary 208 block associated with the security target indicate that the 209 security target (and BIB) might no longer be in the correct 210 bundle. 212 For example, if a security target and associated BIB are copied 213 from one bundle to another bundle, the BIB might still contain a 214 verifiable signature for the security target unless information 215 associated with the bundle primary block is included in the keyed 216 hash carried by the BIB. 218 Including this information in the IPPT protects the integrity of 219 the association of the security target with a specific bundle. 221 Security target other fields 222 The other fields of the security target include block 223 identification and processing information. Changing this 224 information changes how the security target is treated by nodes 225 in the network even when the "user data" of the security target 226 are otherwise unchanged. 228 For example, if the block processing control flags of a security 229 target are different at a security verifier than they were 230 originally set at the security source then the policy for 231 handling the security target has been modified. 233 Including this information in the IPPT protects the integrity of 234 the policy and identification of the security target data. 236 BIB other fields 237 The other fields of the BIB include block identification and 238 processing information. Changing this information changes how 239 the BIB is treated by nodes in the network, even when other 240 aspects of the BIB are unchanged. 242 For example, if the block processing control flags of the BIB are 243 different at a security verifier than they were originally set at 244 the security source, then the policy for handling the BIB has 245 been modified. 247 Including this information in the IPPT protects the integrity of 248 the policy and identification of the security service in the 249 bundle. 251 NOTE: The security context identifier and security context 252 parameters of the security block are not included in the IPPT 253 because these parameters, by definition, are required to verify 254 or accept the security service. Successful verification at 255 security verifiers and security acceptors implies that these 256 parameters were unchanged since being specified at the security 257 source. 259 The scope of the BIB-HMAC-SHA2 security context is configured using 260 an optional security context parameter. 262 3.3. Parameters 264 BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, 265 communicate key information, and define the scope of the IPPT. 267 3.3.1. SHA Variant 269 This optional parameter identifies which variant of the SHA-2 270 algorithm is to be used in the generation of the authentication code. 272 This value MUST be encoded as a CBOR unsigned integer. 274 Valid values for this parameter are as follows. 276 SHA Variant Parameter Values 278 +-------+-----------------------------------------------------------+ 279 | Value | Description | 280 +-------+-----------------------------------------------------------+ 281 | 5 | HMAC 256/256 as defined in [RFC8152] Table 7: HMAC | 282 | | Algorithm Values | 283 | 6 | HMAC 384/384 as defined in [RFC8152] Table 7: HMAC | 284 | | Algorithm Values | 285 | 7 | HMAC 512/512 as defined in [RFC8152] Table 7: HMAC | 286 | | Algorithm Values | 287 +-------+-----------------------------------------------------------+ 289 Table 1 291 When not provided, implementations SHOULD assume a value of 6 292 (indicating use of HMAC 384/384), unless an alternate default is 293 established by local security policy at the security source, 294 verifiers, or acceptor of this integrity service. 296 3.3.2. Wrapped Key 298 This optional parameter contains the output of the AES key wrap 299 authenticated encryption function (KW-AE) as defined in [AES-KW]. 300 Specifically, this parameter holds the cipher text produced when 301 running the KW-AE algorithm with the input string being the symmetric 302 HMAC key used to generate the security results present in the 303 security block. The value of this parameter is used as input to the 304 AES key wrap authenticated decryption function (KW-AD) at security 305 verifiers and security acceptors to determine the symmetric HMAC key 306 needed for the proper validation of the security results in the 307 security block. 309 This value MUST be encoded as a CBOR byte string. 311 If this parameter is not present then security verifiers and 312 acceptors MUST determine the proper key as a function of their local 313 BPSec policy and configuration. 315 3.3.3. Integrity Scope Flags 317 This optional parameter contains a series of flags that describe what 318 information is to be included with the block-type-specific data when 319 constructing the IPPT value. 321 This value MUST be represented as a CBOR unsigned integer, the value 322 of which MUST be processed as a bit field. 324 Integrity scope flags that are unrecognized MUST be ignored, as 325 future definitions of additional flags might not be integrated 326 simultaneously into security context implementations operating at all 327 nodes. 329 Bits in this field represent additional information to be included 330 when generating an integrity signature over the security target. 331 These bits are defined as follows. 333 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 335 - Bit 1 (0x0002): Target Header Flag. 337 - Bit 2 (0x0003): Security Header Flag. 339 - Bits 3-7 are reserved. 341 - Bits 8-15 are unassigned. 343 3.3.4. Enumerations 345 BIB-HMAC-SHA2 defines the following security context parameters. 347 BIB-HMAC-SHA2 Security Parameters 349 +----+-----------------------+--------------------+---------------+ 350 | Id | Name | CBOR Encoding Type | Default Value | 351 +----+-----------------------+--------------------+---------------+ 352 | 1 | SHA Variant | UINT | 6 | 353 | 2 | Wrapped Key | Byte String | NONE | 354 | 4 | Integrity Scope Flags | UINT | 0x7 | 355 +----+-----------------------+--------------------+---------------+ 357 Table 2 359 3.4. Results 361 BIB-HMAC-SHA2 defines the following security results. 363 BIB-HMAC-SHA2 Security Results 365 +--------+----------+-------------+---------------------------------+ 366 | Result | Result | CBOR | Description | 367 | Id | Name | Encoding | | 368 | | | Type | | 369 +--------+----------+-------------+---------------------------------+ 370 | 1 | Expected | byte string | The output of the HMAC | 371 | | HMAC | | calculation at the security | 372 | | | | source. | 373 +--------+----------+-------------+---------------------------------+ 375 Table 3 377 3.5. Key Considerations 379 HMAC keys used with this context MUST be symmetric and MUST have a 380 key length equal to the output of the HMAC. For this reason, HMAC 381 keys will be integer divisible by 8 bytes and special padding-aware 382 AES key wrap algorithms are not needed. 384 It is assumed that any security verifier or security acceptor 385 performing an integrity verification can determine the proper HMAC 386 key to be used. Potential sources of the HMAC key include (but are 387 not limited to) the following: 389 Pre-placed keys selected based on local policy. 391 Keys extracted from material carried in the BIB. 393 Session keys negotiated via a mechanism external to the BIB. 395 When an AES-KW wrapped key is present in a security block, it is 396 assumed that security verifiers and security acceptors can 397 independently determine the key encryption key (KEK) used in the 398 wrapping of the symmetric HMAC key. 400 As discussed in Section 6 and emphasized here, it is strongly 401 recommended that keys be protected once generated, both when they are 402 stored and when they are transmitted. 404 3.6. Canonicalization Algorithms 406 This section defines the canonicalization algorithm used to prepare 407 the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The 408 construction of the IPPT depends on the settings of the integrity 409 scope flags that can be provided as part of customizing the behavior 410 of this security context. 412 In all cases, the canonical form of any portion of an extension block 413 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 414 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 415 the canonical forms for extension blocks defined in 416 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 417 are represented in CBOR. 419 The IPPT is constructed using the following process. 421 1. The canonical form of the IPPT starts as the empty set with 422 length 0. 424 2. If the integrity scope parameter is present and the primary block 425 flag is set to 1, then a canonical form of the bundle's primary 426 block MUST be calculated and the result appended to the IPPT. 428 3. If the integrity scope parameter is present and the target header 429 flag is set to 1, then the canonical form of the block type code, 430 block number, and block processing control flags associated with 431 the security target MUST be calculated and, in that order, 432 appended to the IPPT. 434 4. If the integrity scope parameter is present and the security 435 header flag is set to 1, then the canonical form of the block 436 type code, block number, and block processing control flags 437 associated with the BIB MUST be calculated and, in that order, 438 appended to the IPPT. 440 5. The canonical form of the security target block-type-specific 441 data MUST be calculated and appended to the IPPT. 443 3.7. Processing 445 3.7.1. Keyed Hash Generation 447 During keyed hash generation, two inputs are prepared for the the 448 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 449 data items MUST be generated as follows. 451 The HMAC key MUST have the appropriate length as required by local 452 security policy. The key can be generated specifically for this 453 integrity service, given as part of local security policy, or 454 through some other key management mechanism as discussed in 455 Section 3.5. 457 Prior to the generation of the IPPT, if a CRC value is present for 458 the target block of the BIB, then that CRC value MUST be removed 459 from the target block. This involves both removing the CRC value 460 from the target block and setting the CRC Type field of the target 461 block to "no CRC is present." 463 Once CRC information is removed, the IPPT MUST be generated as 464 discussed in Section 3.6. 466 Upon successful hash generation the following actions MUST occur. 468 The keyed hash produced by the HMAC/SHA2 variant MUST be added as 469 a security result for the BIB representing the security operation 470 on this security target, as discussed in Section 3.4). 472 Finally, the BIB containing information about this security operation 473 MUST be updated as follows. These operations can occur in any order. 475 The security context identifier for the BIB MUST be set to the 476 context identifier for BIB-HMAC-SHA2. 478 Any local flags used to generate the IPPT SHOULD be placed in the 479 integrity scope flags security parameter for the BIB unless these 480 flags are expected to be correctly configured at security 481 verifiers and acceptors in the network. 483 The HMAC key MAY be wrapped using the NIST AES-KW algorithm and 484 the results of the wrapping added as the wrapped key security 485 parameter for the BIB. 487 The SHA variant used by this security context SHOULD be added as 488 the SHA variant security parameter for the BIB if it differs from 489 the default key length. Otherwise, this parameter MAY be omitted 490 if doing so provides a useful reduction in message sizes. 492 Problems encountered in the keyed hash generation MUST be processed 493 in accordance with local BPSec security policy. 495 3.7.2. Keyed Hash Verification 497 During keyed hash verification, the input of the security target and 498 a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. 500 During keyed hash verification, two inputs are prepared for the 501 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 502 data items MUST be generated as follows. 504 The HMAC key MUST be derived using the wrapped key security 505 parameter if such a parameter is included in the security context 506 parameters of the BIB. Otherwise, this key MUST be derived in 507 accordance with security policy at the verifying node as discussed 508 in Section 3.5. 510 The IPPT MUST be generated as discussed in Section 3.6 with the 511 value of integrity scope flags being taken from the integrity 512 scope flags security context parameter. If the integrity scope 513 flags parameter is not included in the security context parameters 514 then these flags MAY be derived from local security policy. 516 The calculated HMAC output MUST be compared to the expected HMAC 517 output encoded in the security results of the BIB for the security 518 target. If the calculated HMAC and expected HMAC are identical, the 519 verification MUST be considered a success. Otherwise, the 520 verification MUST be considered a failure. 522 If the verification fails or otherwise experiences an error, or if 523 any needed parameters are missing, then the verification MUST be 524 treated as failed and processed in accordance with local security 525 policy. 527 This security service is removed from the bundle at the security 528 acceptor as required by the BPSec specification. If the security 529 acceptor is not the bundle destination and if no other integrity 530 service is being applied to the target block, then a CRC MUST be 531 included for the target block. The CRC type, as determined by 532 policy, is set in the target block's CRC type field and the 533 corresponding CRC value is added as the CRC field for that block. 535 4. Security Context BCB-AES-GCM 537 4.1. Overview 539 The BCB-AES-GCM security context replaces the block-type-specific 540 data field of its security target with cipher text generated using 541 the Advanced Encryption Standard (AES) cipher operating in Galois/ 542 Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the 543 cipher suite for this confidentiality mechanism for several reasons: 545 1. The selection of a symmetric-key cipher suite allows for 546 relatively smaller keys than asymmetric-key cipher suites. 548 2. The selection of a symmetric-key cipher suite allows this 549 security context to be used in places where an asymmetric-key 550 infrastructure (such as a public key infrastructure) might be 551 impractical. 553 3. The use of the Galois/Counter Mode produces cipher-text with the 554 same size as the plain text making the replacement of target 555 block information easier as length fields do not need to be 556 changed. 558 4. The AES-GCM cipher suite provides authenticated encryption, as 559 required by the BPSec protocol. 561 Additionally, the BCB-AES-GCM security context generates an 562 authentication tag based on the plain text value of the block-type- 563 specific data and other additional authenticated data that might be 564 specified via parameters to this security context. 566 This security context supports two variants of AES-GCM, based on the 567 supported length of the symmetric key. These variants correspond to 568 A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value 569 for AES-GCM. 571 The BCB-AES-GCM security context MUST have the security context 572 identifier specified in Section 5.1. 574 4.2. Scope 576 There are two scopes associated with BCB-AES-GCM: the scope of the 577 confidentiality service and the scope of the authentication service. 578 The first defines the set of information provided to the AES-GCM 579 cipher for the purpose of producing cipher text. The second defines 580 the set of information used to generate an authentication tag. 582 The scope of the confidentiality service defines the set of 583 information provided to the AES-GCM cipher for the purpose of 584 producing cipher text. This MUST be the full set of plain text 585 contained in the block-type-specific data field of the security 586 target. 588 The scope of the authentication service defines the set of 589 information used to generate an authentication tag carried with the 590 security block. This information includes the data included in the 591 confidentiality service and MAY include other information (additional 592 authenticated data), as follows. 594 Primary block 595 The primary block identifies a bundle and, once created, the 596 contents of this block are immutable. Changes to the primary 597 block associated with the security target indicate that the 598 security target (and BCB) might no longer be in the correct 599 bundle. 601 For example, if a security target and associated BCB are copied 602 from one bundle to another bundle, the BCB might still be able to 603 decrypt the security target even though these blocks were never 604 intended to exist in the copied-to bundle. 606 Including this information as part of additional authenticated 607 data ensures that security target (and security block) appear in 608 the same bundle at the time of decryption as at the time of 609 encryption. 611 Security target other fields 612 The other fields of the security target include block 613 identification and processing information. Changing this 614 information changes how the security target is treated by nodes 615 in the network even when the "user data" of the security target 616 are otherwise unchanged. 618 For example, if the block processing control flags of a security 619 target are different at a security verifier than they were 620 originally set at the security source then the policy for 621 handling the security target has been modified. 623 Including this information as part of additional authenticated 624 data ensures that the cipher text in the security target will not 625 be used with a different set of block policy than originally set 626 at the time of encryption. 628 BCB other fields 629 The other fields of the BCB include block identification and 630 processing information. Changing this information changes how 631 the BCB is treated by nodes in the network, even when other 632 aspects of the BCB are unchanged. 634 For example, if the block processing control flags of the BCB are 635 different at a security acceptor than they were originally set at 636 the security source then the policy for handling the BCB has been 637 modified. 639 Including this information as part of additional authenticated 640 data ensures that the policy and identification of the security 641 service in the bundle has not changed. 643 NOTE: The security context identifier and security context 644 parameters of the security block are not included as additional 645 authenticated data because these parameters, by definition, are 646 those needed to verify or accept the security service. 647 Therefore, it is expected that changes to these values would 648 result in failures at security verifiers and security acceptors. 650 The scope of the BCB-AES-GCM security context is configured using an 651 optional security context parameter. 653 4.3. Parameters 655 BCB-AES-GCM can be parameterized to specify the AES variant, 656 initialization vector, key information, and identify additional 657 authenticated data. 659 4.3.1. Initialization Vector (IV) 661 This optional parameter identifies the initialization vector (IV) 662 used to initialize the AES-GCM cipher. 664 The length of the initialization vector, prior to any CBOR encoding, 665 MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used 666 unless local security policy requires a different length. 668 This value MUST be encoded as a CBOR byte string. 670 The initialization vector can have any value with the caveat that a 671 value MUST NOT be re-used for multiple encryptions using the same 672 encryption key. This value MAY be re-used when encrypting with 673 different keys. For example, if each encryption operation using BCB- 674 AES-GCM uses a newly generated key, then the same IV can be reused. 676 4.3.2. AES Variant 678 This optional parameter identifies the AES variant being used for the 679 AES-GCM encryption, where the variant is identified by the length of 680 key used. 682 This value MUST be encoded as a CBOR unsigned integer. 684 Valid values for this parameter are as follows. 686 AES Variant Parameter Values 688 +-------+-----------------------------------------------------------+ 689 | Value | Description | 690 +-------+-----------------------------------------------------------+ 691 | 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values | 692 | | for AES-GCM | 693 | 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values | 694 | | for AES-GCM | 695 +-------+-----------------------------------------------------------+ 696 When not provided, implementations SHOULD assume a value of 3 697 (indicating use of A256GCM), unless an alternate default is 698 established by local security policy at the security source, 699 verifier, or acceptor of this integrity service. 701 Regardless of the variant, the generated authentication tag MUST 702 always be 128 bits. 704 4.3.3. Wrapped Key 706 This optional parameter contains the output of the AES key wrap 707 authenticated encryption function (KW-AE) as defined in [AES-KW]. 708 Specifically, this parameter holds the cipher text produced when 709 running the KW-AE algorithm with the input string being the symmetric 710 AES key used to generate the security results present in the security 711 block. The value of this parameter is used as input to the AES key 712 wrap authenticated decryption function (KW-AD) at security verifiers 713 and security acceptors to determine the symmetric AES key needed for 714 the proper decryption of the security results in the security block. 716 This value MUST be encoded as a CBOR byte string. 718 If this parameter is not present then security verifiers and 719 acceptors MUST determine the proper key as a function of their local 720 BPSec policy and configuration. 722 4.3.4. AAD Scope Flags 724 This optional parameter contains a series of flags that describe what 725 information is to be included with the block-type-specific data of 726 the security target as part of additional authenticated data (AAD). 728 This value MUST be represented as a CBOR unsigned integer, the value 729 of which MUST be processed as a bit field. 731 AAD scope flags that are unrecognized MUST be ignored, as future 732 definitions of additional flags might not be integrated 733 simultaneously into security context implementations operating at all 734 nodes. 736 Bits in this field represent additional information to be included 737 when generating an integrity signature over the security target. 738 These bits are defined as follows. 740 - Bit 0 (the low-order bit, 0x0001): Primary Block Flag. 742 - Bit 1 (0x0002): Target Header Flag. 744 - Bit 2 (0x0003): Security Header Flag. 746 - Bits 3-7 are reserved. 748 - Bits 8-15 are unassigned. 750 4.3.5. Enumerations 752 BCB-AES-GCM defines the following security context parameters. 754 BCB-AES-GCM Security Parameters 756 +----+-----------------------+--------------------+---------------+ 757 | Id | Name | CBOR Encoding Type | Default Value | 758 +----+-----------------------+--------------------+---------------+ 759 | 1 | Initialization Vector | Byte String | NONE | 760 | 2 | AES Variant | UINT | 3 | 761 | 3 | Wrapped Key | Byte String | NONE | 762 | 4 | AAD Scope Flags | UINT | 0x7 | 763 +----+-----------------------+--------------------+---------------+ 765 Table 4 767 4.4. Results 769 The BCB-AES-GCM security context produces a single security result 770 carried in the security block: the authentication tag. 772 NOTES: 774 The cipher text generated by the cipher suite is not considered a 775 security result as it is stored in the block-type-specific data 776 field of the security target block. When operating in GCM mode, 777 AES produces cipher text of the same size as its plain text and, 778 therefore, no additional logic is required to handle padding or 779 overflow caused by the encryption in most cases (see below). 781 If the authentication tag can be separated from the cipher text, 782 then the tag MAY be separated and stored in the authentication tag 783 security result field. Otherwise, the security target block MUST 784 be resized to accommodate the additional 128 bits of 785 authentication tag included with the generated cipher text 786 replacing the block-type-specific-data field of the security 787 target block. 789 4.4.1. Authentication Tag 791 The authentication tag is generated by the cipher suite over the 792 security target plain text input to the cipher suite as combined with 793 any optional additional authenticated data. This tag is used to 794 ensure that the plain text (and important information associated with 795 the plain text) is authenticated prior to decryption. 797 If the authentication tag is included in the cipher text placed in 798 the security target block-type-specific data field, then this 799 security result MUST NOT be included in the BCB for that security 800 target. 802 The length of the authentication tag, prior to any CBOR encoding, 803 MUST be 128 bits. 805 This value MUST be encoded as a CBOR byte string. 807 4.4.2. Enumerations 809 BCB-AES-GCM defines the following security context parameters. 811 BCB-AES-GCM Security Results 813 +-----------+--------------------+--------------------+ 814 | Result Id | Result Name | CBOR Encoding Type | 815 +-----------+--------------------+--------------------+ 816 | 1 | Authentication Tag | Byte String | 817 +-----------+--------------------+--------------------+ 819 Table 5 821 4.5. Key Considerations 823 Keys used with this context MUST be symmetric and MUST have a key 824 length equal to the key length defined in the security context 825 parameters or as defined by local security policy at security 826 verifiers and acceptors. For this reason, content-encrypting keys 827 will be integer divisible by 8 bytes and special padding-aware AES 828 key wrap algorithms are not needed. 830 It is assumed that any security verifier or security acceptor can 831 determine the proper key to be used. Potential sources of the key 832 include (but are not limited to) the following. 834 Pre-placed keys selected based on local policy. 836 Keys extracted from material carried in the BCB. 838 Session keys negotiated via a mechanism external to the BCB. 840 When an AES-KW wrapped key is present in a security block, it is 841 assumed that security verifiers and security acceptors can 842 independently determine the key encryption key (KEK) used in the 843 wrapping of the symmetric AES content-encrypting key. 845 The security provided by block ciphers is reduced as more data is 846 processed with the same key. The total number of bytes processed 847 with a single key for AES-GCM is recommended to be less than 2^64, as 848 described in Appendix B of [AES-GCM]. 850 As discussed in Section 6 and emphasized here, it is strongly 851 recommended that keys be protected once generated, both when they are 852 stored and when they are transmitted. 854 4.6. GCM Considerations 856 The GCM cryptographic mode of AES has specific requirements that MUST 857 be followed by implementers for the secure function of the BCB-AES- 858 GCM security context. While these requirements are well documented 859 in [AES-GCM], some of them are repeated here for emphasis. 861 The pairing of an IV and a security key MUST be unique. An IV 862 MUST NOT be used with a security key more than one time. If an IV 863 and key pair are repeated then the GCM implementation is 864 vulnerable to forgery attacks. More information regarding the 865 importance of the uniqueness of the IV value can be found in 866 Appendix A of [AES-GCM]. 868 While any tag-based authentication mechanism has some likelihood 869 of being forged, this probability is increased when using AES-GCM. 870 In particular, short tag lengths combined with very long messages 871 SHOULD be avoided when using this mode. The BCB-AES-GCM security 872 context requires the use of 128-bit authentication tags at all 873 times. Concerns relating to the size of authentication tags is 874 discussed in Appendices B and C of [AES-GCM]. 876 As discussed in Appendix B of [AES-GCM], implementations SHOULD 877 limit the number of unsuccessful verification attempts for each 878 key to reduce the likelihood of guessing tag values. 880 As discussed in the Security Considerations section of 881 [I-D.ietf-dtn-bpsec], delay-tolerant networks have a higher 882 occurrence of replay attacks due to the store-and-forward nature 883 of the network. Because GCM has no inherent replay attack 884 protection, implementors SHOULD attempt to detect replay attacks 885 by using mechanisms such as those described in Appendix D of 886 [AES-GCM]. 888 4.7. Canonicalization Algorithms 890 This section defines the canonicalization algorithms used to prepare 891 the inputs used to generate both the cipher text and the 892 authentication tag. 894 In all cases, the canonical form of any portion of an extension block 895 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 896 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 897 the canonical forms for extension blocks defined in 898 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 899 are represented in CBOR. 901 4.7.1. Cipher text related calculations 903 The plain text used during encryption MUST be calculated as the 904 single, definite-length CBOR byte string representing the block-type- 905 specific data field of the security target excluding the CBOR byte 906 string identifying byte and optional CBOR byte string length field. 908 For example, consider the following two CBOR byte strings and the 909 plain text that would be extracted from them. 911 CBOR Byte String Examples 913 +------------------------------+---------+--------------------------+ 914 | CBOR Byte String (Hex) | CBOR | Plain Text Part (Hex) | 915 | | Part | | 916 | | (Hex) | | 917 +------------------------------+---------+--------------------------+ 918 | 18ED | 18 | ED | 919 +------------------------------+---------+--------------------------+ 920 | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | 921 +------------------------------+---------+--------------------------+ 923 Table 6 925 Similarly, the cipher text used during decryption MUST be calculated 926 as the single, definite-length CBOR byte string representing the 927 block-type-specific data field excluding the CBOR byte string 928 identifying byte and optional CBOR byte string length field. 930 All other fields of the security target (such as the block type code, 931 block number, block processing control flags, or any CRC information) 932 MUST NOT be considered as part of encryption or decryption. 934 4.7.2. Additional Authenticated Data 936 The construction of additional authenticated data depends on the AAD 937 scope flags that can be provided as part of customizing the behavior 938 of this security context. 940 The canonical form of the AAD input to the BCB-AES-GCM mechanism is 941 constructed using the following process. This process MUST be 942 followed when generating AAD for either encryption or decryption. 944 1. The canonical form of the AAD starts as the empty set with length 945 0. 947 2. If the AAD scope parameter is present and the primary block flag 948 is set to 1, then a canonical form of the bundle's primary block 949 MUST be calculated and the result appended to the AAD. 951 3. If the AAD scope parameter is present and the target header flag 952 is set to 1, then the canonical form of the block type code, 953 block number, and block processing control flags associated with 954 the security target MUST be calculated and, in that order, 955 appended to the AAD. 957 4. If the AAD scope parameter is present and the security header 958 flag is set to 1, then the canonical form of the block type code, 959 block number, and block processing control flags associated with 960 the BIB MUST be calculated and, in that order, appended to the 961 AAD. 963 If, after this process, the AAD remains at length 0, then no AAD 964 exists to be input to the cipher suite. 966 4.8. Processing 968 4.8.1. Encryption 970 During encryption, four inputs are prepared for input to the AES/GCM 971 cipher: the encryption key, the IV, the security target plain text to 972 be encrypted, and any additional authenticated data. These data 973 items MUST be generated as follows. 975 Prior to encryption, if a CRC value is present for the target block, 976 then that CRC value MUST be removed. This requires removing the CRC 977 field from the target block and setting the CRC type field of the 978 target block to "no CRC is present." 980 The encryption key MUST have the appropriate length as required by 981 local security policy. The key might be generated specifically 982 for this encryption, given as part of local security policy, or 983 through some other key management mechanism as discussed in 984 Section 4.5. 986 The IV selected MUST be of the appropriate length. Because 987 replaying an IV in counter mode voids the confidentiality of all 988 messages encrypted with said IV, this context also requires a 989 unique IV for every encryption performed with the same key. This 990 means the same key and IV combination MUST NOT be used more than 991 once. 993 The security target plain text for encryption MUST be generated as 994 discussed in Section 4.7.1. 996 Additional authenticated data, if present, MUST be generated as 997 discussed in Section 4.7.2 with the value of AAD scope flags being 998 taken from local security policy. 1000 Upon successful encryption the following actions MUST occur. 1002 The cipher text produced by AES/GCM MUST replace the bytes used to 1003 define the plain text in the security target block's block-type- 1004 specific data field. The block length of the security target MUST 1005 be updated if the generated cipher text is larger than the plain 1006 text (which can occur when the authentication tag is included in 1007 the cipher text calculation, as discussed in Section 4.4). 1009 The authentication tag calculated by the AES/GCM cipher MUST be 1010 added as a security result for the security target in the BCB 1011 holding results for this security operation. 1013 Cases where the authentication tag is generated as part of the 1014 cipher text MUST be processed as described in Section 4.4. 1016 Finally, the BCB containing information about this security operation 1017 MUST be updated as follows. These operations can occur in any order. 1019 The security context identifier for the BCB MUST be set to the 1020 context identifier for BCB-AES-GCM. 1022 The IV input to the cipher MUST be added as the IV security 1023 parameter for the BCB. 1025 Any local flags used to generated AAD for this cipher MUST be 1026 added as the AAD scope flags security parameter for the BCB. 1028 The encryption key MAY be wrapped using the NIST AES-KW algorithm 1029 and the results of the wrapping added as the wrapped key security 1030 parameter for the BCB. 1032 The key length used by this security context MUST be considered 1033 when setting the AES variant security parameter for the BCB if it 1034 differs from the default AES variant. Otherwise, the AES variant 1035 MAY be omitted if doing so provides a useful reduction in message 1036 sizes. 1038 Problems encountered in the encryption MUST be processed in 1039 accordance with local security policy. This MAY include restoring a 1040 CRC value removed from the target block prior to encryption, if the 1041 target block is allowed to be transmitted after an encryption error. 1043 4.8.2. Decryption 1045 During encryption, five inputs are prepared for input to the AES/GCM 1046 cipher: the decryption key, the IV, the security target cipher text 1047 to be decrypted, any additional authenticated data, and the 1048 authentication tag generated from the original encryption. These 1049 data items MUST be generated as follows. 1051 The decryption key MUST be derived using the wrapped key security 1052 parameter if such a parameter is included in the security context 1053 parameters of the BCB. Otherwise this key MUST be derived in 1054 accordance with local security policy at the decrypting node as 1055 discussed in Section 4.5. 1057 The IV MUST be set to the value of the IV security parameter 1058 included in the BCB. If the IV parameter is not included as a 1059 security parameter, an IV MAY be derived as a function of local 1060 security policy and other BCB contents or a lack of an IV security 1061 parameter in the BCB MAY be treated as an error by the decrypting 1062 node. 1064 The security target cipher text for decryption MUST be generated 1065 as discussed in Section 4.7.1. 1067 Additional authenticated data, if present, MUST be generated as 1068 discussed in Section 4.7.2 with the value of AAD scope flags being 1069 taken from the AAD scope flags security context parameter. If the 1070 AAD scope flags parameter is not included in the security context 1071 parameters then these flags MAY be derived from local security 1072 policy in cases where the set of such flags is determinable in the 1073 network. 1075 The authentication tag MUST be present in the BCB security context 1076 parameters field if additional authenticated data are defined for 1077 the BCB (either in the AAD scope flags parameter or as specified 1078 by local policy). This tag MUST be 128 bits in length. 1080 Upon successful decryption the following actions MUST occur. 1082 The plain text produced by AES/GCM MUST replace the bytes used to 1083 define the cipher text in the security target block's block-type- 1084 specific data field. Any changes to the security target block 1085 length field MUST be corrected in cases where the plain text has a 1086 different length than the replaced cipher text. 1088 If the security acceptor is not the bundle destination and if no 1089 other integrity or confidentiality service is being applied to the 1090 target block, then a CRC MUST be included for the target block. The 1091 CRC type, as determined by policy, is set in the target block's CRC 1092 type field and the corresponding CRC value is added as the CRC field 1093 for that block. 1095 If the cipher text fails to authenticate, if any needed parameters 1096 are missing, or if there are other problems in the decryption then 1097 the decryption MUST be treated as failed and processed in accordance 1098 with local security policy. 1100 5. IANA Considerations 1102 5.1. Security Context Identifiers 1104 This specification allocates two security context identifiers from 1105 the "BPSec Security Context Identifiers" registry defined in 1106 [I-D.ietf-dtn-bpsec]. 1108 Additional Entries for the BPSec Security Context Identifiers 1109 Registry: 1111 +-------+---------------+---------------+ 1112 | Value | Description | Reference | 1113 +-------+---------------+---------------+ 1114 | TBA | BIB-HMAC-SHA2 | This document | 1115 | TBA | BCB-AES-GCM | This document | 1116 +-------+---------------+---------------+ 1118 Table 7 1120 5.2. Integrity Scope Flags 1122 The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field 1123 for which IANA is requested to create and maintain a new registry 1124 named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle 1125 Protocol registry page. Initial values for this registry are given 1126 below. 1128 The registration policy for this registry is: Specification Required. 1130 The value range is unsigned 16-bit integer. 1132 BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry 1134 +-------------------------+--------------------------+--------------+ 1135 | Bit Position (right to | Description | Reference | 1136 | left) | | | 1137 +-------------------------+--------------------------+--------------+ 1138 | 0 | Include primary block | This | 1139 | | | document | 1140 | 1 | Include target header | This | 1141 | | flag | document | 1142 | 2 | Include security header | This | 1143 | | flag | document | 1144 | 3-7 | reserved | This | 1145 | | | document | 1146 | 8-15 | unassigned | This | 1147 | | | document | 1148 +-------------------------+--------------------------+--------------+ 1150 Table 8 1152 5.3. AAD Scope Flags 1154 The BCB-AES-GCM security context has an AAD Scope Flags field for 1155 which IANA is requested to create and maintain a new registry named 1156 "BPSec BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol registry 1157 page. Initial values for this registry are given below. 1159 The registration policy for this registry is: Specification Required. 1161 The value range is unsigned 16-bit integer. 1163 BPSec BCB-AES-GCM AAD Scope Flags Registry 1165 +-------------------------+--------------------------+--------------+ 1166 | Bit Position (right to | Description | Reference | 1167 | left) | | | 1168 +-------------------------+--------------------------+--------------+ 1169 | 0 | Include primary block | This | 1170 | | | document | 1171 | 1 | Include target header | This | 1172 | | flag | document | 1173 | 2 | Include security header | This | 1174 | | flag | document | 1175 | 3-7 | reserved | This | 1176 | | | document | 1177 | 8-15 | unassigned | This | 1178 | | | document | 1179 +-------------------------+--------------------------+--------------+ 1181 Table 9 1183 6. Security Considerations 1185 Security considerations specific to a single security context are 1186 provided in the description of that context. This section discusses 1187 security considerations that should be evaluated by implementers of 1188 any security context described in this document. Considerations can 1189 also be found in documents listed as normative references and they 1190 should also be reviewed by security context implementors. 1192 6.1. Key Management 1194 The delayed and disrupted nature of DTNs complicates the process of 1195 key management because there might not be reliable, timely round-trip 1196 exchange between security sources, security verifiers, and security 1197 acceptors in the network. This is true when there is a substantial 1198 signal propagation delay between nodes, when nodes are in a highly 1199 challenged communications environment, and when nodes do not support 1200 bi-directional communication. 1202 In these environments, key establishment protocols that rely on 1203 round-trip information exchange might not converge on a shared secret 1204 in a timely manner (or at all). Also, key revocation or key 1205 verification mechanisms that rely on access to a centralized 1206 authority (such as a certificate authority) might similarly fail in 1207 the stressing conditions of a DTN. 1209 For these reasons, the default security contexts described in this 1210 document rely on symmetric key cryptographic mechanisms because 1211 asymmetric key infrastructure (such as a public key infrastructure) 1212 is impractical in this environment. This extends to any asymmetric- 1213 key mechanism for key derivation, key exchange, or key revocation. 1215 BPSec assumes that "key management is handled as a separate part of 1216 network management" [I-D.ietf-dtn-bpsec]. This assumption is also 1217 made by the security contexts defined in this document which do not 1218 define new protocols for key derivation, exchange of key-encrypting 1219 keys, revocation of existing keys, or the security configuration or 1220 policy used to select certain keys for certain security operations. 1222 Nodes using these security contexts need to perform the following 1223 kinds of activities, independent of the construction, transmission, 1224 and processing of BPSec security blocks. 1226 Establish shared key-encrypting-keys with other nodes in the 1227 network using an out-of-band mechanism. This might include pre- 1228 sharing of key encryption keys or the use of traditional key 1229 establishment mechanisms prior to the exchange of BPsec security 1230 blocks. 1232 Determine when a key is considered exhausted and no longer to be 1233 used in the generation, verification, or acceptance of a security 1234 block. 1236 Determine when a key is considered invalid and no longer to be 1237 used in the generation, verification, or acceptance of a security 1238 block. Such revocations can be based on a variety of mechanisms 1239 to include local security policy, time relative to the generation 1240 or use of the key, or as specified through network management. 1242 Determine, through an out-of-band mechanism such as local security 1243 policy, what keys are to be used for what security blocks. This 1244 includes the selection of which key should be used in the 1245 evaluation of a security block received by a security verifier or 1246 a security acceptor. 1248 The failure to provide effective key management techniques 1249 appropriate for the operational networking environment can result in 1250 the compromise of those unmanaged keys and the loss of security 1251 services in the network. 1253 6.2. Key Handling 1255 Once generated, keys should be handled as follows. 1257 It is strongly RECOMMENDED that implementations protect keys both 1258 when they are stored and when they are transmitted. 1260 In the event that a key is compromised, any security operations 1261 using a security context associated with that key SHOULD also be 1262 considered compromised. This means that the BIB-HMAC-SHA2 1263 security context SHOULD NOT provide integrity when used with a 1264 compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality 1265 when used with a compromised key. 1267 The same key SHOULD NOT be used for different algorithms as doing 1268 so might leak information about the key. 1270 6.3. AES GCM 1272 There are a significant number of considerations related to the use 1273 of the GCM mode of AES to provide a confidentiality service. These 1274 considerations are provided in Section 4.6 as part of the 1275 documentation of the BCB-AES-GCM security context. 1277 The length of the cipher text produced by the GCM mode of AES will be 1278 equal to the length of the plain text input to the cipher suite. The 1279 authentication tag also produced by this cipher suite is separate 1280 from the cipher text. However, it should be noted that 1281 implementations of the AES-GCM cipher suite might not separate the 1282 concept of cipher text and authentication tag in their application 1283 programming interface (API). 1285 Implementations of the BCB-AES-GCM security context can either keep 1286 the length of the target block unchanged by holding the 1287 authentication tag in a BCB security result or alter the length of 1288 the target block by including the authentication tag with the cipher 1289 text replacing the block-type-specific-data field of the target 1290 block. Implementations MAY use the authentication tag security 1291 result in cases where keeping target block length unchanged is an 1292 important processing concern. In all cases, the cipher text and 1293 authentication tag MUST be processed in accordance with the API of 1294 the AES-GCM cipher suites at the security source and security 1295 acceptor. 1297 6.4. AES Key Wrap 1299 The AES key wrap (AES-KW) algorithm used by the security contexts in 1300 this document does not use an initialization vector and does not 1301 require any key padding. Key padding is not needed because wrapped 1302 keys used by these security contexts will always be multiples of 8 1303 bytes. The length of the wrapped key can be determined by inspecting 1304 the security context parameters. Therefore, a key can be unwrapped 1305 using only the information present in the security block and the key 1306 encryption key provided by local security policy at the security 1307 verifier or security acceptor. 1309 6.5. Bundle Fragmentation 1311 Bundle fragmentation might prevent security services in a bundle from 1312 being verified after a bundle is fragmented and before the bundle is 1313 re-assembled. Examples of potential issues include the following. 1315 If a security block and its security target do not exist in the 1316 same fragment, then the security block cannot be processed until 1317 the bundle is re-assembled. If a fragment includes an encrypted 1318 target block, but not its BCB, then a receiving bundle processing 1319 agent (BPA) will not know that the target block has been 1320 encrypted. 1322 If a security block is cryptographically bound to a bundle, it 1323 cannot be processed even if the security block and target both 1324 coexist in the fragment. This is because fragments have different 1325 primary blocks than the original bundle. 1327 If security blocks and their target blocks are repeated in 1328 multiple fragments, policy needs to determine how to deal with 1329 issues where a security operation verifies in one fragment but 1330 fails in another fragment. This might happen, for example, if a 1331 BIB block becomes corrupted in one fragment but not in another 1332 fragment. 1334 Implementors should consider how security blocks are processed when a 1335 BPA fragments a received bundle. For example, security blocks and 1336 their targets could be placed in the same fragment if the security 1337 block is not otherwise cryptographically bound to the bundle being 1338 fragmented. Alternatively, if security blocks are cryptographically 1339 bound to a bundle, then a fragmenting BPA should consider 1340 encapsulating the bundle first and then fragmenting the encapsulating 1341 bundle. 1343 7. Normative References 1345 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 1346 Recommendation for Block Cipher Modes of Operation: 1347 Galois/Counter Mode (GCM) and GMAC.", November 2007. 1349 [AES-KW] Dworkin, M., "NIST Special Publication 800-38F: 1350 Recommendation for Block Cipher Modes of Operation: 1351 Methods for Key Wrapping.", December 2012. 1353 [HMAC] US NIST, "The Keyed-Hash Message Authentication Code 1354 (HMAC).", FIPS-198-1, Gaithersburg, MD, USA, July 2008. 1356 https://csrc.nist.gov/publications/detail/fips/198/1/final 1358 [I-D.ietf-dtn-bpbis] 1359 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1360 Version 7", draft-ietf-dtn-bpbis-31 (work in progress), 1361 January 2021. 1363 [I-D.ietf-dtn-bpsec] 1364 Birrane, E. and K. McKeever, "Bundle Protocol Security 1365 Specification", draft-ietf-dtn-bpsec-27 (work in 1366 progress), February 2021. 1368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1369 Requirement Levels", BCP 14, RFC 2119, 1370 DOI 10.17487/RFC2119, March 1997, 1371 . 1373 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1374 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1375 . 1377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1379 May 2017, . 1381 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1382 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1383 . 1385 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1386 Representation (CBOR)", STD 94, RFC 8949, 1387 DOI 10.17487/RFC8949, December 2020, 1388 . 1390 [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- 1391 180-4, Gaithersburg, MD, USA, August 2015. 1393 https://csrc.nist.gov/publications/detail/fips/180/4/final 1395 Appendix A. Examples 1397 This appendix is informative. 1399 This section presents a series of examples of constructing BPSec 1400 security blocks (using the security contexts defined in this 1401 document) and adding those blocks to a sample bundle. 1403 The examples presented in this appendix represent valid constructions 1404 of bundles, security blocks, and the encoding of security context 1405 parameters and results. For this reason, they can inform unit test 1406 suites for individual implementations as well as interoperability 1407 test suites amongst implementations. However, these examples do not 1408 cover every permutation of security parameters, security results, or 1409 use of security blocks in a bundle. 1411 NOTE: Figures in this section identified as "(CBOR Diagnostic 1412 Notation)" are represented using the CBOR diagnostic notation defined 1413 in [RFC8949]. This notation is used to express CBOR data structures 1414 in a manner that enables visual inspection. The bundles, security 1415 blocks, and security context contents in these figures are 1416 represented using CBOR structures. In cases where BP blocks (to 1417 include BPSec security blocks) are comprised of a sequence of CBOR 1418 objects, these objects are represented as a CBOR sequence as defined 1419 in [RFC8742]. 1421 NOTE: Examples in this section use the "ipn" URI scheme for 1422 EndpointID naming, as defined in [I-D.ietf-dtn-bpbis]. 1424 NOTE: The bundle source is presumed to be the security source for all 1425 security blocks in this section, unless otherwise noted. 1427 A.1. Example 1: Simple Integrity 1429 This example shows the addition of a BIB to a sample bundle to 1430 provide integrity for the payload block. 1432 A.1.1. Original Bundle 1434 The following diagram shows the original bundle before the BIB has 1435 been added. 1437 Block Block Block 1438 in Bundle Type Number 1439 +========================================+=======+========+ 1440 | Primary Block | N/A | 0 | 1441 +----------------------------------------+-------+--------+ 1442 | Payload Block | 0 | 1 | 1443 +----------------------------------------+-------+--------+ 1445 Figure 1: Example 1 Original Bundle 1447 A.1.1.1. Primary Block 1449 The BPv7 bundle has no special processing flags and no CRC is 1450 provided because the primary block is expected to be protected by an 1451 integrity service BIB using the BIB-HMAC-SHA2 security context. 1453 The bundle is sourced at the source node ipn:2.1 and destined for the 1454 destination node ipn:1.2. The bundle creation time uses a DTN 1455 creation time of 0 indicating lack of an accurate clock and a 1456 sequence number of 40. The lifetime of the bundle is given as 1457 1,000,000 milliseconds since the bundle creation time. 1459 The primary block is provided as follows. 1461 [ 1462 7, / BP version / 1463 0, / flags / 1464 0, / CRC type / 1465 [2, [1,2]], / destination (ipn:1.2) / 1466 [2, [2,1]], / source (ipn:2.1) / 1467 [2, [2,1]], / report-to (ipn:2.1) / 1468 [0, 40], / timestamp / 1469 1000000 / lifetime / 1470 ] 1472 Figure 2: Primary Block (CBOR Diagnostic Notation) 1474 The CBOR encoding of the primary block is 1475 0x88070000820282010282028202018202820201820018281a000f4240. 1477 A.1.1.2. Payload Block 1479 Other than its use as a source of plaintext for security blocks, the 1480 payload has no required distinguishing characteristic for the purpose 1481 of this example. The sample payload is a 32 byte string whose value 1482 is "Ready Generate a 32 byte payload". 1484 The payload is represented in the payload block as a byte string of 1485 the raw payload string. It is NOT represented as a CBOR text string 1486 wrapped within a CBOR binary string. The hex value of the payload 1487 "Ready Generate a 32 byte payload" is 1488 0x52656164792047656e657261746520612033322062797465207061796c6f6164. 1490 The payload block is provided as follows. 1492 [ 1493 1, / type code: Payload block / 1494 1, / block number / 1495 0, / block processing flags / 1496 0, / CRC Type / 1497 h'52656164792047656e65726174652061 / type-specific-data: payload / 1498 2033322062797465207061796c6f6164' 1500 ] 1502 Payload Block (CBOR Diagnostic Notation) 1504 The CBOR encoding of the payload block is 0x8501010000582052656164792 1505 047656e657261746520612033322062797465207061796c6f6164. 1507 A.1.1.3. Bundle CBOR Representation 1509 A BPv7 bundle is represented as an indefinite-length array consisting 1510 of the blocks comprising the bundle, with a terminator character at 1511 the end. 1513 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1514 28202018202820201820018281a000f42408501010000582052656164792047656e65 1515 7261746520612033322062797465207061796c6f6164ff. 1517 A.1.2. Security Operation Overview 1519 This example adds a BIB to the bundle using the BIB-HMAC-SHA2 1520 security context to provide an integrity mechanism over the payload 1521 block. 1523 The following diagram shows the resulting bundle after the BIB is 1524 added. 1526 Block Block Block 1527 in Bundle Type Number 1528 +========================================+=======+========+ 1529 | Primary Block | N/A | 0 | 1530 +----------------------------------------+-------+--------+ 1531 | Bundle Integrity Block | 11 | 2 | 1532 | OP(bib-integrity, target=1) | | | 1533 +----------------------------------------+-------+--------+ 1534 | Payload Block | 0 | 1 | 1535 +----------------------------------------+-------+--------+ 1537 Figure 3: Example 1 Resulting Bundle 1539 A.1.3. Bundle Integrity Block 1541 In this example, a BIB is used to carry an integrity signature over 1542 the payload block. 1544 A.1.3.1. Configuration, Parameters, and Results 1546 For this example, the following configuration and security parameters 1547 are used to generate the security results indicated. 1549 This BIB has a single target and includes a single security result: 1550 the calculated signature over the payload block. 1552 Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 1553 SHA Variant : HMAC 512/512 1554 Scope Flags : 0 1555 Payload Data: h'52656164792047656e65726174652061 1556 2033322062797465207061796c6f6164' 1557 Signature : h'd8e7c3be29effa8779e7dcb0d3cadf53 1558 39df50ebd27b9054f197c8ea9864b0a3 1559 35a0636213e5d4a9c95504f261d91a2f 1560 22757112c95e3587a76b4228361803e8' 1562 Figure 4: Example 1: Configuration, Parameters, and Results 1564 A.1.3.2. Abstract Security Block 1566 The abstract security block structure of the BIB's block-type- 1567 specific-data field for this application is as follows. 1569 [1], / Security Target / 1570 1, / Security Context ID - BIB-HMAC-SHA2 / 1571 1, / Security Context Flags - Parameters Present / 1572 [2,[2, 1]], / Security Source - ipn:2.1 / 1573 [ / Security Parameters - 2 Parameters / 1574 [1, 7], / SHA Variant - HMAC 512/512 / 1575 [3, 0] / Scope Flags - No Additional Scope / 1576 ], 1577 [ / Security Results: 1 Result / 1578 [1, h'd8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864 1579 b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228 1580 361803e8'] 1581 ] 1583 Figure 5: Example 1: BIB Abstract Security Block (CBOR Diagnostic 1584 Notation) 1586 The CBOR encoding of the BIB block-type-specific-data field (the 1587 abstract security block) is 0x810101018202820201828201078203008182015 1588 840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864b0a335 1589 a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228361803e8. 1591 A.1.3.3. Representations 1593 The BIB wrapping this abstract security block is as follows. 1595 [ 1596 11, / type code / 1597 2, / block number / 1598 0, / flags / 1599 0, / CRC type / 1600 h'810101018202820201828201078203008182015840d8e7c3be29effa8779e7dcb 1601 0d3cadf5339df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f2 1602 61d91a2f22757112c95e3587a76b4228361803e8', 1603 ] 1605 Figure 6: Example 1: BIB (CBOR Diagnostic Notation) 1607 The CBOR encoding of the BIB block is 0x850b0200005855810101018202820 1608 201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd2 1609 7b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e358 1610 7a76b4228361803e8. 1612 A.1.4. Final Bundle 1614 The CBOR encoding of the full output bundle, with the BIB: 0x9F880700 1615 00820282010282028202018202820201820018281a000f4240850b020000585581010 1616 1018202820201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf53 1617 39df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757 1618 112c95e3587a76b4228361803e8ff. 1620 A.2. Example 2: Simple Confidentiality with Key Wrap 1622 This example shows the addition of a BCB to a sample bundle to 1623 provide confidentiality for the payload block. AES key wrap is used 1624 to transmit the symmetric key used to generate the security results 1625 for this service. 1627 A.2.1. Original Bundle 1629 The following diagram shows the original bundle before the BCB has 1630 been added. 1632 Block Block Block 1633 in Bundle Type Number 1634 +========================================+=======+========+ 1635 | Primary Block | N/A | 0 | 1636 +----------------------------------------+-------+--------+ 1637 | Payload Block | 0 | 1 | 1638 +----------------------------------------+-------+--------+ 1640 Figure 7: Example 2 Original Bundle 1642 A.2.1.1. Primary Block 1644 The primary block used in this example is identical to the primary 1645 block presented in Example 1 Appendix A.1.1.1. 1647 In summary, the CBOR encoding of the primary block is 1648 0x88070000820282010282028202018202820201820018281a000f4240. 1650 A.2.1.2. Payload Block 1652 The payload block used in this example is identical to the payload 1653 block presented in Example 1 Appendix A.1.1.2. 1655 In summary, the CBOR encoding of the payload block is 0x8501010000582 1656 052656164792047656e657261746520612033322062797465207061796c6f6164. 1658 A.2.1.3. Bundle CBOR Representation 1660 A BPv7 bundle is represented as an indefinite-length array consisting 1661 of the blocks comprising the bundle, with a terminator character at 1662 the end. 1664 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1665 28202018202820201820018281a000f42408501010000582052656164792047656e65 1666 7261746520612033322062797465207061796c6f6164ff. 1668 A.2.2. Security Operation Overview 1670 This example adds a BCB using the BCB-AES-GCM security context using 1671 AES key wrap to provide a confidentiality mechanism over the payload 1672 block and transmit the symmetric key. 1674 The following diagram shows the resulting bundle after the BCB is 1675 added. 1677 Block Block Block 1678 in Bundle Type Number 1679 +========================================+=======+========+ 1680 | Primary Block | N/A | 0 | 1681 +----------------------------------------+-------+--------+ 1682 | Bundle Confidentiality Block | 12 | 2 | 1683 | OP(bcb-confidentiality, target=1) | | | 1684 +----------------------------------------+-------+--------+ 1685 | Payload Block (Encrypted) | 0 | 1 | 1686 +----------------------------------------+-------+--------+ 1688 Figure 8: Example 2 Resulting Bundle 1690 A.2.3. Bundle Confidentiality Block 1692 In this example, a BCB is used to encrypt the payload block and uses 1693 AES key wrap to transmit the symmetric key. 1695 A.2.3.1. Configuration, Parameters, and Results 1697 For this example, the following configuration and security parameters 1698 are used to generate the security results indicated. 1700 This BCB has a single target, the payload block. Three security 1701 results are generated: cipher text which replaces the plain text 1702 block-type-specific data to encrypt the payload block, an 1703 authentication tag, and the AES wrapped key. 1705 Content Encryption 1706 Key: h'71776572747975696f70617364666768' 1707 Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' 1708 IV: h'5477656c7665313231323132' 1709 AES Variant: A128GCM 1710 AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 1711 96fabf34d7fae700' 1712 Scope Flags: 0 1713 Payload Data: h'52656164792047656e65726174652061 1714 2033322062797465207061796c6f6164' 1715 Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb' 1716 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 1717 a563e32648b700c2784e26a990d91f9d' 1719 Figure 9: Example 2: Configuration, Parameters, and Results 1721 A.2.3.2. Abstract Security Block 1723 The abstract security block structure of the BCB's block-type- 1724 specific-data field for this application is as follows. 1726 [1], / Security Target / 1727 2, / Security Context ID - BCB-AES-GCM / 1728 1, / Security Context Flags - Parameters Present / 1729 [2,[2, 1]], / Security Source - ipn:2.1 / 1730 [ / Security Parameters - 4 Parameters / 1731 [1, h'5477656c7665313231323132'], / Initialization Vector / 1732 [2, 1], / AES Variant - A128GCM / 1733 [3, h'69c411276fecddc4780df42c8a / AES wrapped key / 1734 2af89296fabf34d7fae700'], 1735 [4, 0] / Scope Flags - No extra scope/ 1736 ], 1737 [ / Security Results: 1 Result / 1738 [1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag / 1739 ] 1741 Figure 10: Example 2: BCB Abstract Security Block (CBOR Diagnostic 1742 Notation) 1744 The CBOR encoding of the BCB block-type-specific-data field (the 1745 abstract security block) is 0x8101020182028202018482014c5477656c76653 1746 132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa 1747 e70082040081820150689b98e649ae3b554e98aa2ae8f801eb. 1749 A.2.3.3. Representations 1751 The BCB wrapping this abstract security block is as follows. 1753 [ 1754 12, / type code / 1755 2, / block number / 1756 1, / flags - block must be replicated in every fragment / 1757 0, / CRC type / 1758 h'8101020182028202018482014c5477656c766531323132313282020182035818 1759 69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008182015068 1760 9b98e649ae3b554e98aa2ae8f801eb' 1761 ] 1763 Figure 11: Example 2: BCB (CBOR Diagnostic Notation) 1765 The CBOR encoding of the BCB block is 0x850c020100584f810102018202820 1766 2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d 1767 f42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554e98aa2ae8f 1768 801eb. 1770 A.2.4. Final Bundle 1772 The CBOR encoding of the full output bundle, with the BCB: 0x9f880700 1773 00820282010282028202018202820201820018281a000f4240850c020100584f81010 1774 20182028202018482014c5477656c76653132313231328202018203581869c411276f 1775 ecddc4780df42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554 1776 e98aa2ae8f801eb850101000058203a09c1e63fe2097528a78b7c12943354a563e326 1777 48b700c2784e26a990d91f9dff. 1779 A.3. Example 3: Security Blocks from Multiple Sources 1781 This example shows the addition of a BIB and BCB to a sample bundle. 1782 These two security blocks are added by two different nodes. The BCB 1783 is added by the source endpoint and the BIB is added by a forwarding 1784 node. 1786 The resulting bundle contains a BCB to encrypt the Payload Block and 1787 a BIB to provide integrity to the Primary and Bundle Age Block. 1789 A.3.1. Original Bundle 1791 The following diagram shows the original bundle before the security 1792 blocks have been added. 1794 Block Block Block 1795 in Bundle Type Number 1796 +========================================+=======+========+ 1797 | Primary Block | N/A | 0 | 1798 +----------------------------------------+-------+--------+ 1799 | Extension Block: Bundle Age Block | 7 | 2 | 1800 +----------------------------------------+-------+--------+ 1801 | Payload Block | 0 | 1 | 1802 +----------------------------------------+-------+--------+ 1804 Figure 12: Example 3 Original Bundle 1806 A.3.1.1. Primary Block 1808 The primary block used in this example is identical to the primary 1809 block presented in Example 1 Appendix A.1.1.1. 1811 In summary, the CBOR encoding of the primary block is 1812 0x88070000820282010282028202018202820201820018281a000f4240. 1814 A.3.1.2. Bundle Age Block 1816 A bundle age block is added to the bundle to help other nodes in the 1817 network determine the age of the bundle. The use of this block is as 1818 recommended because the bundle source does not have an accurate clock 1819 (as indicated by the DTN time of 0). 1821 Because this block is specified at the time the bundle is being 1822 forwarded, the bundle age represents the time that has elapsed from 1823 the time the bundle was created to the time it is being prepared for 1824 forwarding. In this case, the value is given as 300 milliseconds. 1826 The bundle age extension block is provided as follows. 1828 [ 1829 7, / type code: Bundle Age block / 1830 2, / block number / 1831 0, / block processing flags / 1832 0, / CRC Type / 1833 <<300>> / type-specific-data: age / 1834 ] 1836 Figure 13: Bundle Age Block (CBOR Diagnostic Notation) 1838 The CBOR encoding of the bundle age block is 0x85070200004319012c. 1840 A.3.1.3. Payload Block 1842 The payload block used in this example is identical to the payload 1843 block presented in Example 1 Appendix A.1.1.2. 1845 In summary, the CBOR encoding of the payload block is 0x8501010000582 1846 052656164792047656e657261746520612033322062797465207061796c6f6164. 1848 A.3.1.4. Bundle CBOR Representation 1850 A BPv7 bundle is represented as an indefinite-length array consisting 1851 of the blocks comprising the bundle, with a terminator character at 1852 the end. 1854 The CBOR encoding of the original bundle is 0x9f880700008202820102820 1855 28202018202820201820018281a000f424085070200004319012c8501010000582052 1856 656164792047656e657261746520612033322062797465207061796c6f6164ff. 1858 A.3.2. Security Operation Overview 1860 This example provides: 1862 a BIB with the BIB-HMAC-SHA2 security context to provide an 1863 integrity mechanism over the primary block and bundle age block. 1865 a BCB with the BCB-AES-GCM security context to provide a 1866 confidentiality mechanism over the payload block. 1868 The following diagram shows the resulting bundle after the security 1869 blocks are added. 1871 Block Block Block 1872 in Bundle Type Number 1873 +========================================+=======+========+ 1874 | Primary Block | N/A | 0 | 1875 +----------------------------------------+-------+--------+ 1876 | Bundle Integrity Block | 11 | 3 | 1877 | OP(bib-integrity, targets=0, 2) | | | 1878 +----------------------------------------+-------+--------+ 1879 | Bundle Confidentiality Block | 12 | 4 | 1880 | OP(bcb-confidentiality, target=1) | | | 1881 +----------------------------------------+-------+--------+ 1882 | Extension Block: Bundle Age Block | 7 | 2 | 1883 +----------------------------------------+-------+--------+ 1884 | Payload Block (Encrypted) | 0 | 1 | 1885 +----------------------------------------+-------+--------+ 1887 Figure 14: Example 3 Resulting Bundle 1889 A.3.3. Bundle Integrity Block 1891 In this example, a BIB is used to carry an integrity signature over 1892 the bundle age block and an additional signature over the payload 1893 block. The BIB is added by a waypoint node, ipn:3.0. 1895 A.3.3.1. Configuration, Parameters, and Results 1897 For this example, the following configuration and security parameters 1898 are used to generate the security results indicated. 1900 This BIB has two security targets and includes two security results, 1901 holding the calculated signatures over the bundle age block and 1902 primary block. 1904 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 1905 SHA Variant: HMAC 256/256 1906 Scope Flags: 0 1907 Primary Block Data: h'8807000082028201028202820201820282020182001 1908 8281a000f4240' 1909 Bundle Age Block 1910 Data: h'85070200004319012c' 1911 Primary Block 1912 Signature: h'2f74b42d88234f0a8a98a6c72775ec6511aff3cb5bf 1913 c06aa648f5fc40f31ec0d' 1914 Bundle Age Block 1915 Signature: h'e61385353ce2b4cce5319bc33326cdc26f4061e76cb 1916 21b434c89199a36b00de3' 1918 Figure 15: Example 3: Configuration, Parameters, and Results for the 1919 BIB 1921 A.3.3.2. Abstract Security Block 1923 The abstract security block structure of the BIB's block-type- 1924 specific-data field for this application is as follows. 1926 [0, 2], / Security Target / 1927 1, / Security Context ID - BIB-HMAC-SHA2 / 1928 1, / Security Context Flags - Parameters Present / 1929 [2,[3, 0]], / Security Source - ipn:3.0 / 1930 [ / Security Parameters - 2 Parameters / 1931 [1, 5], / SHA Variant - HMAC 256/256 / 1932 [3, 0] / Scope Flags - No Additional Scope / 1933 ], 1934 [ / Security Results: 2 Results / 1935 [1, h'2f74b42d88234f0a8a98a6c72775ec6511aff3 / Primary Block / 1936 cb5bfc06aa648f5fc40f31ec0d'], 1937 [1, h'e61385353ce2b4cce5319bc33326cdc26f4061 / Bundle Age Block / 1938 e76cb21b434c89199a36b00de3'] 1939 ] 1941 Figure 16: Example 3: BIB Abstract Security Block (CBOR Diagnostic 1942 Notation) 1944 The CBOR encoding of the BIB block-type-specific-data field (the 1945 abstract security block) is 0x820002010182028203008282010582030082820 1946 158202f74b42d88234f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d 1947 82015820e61385353ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00 1948 de3. 1950 A.3.3.3. Representations 1952 The BIB wrapping this abstract security block is as follows. 1954 [ 1955 11, / type code / 1956 3, / block number / 1957 0, / flags / 1958 0, / CRC type / 1959 h'820002010182028203008282010582030082820158202f74b42d88234f0a8a98 1960 a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353ce2 1961 b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3', 1962 ] 1964 Figure 17: Example 3: BIB (CBOR Diagnostic Notation) 1966 The CBOR encoding of the BIB block is 0x850b030000585a820002010182028 1967 203008282010582030082820158202f74b42d88234f0a8a98a6c72775ec6511aff3cb 1968 5bfc06aa648f5fc40f31ec0d82015820e61385353ce2b4cce5319bc33326cdc26f406 1969 1e76cb21b434c89199a36b00de3. 1971 A.3.4. Bundle Confidentiality Block 1973 In this example, a BCB is used encrypt the payload block. The BCB is 1974 added by the bundle source node, ipn:2.1. 1976 A.3.4.1. Configuration, Parameters, and Results 1978 For this example, the following configuration and security parameters 1979 are used to generate the security results indicated. 1981 This BCB has a single target, the payload block. Two security 1982 results are generated: cipher text which replaces the plain text 1983 block-type-specific data to encrypt the payload block, and an 1984 authentication tag. 1986 Content Encryption 1987 Key: h'71776572747975696f70617364666768' 1988 IV: h'5477656c7665313231323132' 1989 AES Variant: A128GCM 1990 Scope Flags: 0 1991 Payload Data: h'52656164792047656e65726174652061 1992 2033322062797465207061796c6f6164' 1993 Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb' 1994 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 1995 a563e32648b700c2784e26a990d91f9d' 1997 Figure 18: Example 3: Configuration, Parameters, and Results for the 1998 BCB 2000 A.3.4.2. Abstract Security Block 2002 The abstract security block structure of the BCB's block-type- 2003 specific-data field for this application is as follows. 2005 [1], / Security Target / 2006 2, / Security Context ID - BCB-AES-GCM / 2007 1, / Security Context Flags - Parameters Present / 2008 [2,[2, 1]], / Security Source - ipn:2.1 / 2009 [ / Security Parameters - 3 Parameters / 2010 [1, b'Twelve121212'] / Initialization Vector /, 2011 [2, 1] / AES Variant - AES 128 /, 2012 [4, 0] / Scope Flags - No Additional Scope / 2013 ], 2014 [ / Security Results: 1 Result / 2015 [1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag / 2016 ] 2018 Figure 19: Example 3: BCB Abstract Security Block (CBOR Diagnostic 2019 Notation) 2021 The CBOR encoding of the BCB block-type-specific-data field (the 2022 abstract security block) is 0x8101020182028202018382014c5477656C76653 2023 1323132313282020182040081820150689b98e649ae3b554e98aa2ae8f801eb. 2025 A.3.4.3. Representations 2027 The BCB wrapping this abstract security block is as follows. 2029 [ 2030 12, / type code / 2031 4, / block number / 2032 1, / flags - block must be replicated in every fragment / 2033 0, / CRC type / 2034 h'8101020182028202018382014c5477656C766531323132313282020182040081 2035 820150689b98e649ae3b554e98aa2ae8f801eb', 2036 ] 2038 Figure 20: Example 3: BCB (CBOR Diagnostic Notation) 2040 The CBOR encoding of the BCB block is 0x850c0401005833810102018202820 2041 2018382014c5477656C766531323132313282020182040081820150689b98e649ae3b 2042 554e98aa2ae8f801eb. 2044 A.3.5. Final Bundle 2046 The CBOR encoding of the full output bundle, with the BIB and BCB 2047 added is: 9F88070000820282010282028202018202820201820018281a000f42408 2048 50b030000585a820002010182028203008282010582030082820158202f74b42d8823 2049 4f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353 2050 ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3850c0401005833 2051 8101020182028202018382014c5477656C76653132313231328202018204008182015 2052 0689b98e649ae3b554e98aa2ae8f801eb85070200004319012c850101000058203a09 2053 c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dFF. 2055 A.4. Example 4: Security Blocks with Full Scope 2057 This example shows the addition of a BIB and BCB to a sample bundle. 2058 A BIB is added to provide integrity over the payload block and a BCB 2059 is added for confidentiality over the payload and BIB. 2061 The integrity scope and additional authentication data will bind the 2062 primary block, target header, and the security header. 2064 A.4.1. Original Bundle 2066 The following diagram shows the original bundle before the security 2067 blocks have been added. 2069 Block Block Block 2070 in Bundle Type Number 2071 +========================================+=======+========+ 2072 | Primary Block | N/A | 0 | 2073 +----------------------------------------+-------+--------+ 2074 | Payload Block | 0 | 1 | 2075 +----------------------------------------+-------+--------+ 2077 Figure 21: Example 4 Original Bundle 2079 A.4.1.1. Primary Block 2081 The primary block used in this example is identical to the primary 2082 block presented in Example 1 Appendix A.1.1.1. 2084 In summary, the CBOR encoding of the primary block is 2085 0x88070000820282010282028202018202820201820018281a000f4240. 2087 A.4.1.2. Payload Block 2089 The payload block used in this example is identical to the payload 2090 block presented in Example 1 Appendix A.1.1.2. 2092 In summary, the CBOR encoding of the payload block is 0x8501010000582 2093 052656164792047656e657261746520612033322062797465207061796c6f6164. 2095 A.4.1.3. Bundle CBOR Representation 2097 A BPv7 bundle is represented as an indefinite-length array consisting 2098 of the blocks comprising the bundle, with a terminator character at 2099 the end. 2101 The CBOR encoding of the original bundle is 0x9f880700008202820102820 2102 28202018202820201820018281a000f42408501010000582052656164792047656e65 2103 7261746520612033322062797465207061796c6f6164ff. 2105 A.4.2. Security Operation Overview 2107 This example provides: 2109 a BIB with the BIB-HMAC-SHA2 security context to provide an 2110 integrity mechanism over the payload block. 2112 a BCB with the BCB-AES-GCM security context to provide a 2113 confidentiality mechanism over the payload block and BIB. 2115 The following diagram shows the resulting bundle after the security 2116 blocks are added. 2118 Block Block Block 2119 in Bundle Type Number 2120 +========================================+=======+========+ 2121 | Primary Block | N/A | 0 | 2122 +----------------------------------------+-------+--------+ 2123 | Bundle Integrity Block (Encrypted) | 11 | 3 | 2124 | OP(bib-integrity, target=1) | | | 2125 +----------------------------------------+-------+--------+ 2126 | Bundle Confidentiality Block | 12 | 4 | 2127 | OP(bcb-confidentiality, targets=1, 3) | | | 2128 +----------------------------------------+-------+--------+ 2129 | Payload Block (Encrypted) | 0 | 1 | 2130 +----------------------------------------+-------+--------+ 2132 Figure 22: Example 4 Resulting Bundle 2134 A.4.3. Bundle Integrity Block 2136 In this example, a BIB is used to carry an integrity signature over 2137 the payload block. The IPPT contains the payload block block-type- 2138 specific data, primary block data, the payload block header, and the 2139 BIB header. That is, all additional headers are included in the 2140 IPPT. 2142 A.4.3.1. Configuration, Parameters, and Results 2144 For this example, the following configuration and security parameters 2145 are used to generate the security results indicated. 2147 This BIB has a single target and includes a single security result: 2148 the calculated signature over the Payload block. 2150 Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' 2151 SHA Variant: HMAC 384/384 2152 Scope Flags: 7 (all additional headers) 2153 Primary Block Data: h'88070000820282010282028202018202 2154 820201820018281a000f4240 2155 Payload Data: h'52656164792047656e65726174652061 2156 2033322062797465207061796c6f6164' 2157 Payload Header: h'85010100005820' 2158 BIB Header: h'850b0300005845' 2159 Payload Signature: h'6f56e0f58ec584df34603c75cc055939 2160 00b1a938f23883f119772e1230441d86 2161 9bce6ac9559f721260314424ab14b981 2163 Figure 23: Example 4: Configuration, Parameters, and Results for the 2164 BIB 2166 A.4.3.2. Abstract Security Block 2168 The abstract security block structure of the BIB's block-type- 2169 specific-data field for this application is as follows. 2171 [1], / Security Target / 2172 1, / Security Context ID - BIB-HMAC-SHA2 / 2173 1, / Security Context Flags - Parameters Present / 2174 [2,[2, 1]], / Security Source: ipn:2.1 / 2175 [ / Security Parameters: 2 Parameters / 2176 [1, 6], / SHA Variant - HMAC 384/384 / 2177 [3, 7] / Scope Flags - All additional headers in the SHA Hash / 2178 ], 2179 [ / Security Results: 1 Result / 2180 [1, h'6f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e123044 2181 1d869bce6ac9559f721260314424ab14b981'] 2182 ] 2184 Figure 24: Example 4: BIB Abstract Security Block (CBOR Diagnostic 2185 Notation) 2187 The CBOR encoding of the BIB block-type-specific-data field (the 2188 abstract security block) is 0x810101018202820201828201068203078182015 2189 8306f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e1230441d869b 2190 ce6ac9559f721260314424ab14b981. 2192 A.4.3.3. Representations 2194 The BIB wrapping this abstract security block is as follows. 2196 [ 2197 11, / type code / 2198 3, / block number / 2199 0, / flags / 2200 0, / CRC type / 2201 h'8101010182028202018282010682030781820158306f56e0f58ec584df34603c 2202 75cc05593900b1a938f23883f119772e1230441d869bce6ac9559f7212603144 2203 24ab14b981', 2204 ] 2206 Figure 25: Example 4: BIB (CBOR Diagnostic Notation) 2208 The CBOR encoding of the BIB block is 0x850b0300005845810101018202820 2209 2018282010682030781820158306f56e0f58ec584df34603c75cc05593900b1a938f2 2210 3883f119772e1230441d869bce6ac9559f721260314424ab14b981. 2212 A.4.4. Bundle Confidentiality Block 2214 In this example, a BCB is used encrypt the payload block and the BIB 2215 that provides integrity over the payload. 2217 A.4.4.1. Configuration, Parameters, and Results 2219 For this example, the following configuration and security parameters 2220 are used to generate the security results indicated. 2222 This BCB has two targets: the payload block and BIB. Four security 2223 results are generated: cipher text which replaces the plain text 2224 block-type-specific data of the payload block, cipher text to encrypt 2225 the BIB, and authentication tags for both the payload block and BIB. 2227 Key: h'71776572747975696f70617364666768 2228 71776572747975696f70617364666768' 2229 IV: h'5477656c7665313231323132' 2230 AES Variant: A256GCM 2231 Scope Flags: 7 (All additional headers) 2232 Payload Data: h'52656164792047656e65726174652061 2233 2033322062797465207061796c6f6164' 2234 BIB Data: h'52656164792047656E65726174652061 2235 2033322062797465207061796C6F6164' 2236 BIB 2237 Authentication Tag: h'92bc2665e9f04350c5974f023929dd62' 2238 Payload Block 2239 Authentication Tag: h'865bc14b3910d6c53e95fdc65aa601fd' 2240 Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 2241 319bb227706000abc8fcac3b9bb9c87e' 2242 BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 2243 902a815f2276222e1d0208c628e2c926 2244 2a0c438fc300190dbf5954ae4f84f748 2245 64e58ed1e39043633142ad2559e0e3a9 2246 c9cbce5c2d' 2248 Figure 26: Example 4: Configuration, Parameters, and Results for the 2249 BCB 2251 A.4.4.2. Abstract Security Block 2253 The abstract security block structure of the BCB's block-type- 2254 specific-data field for this application is as follows. 2256 [3, 1], / Security Target / 2257 2, / Security Context ID - BCB-AES-GCM / 2258 1, / Security Context Flags - Parameters Present / 2259 [2,[2, 1]], / Security Source - ipn:2.1 / 2260 [ / Security Parameters - 3 Parameters / 2261 [1, h'5477656c7665313231323132'] / Initialization Vector /, 2262 [2, 3] / AES Variant - AES 256 /, 2263 [4, 7] / Scope Flags - All headers in SHA hash / 2264 ], 2265 [ / Security Results: 2 Results / 2266 [1, h'865bc14b3910d6c53e95fdc65aa601fd'], / Payload Auth. Tag / 2267 [1, h'92bc2665e9f04350c5974f023929dd62'] / BIB Auth. Tag / 2268 ] 2270 Figure 27: Example 4: BCB Abstract Security Block (CBOR Diagnostic 2271 Notation) 2273 The CBOR encoding of the BCB block-type-specific-data field (the 2274 abstract security block) is 0x820301020182028202018382014c5477656C766 2275 531323132313282020382040782820150d0b506cc2e5ede57b36e6c52791457008201 2276 50865bc14b3910d6c53e95fdc65aa601fd. 2278 A.4.4.3. Representations 2280 The BCB wrapping this abstract security block is as follows. 2282 [ 2283 12, / type code / 2284 2, / block number / 2285 1, / flags - block must be replicated in every fragment / 2286 0, / CRC type / 2287 h'820301020182028202018382014c5477656C7665313231323132820203820407 2288 82820150d0b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e 2289 95fdc65aa601fd', 2290 ] 2292 Figure 28: Example 4: BCB (CBOR Diagnostic Notation) 2294 The CBOR encoding of the BCB block is 0x850c0201005847820301020182028 2295 202018382014c5477656C766531323132313282020382040782820150d0b506cc2e5e 2296 de57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd. 2298 A.4.5. Final Bundle 2300 The CBOR encoding of the full output bundle, with the security blocks 2301 added and payload block and BIB encrypted is: 9F880700008202820102820 2302 28202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb94d 2303 952175167df0902a815f2276222e1d0208c628e2c9262a0c438fc300190dbf5954ae4 2304 f84f74864e58ed1e39043633142ad2559e0e3a9c9cbce5c2d 850c020100584782030 2305 1020182028202018382014c5477656C766531323132313282020382040782820150d0 2306 b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd8 2307 501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac3b 2308 9bb9c87eFF. 2310 Appendix B. Acknowledgements 2312 The following participants contributed useful review and analysis of 2313 these security contexts: Amy Alford of the Johns Hopkins University 2314 Applied Physics Laboratory. 2316 Authors' Addresses 2318 Edward J. Birrane, III 2319 The Johns Hopkins University Applied 2320 Physics Laboratory 2321 11100 Johns Hopkins Rd. 2322 Laurel, MD 20723 2323 US 2325 Phone: +1 443 778 7423 2326 Email: Edward.Birrane@jhuapl.edu 2328 Alex White 2329 The Johns Hopkins University Applied 2330 Physics Laboratory 2331 11100 Johns Hopkins Rd. 2332 Laurel, MD 20723 2333 US 2335 Phone: +1 443 778 0845 2336 Email: Alex.White@jhuapl.edu 2338 Sarah Heiner 2339 The Johns Hopkins University Applied 2340 Physics Laboratory 2341 11100 Johns Hopkins Rd. 2342 Laurel, MD 20723 2343 US 2345 Phone: +1 240 592 3704 2346 Email: Sarah.Heiner@jhuapl.edu