idnits 2.17.1 draft-ietf-dtn-bpsec-default-sc-04.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 (April 11, 2021) is 1111 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) -- 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 (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking E. Birrane 3 Internet-Draft JHU/APL 4 Intended status: Standards Track April 11, 2021 5 Expires: October 13, 2021 7 BPSec Default Security Contexts 8 draft-ietf-dtn-bpsec-default-sc-04 10 Abstract 12 This document defines default integrity and confidentiality security 13 contexts that may be used with the Bundle Protocol Security Protocol 14 (BPSec) implementations. These security contexts are intended to be 15 used for both testing the interoperability of BPSec implementations 16 and for providing basic security operations when no other security 17 contexts are defined or otherwise required for a network. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 13, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 3 56 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 6 60 3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 6 61 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 7 62 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 7 63 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 8 65 3.6. Canonicalization Algorithms . . . . . . . . . . . . . . . 8 66 3.7. Processing . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.7.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 9 68 3.7.2. Keyed Hash Verification . . . . . . . . . . . . . . . 10 69 4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 11 70 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 14 74 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 14 75 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 15 76 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 15 77 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 16 78 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 16 80 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 17 81 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 17 82 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 18 83 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 19 84 4.7.1. Cipher text related calculations . . . . . . . . . . 19 85 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 20 86 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 20 87 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 20 88 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 22 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 5.1. Security Context Identifiers . . . . . . . . . . . . . . 23 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 92 6.1. Key Handling . . . . . . . . . . . . . . . . . . . . . . 24 93 6.2. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 6.3. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 24 95 7. Normative References . . . . . . . . . . . . . . . . . . . . 25 96 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Introduction 101 The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] 102 specification provides inter-bundle integrity and confidentiality 103 operations for networks deploying the Bundle Protocol (BP) 104 [I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry 105 security information produced under the auspices of some security 106 context. 108 This document defines two security contexts (one for an integrity 109 service and one for a confidentiality service) for populating BPSec 110 Block Integrity Blocks (BIBs) and Block Confidentiality Blocks 111 (BCBs). 113 These contexts generate information that MUST be encoded using the 114 CBOR specification documented in [RFC8949]. 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 3. Integrity Security Context BIB-HMAC-SHA2 126 3.1. Overview 128 The BIB-HMAC-SHA2 security context provides a keyed hash over a set 129 of plain text information. This context uses the Secure Hash 130 Algorithm 2 (SHA-2) discussed in [SHS] combined with the HMAC keyed 131 hash discussed in [HMAC]. The combination of HMAC and SHA-2 as the 132 integrity mechanism for this security context was selected for two 133 reasons: 135 1. The use of symmetric keys allows this security context to be used 136 in places where an asymmetric-key infrastructure (such as a 137 public key infrastructure) may be impractical. 139 2. The combination HMAC-SHA2 represents a well-supported and well- 140 understood integrity mechanism with multiple implementations 141 available. 143 BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the 144 supported length of the SHA-2 hash value. These variants correspond 145 to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in 146 [RFC8152] Table 7: HMAC Algorithm Values. The selection of which 147 variant is used by this context is provided as a security context 148 parameter. 150 The output of the HMAC MUST be equal to the size of the SHA2 hashing 151 function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits 152 for SHA-512. 154 The BIB-HMAC-SHA2 security context MUST have the security context 155 identifier specified in Section 5.1. 157 3.2. Scope 159 The scope of BIB-HMAC-SHA2 is the set of information used to produce 160 the plain text over which a keyed hash is calculated. This plain 161 text is termed the "Integrity Protected Plain Text" (IPPT). The 162 content of the IPPT is constructed as the concatenation of 163 information whose integrity is being preserved from the BIB-HMAC-SHA2 164 security source to its security acceptor. There are four types of 165 information that can be used in the generation of the IPPT, based on 166 how broadly the concept of integrity is being applied. These four 167 types of information, whether they are required, and why they are 168 important for integrity, are discussed as follows. 170 Security target contents 171 The contents of the block-type-specific data field of the 172 security target MUST be included in the IPPT. Including this 173 information protects the security target data and is considered 174 the minimal, required set of information for an integrity service 175 on the security target. 177 Primary block 178 The primary block identifies a bundle and, once created, the 179 contents of this block are immutable. Changes to the primary 180 block associated with the security target indicate that the 181 security target (and BIB) may no longer be in the correct bundle. 183 For example, if a security target and associated BIB are copied 184 from one bundle to another bundle, the BIB may still contain a 185 verifiable signature for the security target unless information 186 associated with the bundle primary block is included in the keyed 187 hash carried by the BIB. 189 Including this information in the IPPT protects the integrity of 190 the association of the security target with a specific bundle. 192 Security target other fields 193 The other fields of the security target include block 194 identification and processing information. Changing this 195 information changes how the security target is treated by nodes 196 in the network even when the "user data" of the security target 197 are otherwise unchanged. 199 For example, if the block processing control flags of a security 200 target are different at a security verifier than they were 201 originally set at the security source then the policy for 202 handling the security target has been modified. 204 Including this information in the IPPT protects the integrity of 205 the policy and identification of the security target data. 207 BIB other fields 208 The other fields of the BIB include block identification and 209 processing information. Changing this information changes how 210 the BIB is treated by nodes in the network, even when other 211 aspects of the BIB are unchanged. 213 For example, if the block processing control flags of the BIB are 214 different at a security verifier than they were originally set at 215 the security source, then the policy for handling the BIB has 216 been modified. 218 Including this information in the IPPT protects the integrity of 219 the policy and identification of the security service in the 220 bundle. 222 NOTE: The security context identifier and security context 223 parameters of the security block are not included in the IPPT 224 because these parameters, by definition, are required to verify 225 or accept the security service. Successful verification at 226 security verifiers and security acceptors implies that these 227 parameters were unchanged since being specified at the security 228 source. 230 The scope of the BIB-HMAC-SHA2 security context is configured using 231 an optional security context parameter. 233 3.3. Parameters 235 BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, 236 communicate key information, and define the scope of the IPPT. 238 3.3.1. SHA Variant 240 This optional parameter identifies which variant of the SHA-2 241 algorithm is to be used in the generation of the authentication code. 243 This value MUST be encoded as a CBOR unsigned integer. 245 Valid values for this parameter are as follows. 247 SHA Variant Parameter Values 249 +-------+-----------------------------------------------------------+ 250 | Value | Description | 251 +-------+-----------------------------------------------------------+ 252 | 5 | HMAC 256/256 as defined in [RFC8152] Table 7: HMAC | 253 | | Algorithm Values | 254 | 6 | HMAC 384/384 as defined in [RFC8152] Table 7: HMAC | 255 | | Algorithm Values | 256 | 7 | HMAC 512/512 as defined in [RFC8152] Table 7: HMAC | 257 | | Algorithm Values | 258 +-------+-----------------------------------------------------------+ 260 Table 1 262 When not provided, implementations SHOULD assume a value of 6 263 (indicating use of HMAC 384/384), unless an alternate default is 264 established by local security policy at the security source, 265 verifiers, or acceptor of this integrity service. 267 3.3.2. Wrapped Key 269 This optional parameter contains the output of the AES key wrap 270 authenticated encryption function (KW-AE) as defined in [AES-KW]. 271 Specifically, this parameter holds the cipher text produced when 272 running the KW-AE algorithm with the input string being the symmetric 273 HMAC key used to generate the security results present in the 274 security block. The value of this parameter is used as input to the 275 AES key wrap authenticated decryption function (KW-AD) at security 276 verifiers and security acceptors to determine the symmetric HMAC key 277 needed for the proper validation of the security results in the 278 security block. 280 This value MUST be encoded as a CBOR byte string. 282 If this parameter is not present then security verifiers and 283 acceptors MUST determine the proper key as a function of their local 284 BPSec policy and configuration. 286 3.3.3. Integrity Scope Flags 288 This optional parameter contains a series of flags that describe what 289 information is to be included with the block-type-specific data when 290 constructing the IPPT value. 292 This value MUST be represented as a CBOR unsigned integer, the value 293 of which MUST be processed as a bit field containing no more than 8 294 bits. 296 Bits in this field represent additional information to be included 297 when generating an integrity signature over the security target. 298 These bits are defined as follows. 300 - Bit 0 (the low-order bit, 0x1): Primary Block Flag. 302 - Bit 1 (0x02): Target Header Flag. 304 - Bit 2 (0x03): Security Header Flag. 306 - Bits 3-7 are reserved. 308 3.3.4. Enumerations 310 BIB-HMAC-SHA2 defines the following security context parameters. 312 BIB-HMAC-SHA2 Security Parameters 314 +----+-----------------------+--------------------+---------------+ 315 | Id | Name | CBOR Encoding Type | Default Value | 316 +----+-----------------------+--------------------+---------------+ 317 | 1 | SHA Variant | UINT | 6 | 318 | 2 | Wrapped Key | Byte String | NONE | 319 | 4 | Integrity Scope Flags | UINT | 0x7 | 320 +----+-----------------------+--------------------+---------------+ 322 Table 2 324 3.4. Results 326 BIB-HMAC-SHA2 defines the following security results. 328 BIB-HMAC-SHA2 Security Results 330 +--------+----------+-------------+---------------------------------+ 331 | Result | Result | CBOR | Description | 332 | Id | Name | Encoding | | 333 | | | Type | | 334 +--------+----------+-------------+---------------------------------+ 335 | 1 | Expected | byte string | The output of the HMAC | 336 | | HMAC | | calculation at the security | 337 | | | | source. | 338 +--------+----------+-------------+---------------------------------+ 340 Table 3 342 3.5. Key Considerations 344 HMAC keys used with this context MUST be symmetric and MUST have a 345 key length equal to the output of the HMAC. For this reason, HMAC 346 keys will be integer divisible by 8 bytes and special padding-aware 347 AES key wrap algorithms are not needed. 349 It is assumed that any security verifier or security acceptor 350 performing an integrity verification can determine the proper HMAC 351 key to be used. Potential sources of the HMAC key include (but are 352 not limited to) the following: 354 Pre-placed keys selected based on local policy. 356 Keys extracted from material carried in the BIB. 358 Session keys negotiated via a mechanism external to the BIB. 360 When an AES-KW wrapped key is present in a security block, it is 361 assumed that security verifiers and security acceptors can 362 independently determine the key encryption key (KEK) used in the 363 wrapping of the symmetric HMAC key. 365 As discussed in Section 6 and emphasized here, it is strongly 366 recommended that keys be protected once generated, both when they are 367 stored and when they are transmitted. 369 3.6. Canonicalization Algorithms 371 This section defines the canonicalization algorithm used to prepare 372 the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The 373 construction of the IPPT depends on the settings of the integrity 374 scope flags that may be provided as part of customizing the behavior 375 of this security context. 377 In all cases, the canonical form of any portion of an extension block 378 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 379 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 380 the canonical forms for extension blocks defined in 381 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 382 are represented in CBOR. 384 The IPPT is constructed using the following process. 386 1. The canonical form of the IPPT starts as the empty set with 387 length 0. 389 2. If the integrity scope parameter is present and the primary block 390 flag is set to 1, then a canonical form of the bundle's primary 391 block MUST be calculated and the result appended to the IPPT. 393 3. If the integrity scope parameter is present and the target header 394 flag is set to 1, then the canonical form of the block type code, 395 block number, and block processing control flags associated with 396 the security target MUST be calculated and, in that order, 397 appended to the IPPT. 399 4. If the integrity scope parameter is present and the security 400 header flag is set to 1, then the canonical form of the block 401 type code, block number, and block processing control flags 402 associated with the BIB MUST be calculated and, in that order, 403 appended to the IPPT. 405 5. The canonical form of the security target block-type-specific 406 data MUST be calculated and appended to the IPPT. 408 3.7. Processing 410 3.7.1. Keyed Hash Generation 412 During keyed hash generation, two inputs are prepared for the the 413 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 414 data items MUST be generated as follows. 416 The HMAC key MUST have the appropriate length as required by local 417 security policy. The key can be generated specifically for this 418 integrity service, given as part of local security policy, or 419 through some other key management mechanism as discussed in 420 Section 3.5. 422 Prior to the generation of the IPPT, if a CRC value is present for 423 the target block of the BIB, then that CRC value MUST be removed 424 from the target block. This involves both removing the CRC value 425 from the target block and setting the CRC Type field of the target 426 block to "no CRC is present." 428 Once CRC information is removed, the IPPT MUST be generated as 429 discussed in Section 3.6. 431 Upon successful hash generation the following actions MUST occur. 433 The keyed hash produced by the HMAC/SHA2 variant MUST be added as 434 a security result for the BIB representing the security operation 435 on this security target, as discussed in Section 3.4). 437 Finally, the BIB containing information about this security operation 438 MUST be updated as follows. These operations may occur in any order. 440 The security context identifier for the BIB MUST be set to the 441 context identifier for BIB-HMAC-SHA2. 443 Any local flags used to generate the IPPT SHOULD be placed in the 444 integrity scope flags security parameter for the BIB unless these 445 flags are expected to be correctly configured at security 446 verifiers and acceptors in the network. 448 The HMAC key MAY be wrapped using the NIST AES-KW algorithm and 449 the results of the wrapping added as the wrapped key security 450 parameter for the BIB. 452 The SHA variant used by this security context SHOULD be added as 453 the SHA variant security parameter for the BIB if it differs from 454 the default key length. Otherwise, this parameter MAY be omitted 455 if doing so provides a useful reduction in message sizes. 457 Problems encountered in the keyed hash generation MUST be processed 458 in accordance with local BPSec security policy. 460 3.7.2. Keyed Hash Verification 462 During keyed hash verification, the input of the security target and 463 a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. 465 During keyed hash verification, two inputs are prepared for the 466 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 467 data items MUST be generated as follows. 469 The HMAC key MUST be derived using the wrapped key security 470 parameter if such a parameter is included in the security context 471 parameters of the BIB. Otherwise, this key MUST be derived in 472 accordance with security policy at the verifying node as discussed 473 in Section 3.5. 475 The IPPT MUST be generated as discussed in Section 3.6 with the 476 value of integrity scope flags being taken from the integrity 477 scope flags security context parameter. If the integrity scope 478 flags parameter is not included in the security context parameters 479 then these flags MAY be derived from local security policy. 481 The calculated HMAC output MUST be compared to the expected HMAC 482 output encoded in the security results of the BIB for the security 483 target. If the calculated HMAC and expected HMAC are identical, the 484 verification MUST be considered a success. Otherwise, the 485 verification MUST be considered a failure. 487 If the verification fails or otherwise experiences an error, or if 488 any needed parameters are missing, then the verification MUST be 489 treated as failed and processed in accordance with local security 490 policy. 492 This security service is removed from the bundle at the security 493 acceptor as required by the BPSec specification. If the security 494 acceptor is not the bundle destination and if no other integrity 495 service is being applied to the target block, then a CRC MUST be 496 included for the target block. The CRC type, as determined by 497 policy, is set in the target block's CRC type field and the 498 corresponding CRC value is added as the CRC field for that block. 500 4. Security Context BCB-AES-GCM 502 4.1. Overview 504 The BCB-AES-GCM security context replaces the block-type-specific 505 data field of its security target with cipher text generated using 506 the Advanced Encryption Standard (AES) cipher operating in Galois/ 507 Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the 508 cipher suite for this confidentiality mechanism for several reasons: 510 1. The selection of a symmetric-key cipher suite allows for 511 relatively smaller keys than asymmetric-key cipher suites. 513 2. The selection of a symmetric-key cipher suite allows this 514 security context to be used in places where an asymmetric-key 515 infrastructure (such as a public key infrastructure) may be 516 impractical. 518 3. The use of the Galois/Counter Mode produces cipher-text with the 519 same size as the plain text making the replacement of target 520 block information easier as length fields do not need to be 521 changed. 523 4. The AES-GCM cipher suite provides authenticated encryption, as 524 required by the BPSec protocol. 526 Additionally, the BCB-AES-GCM security context generates an 527 authentication tag based on the plain text value of the block-type- 528 specific data and other additional authenticated data that may be 529 specified via parameters to this security context. 531 This security context supports two variants of AES-GCM, based on the 532 supported length of the symmetric key. These variants correspond to 533 A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value 534 for AES-GCM. 536 The BCB-AES-GCM security context MUST have the security context 537 identifier specified in Section 5.1. 539 4.2. Scope 541 There are two scopes associated with BCB-AES-GCM: the scope of the 542 confidentiality service and the scope of the authentication service. 543 The first defines the set of information provided to the AES-GCM 544 cipher for the purpose of producing cipher text. The second defines 545 the set of information used to generate an authentication tag. 547 The scope of the confidentiality service defines the set of 548 information provided to the AES-GCM cipher for the purpose of 549 producing cipher text. This MUST be the full set of plain text 550 contained in the block-type-specific data field of the security 551 target. 553 The scope of the authentication service defines the set of 554 information used to generate an authentication tag carried with the 555 security block. This information includes the data included in the 556 confidentiality service and MAY include other information (additional 557 authenticated data), as follows. 559 Primary block 560 The primary block identifies a bundle and, once created, the 561 contents of this block are immutable. Changes to the primary 562 block associated with the security target indicate that the 563 security target (and BCB) may no longer be in the correct bundle. 565 For example, if a security target and associated BCB are copied 566 from one bundle to another bundle, the BCB may still be able to 567 decrypt the security target even though these blocks were never 568 intended to exist in the copied-to bundle. 570 Including this information as part of additional authenticated 571 data ensures that security target (and security block) appear in 572 the same bundle at the time of decryption as at the time of 573 encryption. 575 Security target other fields 576 The other fields of the security target include block 577 identification and processing information. Changing this 578 information changes how the security target is treated by nodes 579 in the network even when the "user data" of the security target 580 are otherwise unchanged. 582 For example, if the block processing control flags of a security 583 target are different at a security verifier than they were 584 originally set at the security source then the policy for 585 handling the security target has been modified. 587 Including this information as part of additional authenticated 588 data ensures that the cipher text in the security target will not 589 be used with a different set of block policy than originally set 590 at the time of encryption. 592 BCB other fields 593 The other fields of the BCB include block identification and 594 processing information. Changing this information changes how 595 the BCB is treated by nodes in the network, even when other 596 aspects of the BCB are unchanged. 598 For example, if the block processing control flags of the BCB are 599 different at a security acceptor than they were originally set at 600 the security source then the policy for handling the BCB has been 601 modified. 603 Including this information as part of additional authenticated 604 data ensures that the policy and identification of the security 605 service in the bundle has not changed. 607 NOTE: The security context identifier and security context 608 parameters of the security block are not included as additional 609 authenticated data because these parameters, by definition, are 610 those needed to verify or accept the security service. 611 Therefore, it is expected that changes to these values would 612 result in failures at security verifiers and security acceptors. 614 The scope of the BCB-AES-GCM security context is configured using an 615 optional security context parameter. 617 4.3. Parameters 619 BCB-AES-GCM can be parameterized to specify the AES variant, 620 initialization vector, key information, and identify additional 621 authenticated data. 623 4.3.1. Initialization Vector (IV) 625 This optional parameter identifies the initialization vector (IV) 626 used to initialize the AES-GCM cipher. 628 The length of the initialization vector, prior to any CBOR encoding, 629 MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used 630 unless local security policy requires a different length. 632 This value MUST be encoded as a CBOR byte string. 634 The initialization vector may have any value with the caveat that a 635 value MUST NOT be re-used for multiple encryptions using the same 636 encryption key. This value MAY be re-used when encrypting with 637 different keys. For example, if each encryption operation using BCB- 638 AES-GCM uses a newly generated key, then the same IV may be reused. 640 4.3.2. AES Variant 642 This optional parameter identifies the AES variant being used for the 643 AES-GCM encryption, where the variant is identified by the length of 644 key used. 646 This value MUST be encoded as a CBOR unsigned integer. 648 Valid values for this parameter are as follows. 650 AES Variant Parameter Values 652 +-------+-----------------------------------------------------------+ 653 | Value | Description | 654 +-------+-----------------------------------------------------------+ 655 | 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values | 656 | | for AES-GCM | 657 | 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values | 658 | | for AES-GCM | 659 +-------+-----------------------------------------------------------+ 660 When not provided, implementations SHOULD assume a value of 3 661 (indicating use of A256GCM), unless an alternate default is 662 established by local security policy at the security source, 663 verifier, or acceptor of this integrity service. 665 Regardless of the variant, the generated authentication tag MUST 666 always be 128 bits. 668 4.3.3. Wrapped Key 670 This optional parameter contains the output of the AES key wrap 671 authenticated encryption function (KW-AE) as defined in [AES-KW]. 672 Specifically, this parameter holds the cipher text produced when 673 running the KW-AE algorithm with the input string being the symmetric 674 AES key used to generate the security results present in the security 675 block. The value of this parameter is used as input to the AES key 676 wrap authenticated decryption function (KW-AD) at security verifiers 677 and security acceptors to determine the symmetric AES key needed for 678 the proper decryption of the security results in the security block. 680 This value MUST be encoded as a CBOR byte string. 682 If this parameter is not present then security verifiers and 683 acceptors MUST determine the proper key as a function of their local 684 BPSec policy and configuration. 686 4.3.4. AAD Scope Flags 688 This optional parameter contains a series of flags that describe what 689 information is to be included with the block-type-specific data of 690 the security target as part of additional authenticated data (AAD). 692 This value MUST be represented as a CBOR unsigned integer, the value 693 of which MUST be processed as a bit field containing no more than 8 694 bits. 696 Bits in this field represent additional information to be included 697 when generating an integrity signature over the security target. 698 These bits are defined as follows. 700 - Bit 0 (the low-order bit, 0x1): Primary Block Flag. 702 - Bit 1 (0x02): Target Header Flag. 704 - Bit 2 (0x03): Security Header Flag. 706 - Bits 3-7 are reserved. 708 4.3.5. Enumerations 710 BCB-AES-GCM defines the following security context parameters. 712 BCB-AES-GCM Security Parameters 714 +----+-----------------------+--------------------+---------------+ 715 | Id | Name | CBOR Encoding Type | Default Value | 716 +----+-----------------------+--------------------+---------------+ 717 | 1 | Initialization Vector | Byte String | NONE | 718 | 2 | AES Variant | UINT | 3 | 719 | 3 | Wrapped Key | Byte String | NONE | 720 | 4 | AAD Scope Flags | UINT | 0x7 | 721 +----+-----------------------+--------------------+---------------+ 723 Table 4 725 4.4. Results 727 The BCB-AES-GCM security context produces a single security result 728 carried in the security block: the authentication tag. 730 NOTES: 732 The cipher text generated by the cipher suite is not considered a 733 security result as it is stored in the block-type-specific data 734 field of the security target block. When operating in GCM mode, 735 AES produces cipher text of the same size as its plain text and, 736 therefore, no additional logic is required to handle padding or 737 overflow caused by the encryption in most cases (see below). 739 If the generated cipher text contains the authentication tag and 740 the tag can be separated from the cipher text then the tag MUST be 741 separated and stored in the authentication tag security result 742 field. 744 If the generated cipher text contains the authentication tag and 745 the tag cannot be separated from the cipher text then the tag MUST 746 NOT be included in the authentication tag security result field. 747 Instead the security target block MUST be resized to accommodate 748 the additional 128 bits of authentication tag included in the 749 generated cipher text. 751 4.4.1. Authentication Tag 753 The authentication tag is generated by the cipher suite over the 754 security target plain text input to the cipher suite as combined with 755 any optional additional authenticated data. This tag is used to 756 ensure that the plain text (and important information associated with 757 the plain text) is authenticated prior to decryption. 759 If the authentication tag is included in the cipher text placed in 760 the security target block-type-specific data field, then this 761 security result MUST NOT be included in the BCB for that security 762 target. 764 The length of the authentication tag, prior to any CBOR encoding, 765 MUST be 128 bits. 767 This value MUST be encoded as a CBOR byte string. 769 4.4.2. Enumerations 771 BCB-AES-GCM defines the following security context parameters. 773 BCB-AES-GCM Security Results 775 +-----------+--------------------+--------------------+ 776 | Result Id | Result Name | CBOR Encoding Type | 777 +-----------+--------------------+--------------------+ 778 | 1 | Authentication Tag | Byte String | 779 +-----------+--------------------+--------------------+ 781 Table 5 783 4.5. Key Considerations 785 Keys used with this context MUST be symmetric and MUST have a key 786 length equal to the key length defined in the security context 787 parameters or as defined by local security policy at security 788 verifiers and acceptors. For this reason, content-encrypting keys 789 will be integer divisible by 8 bytes and special padding-aware AES 790 key wrap algorithms are not needed. 792 It is assumed that any security verifier or security acceptor can 793 determine the proper key to be used. Potential sources of the key 794 include (but are not limited to) the following. 796 Pre-placed keys selected based on local policy. 798 Keys extracted from material carried in the BCB. 800 Session keys negotiated via a mechanism external to the BCB. 802 When an AES-KW wrapped key is present in a security block, it is 803 assumed that security verifiers and security acceptors can 804 independently determine the key encryption key (KEK) used in the 805 wrapping of the symmetric AES content-encrypting key. 807 The security provided by block ciphers is reduced as more data is 808 processed with the same key. The total number of bytes processed 809 with a single key for AES-GCM is recommended to be less than 2^64, as 810 described in Appendix B of [AES-GCM]. 812 As discussed in Section 6 and emphasized here, it is strongly 813 recommended that keys be protected once generated, both when they are 814 stored and when they are transmitted. 816 4.6. GCM Considerations 818 The GCM cryptographic mode of AES has specific requirements that MUST 819 be followed by implementers for the secure function of the BCB-AES- 820 GCM security context. While these requirements are well documented 821 in [AES-GCM], some of them are repeated here for emphasis. 823 The pairing of an IV and a security key MUST be unique. An IV 824 MUST NOT be used with a security key more than one time. If an IV 825 and key pair are repeated then the GCM implementation may be 826 vulnerable to forgery attacks. More information regarding the 827 importance of the uniqueness of the IV value can be found in 828 Appendix A of [AES-GCM]. 830 While any tag-based authentication mechanism has some likelihood 831 of being forged, this probability is increased when using AES-GCM. 832 In particular, short tag lengths combined with very long messages 833 SHOULD be avoided when using this mode. The BCB-AES-GCM security 834 context requires the use of 128-bit authentication tags at all 835 times. Concerns relating to the size of authentication tags is 836 discussed in Appendices B and C of [AES-GCM]. 838 As discussed in Appendix B of [AES-GCM], implementations SHOULD 839 limit the number of unsuccessful verification attempts for each 840 key to reduce the likelihood of guessing tag values. 842 As discussed in the Security Considerations section of 843 [I-D.ietf-dtn-bpsec], delay-tolerant networks may have a higher 844 occurrence of replay attacks due to the store-and-forward nature 845 of the network. Because GCM has no inherent replay attack 846 protection, implementors SHOULD attempt to detect replay attacks 847 by using mechanisms such as those described in Appendix D of 848 [AES-GCM]. 850 4.7. Canonicalization Algorithms 852 This section defines the canonicalization algorithms used to prepare 853 the inputs used to generate both the cipher text and the 854 authentication tag. 856 In all cases, the canonical form of any portion of an extension block 857 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 858 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 859 the canonical forms for extension blocks defined in 860 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 861 are represented in CBOR. 863 4.7.1. Cipher text related calculations 865 The plain text used during encryption MUST be calculated as the 866 single, definite-length CBOR byte string representing the block-type- 867 specific data field of the security target excluding the CBOR byte 868 string identifying byte and optional CBOR byte string length field. 870 For example, consider the following two CBOR byte strings and the 871 plain text that would be extracted from them. 873 CBOR Byte String Examples 875 +------------------------------+---------+--------------------------+ 876 | CBOR Byte String (Hex) | CBOR | Plain Text Part (Hex) | 877 | | Part | | 878 | | (Hex) | | 879 +------------------------------+---------+--------------------------+ 880 | 18ED | 18 | ED | 881 +------------------------------+---------+--------------------------+ 882 | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | 883 +------------------------------+---------+--------------------------+ 885 Table 6 887 Similarly, the cipher text used during decryption MUST be calculated 888 as the single, definite-length CBOR byte string representing the 889 block-type-specific data field excluding the CBOR byte string 890 identifying byte and optional CBOR byte string length field. 892 All other fields of the security target (such as the block type code, 893 block number, block processing control flags, or any CRC information) 894 MUST NOT be considered as part of encryption or decryption. 896 4.7.2. Additional Authenticated Data 898 The construction of additional authenticated data depends on the AAD 899 scope flags that may be provided as part of customizing the behavior 900 of this security context. 902 The canonical form of the AAD input to the BCB-AES-GCM mechanism is 903 constructed using the following process. This process MUST be 904 followed when generating AAD for either encryption or decryption. 906 1. The canonical form of the AAD starts as the empty set with length 907 0. 909 2. If the AAD scope parameter is present and the primary block flag 910 is set to 1, then a canonical form of the bundle's primary block 911 MUST be calculated and the result appended to the AAD. 913 3. If the AAD scope parameter is present and the target header flag 914 is set to 1, then the canonical form of the block type code, 915 block number, and block processing control flags associated with 916 the security target MUST be calculated and, in that order, 917 appended to the AAD. 919 4. If the AAD scope parameter is present and the security header 920 flag is set to 1, then the canonical form of the block type code, 921 block number, and block processing control flags associated with 922 the BIB MUST be calculated and, in that order, appended to the 923 AAD. 925 If, after this process, the AAD remains at length 0, then no AAD 926 exists to be input to the cipher suite. 928 4.8. Processing 930 4.8.1. Encryption 932 During encryption, four inputs are prepared for input to the AES/GCM 933 cipher: the encryption key, the IV, the security target plain text to 934 be encrypted, and any additional authenticated data. These data 935 items MUST be generated as follows. 937 Prior to encryption, if a CRC value is present for the target block, 938 then that CRC value MUST be removed. This requires removing the CRC 939 field from the target block and setting the CRC type field of the 940 target block to "no CRC is present." 942 The encryption key MUST have the appropriate length as required by 943 local security policy. The key may be generated specifically for 944 this encryption, given as part of local security policy, or 945 through some other key management mechanism as discussed in 946 Section 4.5. 948 The IV selected MUST be of the appropriate length. Because 949 replaying an IV in counter mode voids the confidentiality of all 950 messages encrypted with said IV, this context also requires a 951 unique IV for every encryption performed with the same key. This 952 means the same key and IV combination MUST NOT be used more than 953 once. 955 The security target plain text for encryption MUST be generated as 956 discussed in Section 4.7.1. 958 Additional authenticated data, if present, MUST be generated as 959 discussed in Section 4.7.2 with the value of AAD scope flags being 960 taken from local security policy. 962 Upon successful encryption the following actions MUST occur. 964 The cipher text produced by AES/GCM MUST replace the bytes used to 965 define the plain text in the security target block's block-type- 966 specific data field. The block length of the security target MUST 967 be updated if the generated cipher text is larger than the plain 968 text (which can occur when the authentication tag is included in 969 the cipher text calculation, as discussed in Section 4.4). 971 The authentication tag calculated by the AES/GCM cipher MUST be 972 added as a security result for the security target in the BCB 973 holding results for this security operation. 975 Cases where the authentication tag is generated as part of the 976 cipher text MUST be processed as described in Section 4.4. 978 Finally, the BCB containing information about this security operation 979 MUST be updated as follows. These operations may occur in any order. 981 The security context identifier for the BCB MUST be set to the 982 context identifier for BCB-AES-GCM. 984 The IV input to the cipher MUST be added as the IV security 985 parameter for the BCB. 987 Any local flags used to generated AAD for this cipher MUST be 988 added as the AAD scope flags security parameter for the BCB. 990 The encryption key MAY be wrapped using the NIST AES-KW algorithm 991 and the results of the wrapping added as the wrapped key security 992 parameter for the BCB. 994 The key length used by this security context MUST be considered 995 when setting the AES variant security parameter for the BCB if it 996 differs from the default AES variant. Otherwise, the AES variant 997 MAY be omitted if doing so provides a useful reduction in message 998 sizes. 1000 Problems encountered in the encryption MUST be processed in 1001 accordance with local security policy. This MAY include restoring a 1002 CRC value removed from the target block prior to encryption, if the 1003 target block is allowed to be transmitted after an encryption error. 1005 4.8.2. Decryption 1007 During encryption, five inputs are prepared for input to the AES/GCM 1008 cipher: the decryption key, the IV, the security target cipher text 1009 to be decrypted, any additional authenticated data, and the 1010 authentication tag generated from the original encryption. These 1011 data items MUST be generated as follows. 1013 The decryption key MUST be derived using the wrapped key security 1014 parameter if such a parameter is included in the security context 1015 parameters of the BCB. Otherwise this key MUST be derived in 1016 accordance with local security policy at the decrypting node as 1017 discussed in Section 4.5. 1019 The IV MUST be set to the value of the IV security parameter 1020 included in the BCB. If the IV parameter is not included as a 1021 security parameter, an IV MAY be derived as a function of local 1022 security policy and other BCB contents or a lack of an IV security 1023 parameter in the BCB MAY be treated as an error by the decrypting 1024 node. 1026 The security target cipher text for decryption MUST be generated 1027 as discussed in Section 4.7.1. 1029 Additional authenticated data, if present, MUST be generated as 1030 discussed in Section 4.7.2 with the value of AAD scope flags being 1031 taken from the AAD scope flags security context parameter. If the 1032 AAD scope flags parameter is not included in the security context 1033 parameters then these flags MAY be derived from local security 1034 policy in cases where the set of such flags is determinable in the 1035 network. 1037 The authentication tag MUST be present in the BCB security context 1038 parameters field if additional authenticated data are defined for 1039 the BCB (either in the AAD scope flags parameter or as specified 1040 by local policy). This tag MUST be 128 bits in length. 1042 Upon successful decryption the following actions MUST occur. 1044 The plain text produced by AES/GCM MUST replace the bytes used to 1045 define the cipher text in the security target block's block-type- 1046 specific data field. Any changes to the security target block 1047 length field MUST be corrected in cases where the plain text has a 1048 different length than the replaced cipher text. 1050 If the security acceptor is not the bundle destination and if no 1051 other integrity or confidentiality service is being applied to the 1052 target block, then a CRC MUST be included for the target block. The 1053 CRC type, as determined by policy, is set in the target block's CRC 1054 type field and the corresponding CRC value is added as the CRC field 1055 for that block. 1057 If the cipher text fails to authenticate, if any needed parameters 1058 are missing, or if there are other problems in the decryption then 1059 the decryption MUST be treated as failed and processed in accordance 1060 with local security policy. 1062 5. IANA Considerations 1064 5.1. Security Context Identifiers 1066 This specification allocates two security context identifiers from 1067 the "BPSec Security Context Identifier" registry defined in 1068 [I-D.ietf-dtn-bpsec]. 1070 Additional Entries for the BPSec Security Context Identifiers 1071 Registry: 1073 +-------+---------------+---------------+ 1074 | Value | Description | Reference | 1075 +-------+---------------+---------------+ 1076 | TBA | BIB-HMAC-SHA2 | This document | 1077 | TBA | BCB-AES-GCM | This document | 1078 +-------+---------------+---------------+ 1080 Table 7 1082 6. Security Considerations 1084 Security considerations specific to a single security context are 1085 provided in the description of that context. This section discusses 1086 security considerations that should be evaluated by implementers of 1087 any security context described in this document. Considerations may 1088 also be found in documents listed as normative references and they 1089 should also be reviewed by security context implementors. 1091 6.1. Key Handling 1093 In addition to the key considerations listed in each security 1094 context, the following also apply to the generation, transmission, 1095 and use of keys associated with all of the security contexts defined 1096 in this document. 1098 It is strongly RECOMMENDED that implementations protect keys both 1099 when they are stored and when they are transmitted. 1101 In the event that a key is compromised, any security operations 1102 using a security context associated with that key SHOULD also be 1103 considered compromised. This means that the BIB-HMAC-SHA2 1104 security context SHOULD NOT provide integrity when used with a 1105 compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality 1106 when used with a compromised key. 1108 The same key SHOULD NOT be used for different algorithms as doing 1109 so may leak information about the key. 1111 Unless otherwise specified, the security contexts provided in this 1112 document do not mandate any specific method for key exchange, 1113 encryption, or encapsulation. The derivation of an appropriate 1114 key is considered separate from the application of the 1115 authenticated confidentiality service provided by this context. 1117 6.2. AES GCM 1119 There are a significant number of considerations related to the use 1120 of the GCM mode of AES to provide a confidentiality service. These 1121 considerations are provided in Section 4.6 as part of the 1122 documentation of the BCB-AES-GCM security context. 1124 6.3. Bundle Fragmentation 1126 Bundle fragmentation may prevent security services in a bundle from 1127 being verified after a bundle is fragmented and before the bundle is 1128 re-assembled. Examples of potential issues include the following. 1130 If a security block and its security target do not exist in the 1131 same fragment, then the security block cannot be processed until 1132 the bundle is re-assembled. If a fragment includes an encrypted 1133 target block, but not its BCB, then a receiving bundle processing 1134 agent (BPA) will not know that the target block has been 1135 encrypted. 1137 If a security block is cryptographically bound to a bundle, it 1138 cannot be processed even if the security block and target both 1139 coexist in the fragment. This is because fragments have different 1140 primary blocks than the original bundle. 1142 If security blocks and their target blocks are repeated in 1143 multiple fragments, policy must determine how to deal with issues 1144 where a security operation verifies in one fragment but fails in 1145 another fragment. This may happen, for example, if a BIB block 1146 becomes corrupted in one fragment but not in another fragment. 1148 Implementors should consider how security blocks are processed when a 1149 BPA fragments a received bundle. For example, security blocks and 1150 their targets could be placed in the same fragment if the security 1151 block is not otherwise cryptographically bound to the bundle being 1152 fragmented. Alternatively, if security blocks are cryptographically 1153 bound to a bundle, then a fragmenting BPA should consider 1154 encapsulating the bundle first and then fragmenting the encapsulating 1155 bundle. 1157 7. Normative References 1159 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 1160 Recommendation for Block Cipher Modes of Operation: 1161 Galois/Counter Mode (GCM) and GMAC.", November 2007. 1163 [AES-KW] Dworkin, M., "NIST Special Publication 800-38F: 1164 Recommendation for Block Cipher Modes of Operation: 1165 Methods for Key Wrapping.", December 2012. 1167 [HMAC] US NIST, "The Keyed-Hash Message Authentication Code 1168 (HMAC).", FIPS-198-1, Gaithersburg, MD, USA, July 2008. 1170 https://csrc.nist.gov/publications/detail/fips/198/1/final 1172 [I-D.ietf-dtn-bpbis] 1173 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1174 Version 7", draft-ietf-dtn-bpbis-31 (work in progress), 1175 January 2021. 1177 [I-D.ietf-dtn-bpsec] 1178 Birrane, E. and K. McKeever, "Bundle Protocol Security 1179 Specification", draft-ietf-dtn-bpsec-27 (work in 1180 progress), February 2021. 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, 1184 DOI 10.17487/RFC2119, March 1997, 1185 . 1187 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1188 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1189 . 1191 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1192 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1193 May 2017, . 1195 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1196 Representation (CBOR)", STD 94, RFC 8949, 1197 DOI 10.17487/RFC8949, December 2020, 1198 . 1200 [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- 1201 180-4, Gaithersburg, MD, USA, August 2015. 1203 https://csrc.nist.gov/publications/detail/fips/180/4/final 1205 Appendix A. Acknowledgements 1207 The following participants contributed useful review and analysis of 1208 these security contexts: Amy Alford and Sarah Heiner of the Johns 1209 Hopkins University Applied Physics Laboratory. 1211 Author's Address 1213 Edward J. Birrane, III 1214 The Johns Hopkins University Applied 1215 Physics Laboratory 1216 11100 Johns Hopkins Rd. 1217 Laurel, MD 20723 1218 US 1220 Phone: +1 443 778 7423 1221 Email: Edward.Birrane@jhuapl.edu