idnits 2.17.1 draft-ietf-dtn-bpsec-default-sc-02.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 (February 21, 2021) is 1158 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. '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 (==), 4 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 February 21, 2021 5 Expires: August 25, 2021 7 BPSec Default Security Contexts 8 draft-ietf-dtn-bpsec-default-sc-02 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 may be used for 15 both testing the interoperability of BPSec implementations and for 16 providing basic security operations when no other security contexts 17 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 August 25, 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 . . . . . . . . . . . . . . . . . . . . . 5 60 3.3.2. Encapsulated Key . . . . . . . . . . . . . . . . . . 6 61 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 6 62 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 7 63 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 13 74 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 13 75 4.3.3. Encapsulated Key . . . . . . . . . . . . . . . . . . 14 76 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 14 77 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 15 78 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 16 80 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 16 81 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 16 82 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 17 83 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 18 84 4.7.1. Cipher text related calculations . . . . . . . . . . 18 85 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 19 86 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 19 87 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 19 88 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 21 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 5.1. Security Context Identifiers . . . . . . . . . . . . . . 22 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 6.1. Key Handling . . . . . . . . . . . . . . . . . . . . . . 23 93 6.2. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 6.3. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 23 95 7. Normative References . . . . . . . . . . . . . . . . . . . . 24 96 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 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]. 133 BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the 134 supported length of the SHA-2 hash value. These variants correspond 135 to HMAC256-SHA256, HMAC384-SHA384, and HMAC512-SHA512 as defined in 136 [RFC8152] Table 7: HMAC Algorithm Values. The selection of which 137 variant is used by this context is provided as a security context 138 parameter. 140 The output of the HMAC shall be equal to the size of the SHA2 hashing 141 function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits 142 for SHA-512. 144 The BIB-HMAC-SHA2 security context shall have the Security Context ID 145 specified in Section 5.1. 147 3.2. Scope 149 The scope of BIB-HMAC-SHA2 refers to the set of information used to 150 produce the plain text over which a keyed hash is calculated. This 151 plain text is termed the "Integrity Protected Plain Text" (IPPT). 152 The contents of the IPPT is constructed as the concatenation of 153 information whose integrity is being preserved from the BIB-HMAC-SHA2 154 security source to its security acceptor. There are four types of 155 information that can be used in the generation of the IPPT, based on 156 how broadly the concept of integrity is being applied. These four 157 types of information, whether they are required, and why they are 158 important for integrity, are discussed as follows. 160 Security target contents 161 The contents of the block-type-specific data field of the 162 security target MUST be included in the IPPT. Including this 163 information protects the security target data and is considered 164 the minimal, required set of information for an integrity service 165 on the security target. 167 Primary block 168 The primary block identifies a bundle and, once created, the 169 contents of this block are immutable. Changes to the primary 170 block associated with the security target indicate that the 171 security target (and BIB) may no longer be in the correct bundle. 173 For example, if a security target and associated BIB are copied 174 from one bundle to another bundle, the BIB may still contain a 175 verifiable signature for the security target unless information 176 associated with the bundle primary block is included in the keyed 177 hash carried by the BIB. 179 Including this information in the IPPT protects the integrity of 180 the association of the security target with a specific bundle. 182 Security target other fields 183 The other fields of the security target include block 184 identification and processing information. Changing this 185 information changes how the security target is treated by nodes 186 in the network even when the "user data" of the security target 187 are otherwise unchanged. 189 For example, if the block processing control flags of a security 190 target are different at a security verifier than they were 191 originally set at the security source then the policy for 192 handling the security target has been modified. 194 Including this information in the IPPT protects the integrity of 195 the policy and identification of the security target data. 197 BIB other fields 198 The other fields of the BIB carrying the security result for this 199 security context security block include block identification and 200 processing information. Changing this information changes how 201 the BIB is treated by nodes in the network, even when other 202 aspects of the BIB are unchanged. 204 For example, if the block processing control flags of the BIB are 205 different at a security verifier than they were originally set at 206 the security source, then the policy for handling the BIB has 207 been modified. 209 Including this information in the IPPT protects the integrity of 210 the policy and identification of the security service in the 211 bundle. 213 NOTE: The security context identifier and security context 214 parameters of the security block are not included in the IPPT 215 because these parameters, by definition, are required to verify 216 or accept the security service. Successful verification at 217 security verifiers and security acceptors implies that these 218 parameters were unchanged since being specified at the security 219 source. 221 The scope of the BIB-HMAC-SHA2 security context is configured using 222 an optional security context parameter. 224 3.3. Parameters 226 BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, 227 communicate key information, and define the scope of the IPPT. 229 3.3.1. SHA Variant 231 This optional parameter identifies which variant of the SHA-2 232 algorithm is to be used in the generation of the authentication code. 234 This value MUST be encoded as a CBOR unsigned integer. 236 Valid values for this parameter are as follows. 238 SHA Variant Parameter Values 240 +-------+-----------------------------------------------------------+ 241 | Value | Description | 242 +-------+-----------------------------------------------------------+ 243 | 5 | HMAC256/SHA256 as defined in [RFC8152] Table 7: HMAC | 244 | | Algorithm Values | 245 | 6 | HMAC384/SHA384 as defined in [RFC8152] Table 7: HMAC | 246 | | Algorithm Values | 247 | 7 | HMAC512/SHA512 as defined in [RFC8152] Table 7: HMAC | 248 | | Algorithm Values | 249 +-------+-----------------------------------------------------------+ 251 Table 1 253 When not provided, implementations SHOULD assume a value of 6 254 (indicating use of HMAC384/SHA384), unless an alternate default is 255 established by security policy at the security source, verifier, or 256 acceptor of this integrity service. 258 3.3.2. Encapsulated Key 260 This optional parameter contains the output of a Key Encapsulation 261 Mechanism (KEM) run at the security source of this security context. 263 This value MUST be encoded as a CBOR byte string. 265 If provided, this information is used to retrieve the symmetric HMAC 266 key used in the generation of security results for this security 267 context. If not provided, security verifiers and acceptors MUST 268 determine the proper key as a function of their local BPSec policy 269 and configuration, as discussed in Section 3.5. 271 3.3.3. Integrity Scope Flags 273 This optional parameter contains a series of flags that describe what 274 information is to be included with the block-type-specific data when 275 constructing the IPPT value. 277 This value MUST be represented as a CBOR unsigned integer, the value 278 of which MUST be processed as a bit field containing no more than 16 279 bits. 281 Bits in this field represent additional information to be included 282 when generating an integrity signature over the security target. 283 These bits are defined as follows. 285 - Bit 0 (the low-order bit, 0x1): Primary Block Flag. 287 - Bit 1 (0x02): Target Header Flag. 289 - Bit 2 (0x03): Security Header Flag. 291 - Bits 3-7 are reserved. 293 - Bits 8-15 are unassigned. 295 3.3.4. Enumerations 297 BIB-HMAC-SHA2 defines the following security context parameters. 299 BIB-HMAC-SHA2 Security Parameters 301 +----+-----------------------+--------------------+---------------+ 302 | Id | Name | CBOR Encoding Type | Default Value | 303 +----+-----------------------+--------------------+---------------+ 304 | 1 | SHA Variant | UINT | 256 | 305 | 2 | Encapsulated Key | Byte String | NONE | 306 | 3 | Integrity Scope Flags | UINT | 0x7 | 307 +----+-----------------------+--------------------+---------------+ 309 Table 2 311 3.4. Results 313 BIB-HMAC-SHA2 defines the following security results. 315 BIB-HMAC-SHA2 Security Results 317 +--------+----------+-------------+---------------------------------+ 318 | Result | Result | CBOR | Description | 319 | Id | Name | Encoding | | 320 | | | Type | | 321 +--------+----------+-------------+---------------------------------+ 322 | 1 | Expected | byte string | The output of the HMAC | 323 | | HMAC | | calculation at the security | 324 | | | | source. | 325 +--------+----------+-------------+---------------------------------+ 327 Table 3 329 3.5. Key Considerations 331 BIB-HMAC-SHA2 does not define or otherwise mandate any method for key 332 exchange, encryption, or encapsulation. The derivation of an 333 appropriate key for use in the integrity service is considered 334 separate from the application of the integrity service for this 335 context. 337 HMAC keys used with this context MUST be symmetric and MUST have a 338 key length equal to the output of the HMAC. 340 It is assumed that any security verifier or security acceptor 341 performing an integrity verification can determine the proper HMAC 342 key to be used. Potential sources of the HMAC key include (but are 343 not limited to) the following: 345 Pre-placed keys selected based on local policy. 347 Keys extracted from encapsulated key material carried in the BIB. 349 Session keys negotiated via a mechanism external to the BIB. 351 As discussed in Section 6 and emphasized here, it is strongly 352 recommended that keys be protected once generated, both when they are 353 stored and when they are transmitted. 355 3.6. Canonicalization Algorithms 357 This section defines the canonicalization algorithm used to prepare 358 the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The 359 construction of the IPPT depends on the settings of the Integrity 360 Scope Flags that may be provided as part of customizing the behavior 361 of this security context. 363 In all cases, the canonical form of any portion of an extension block 364 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 365 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 366 the canonical forms for extension blocks defined in 367 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 368 are represented in CBOR. 370 The IPPT is constructed using the following process. 372 1. The canonical form of the IPPT starts as the empty set with 373 length 0. 375 2. If the Integrity Scope parameter is present and the Primary Block 376 Flag is set to 1, then a canonical form of the bundle's primary 377 block MUST be calculated and the result appended to the IPPT. 379 3. If the Integrity Scope parameter is present and the Security 380 Header flag is set to 1, then the canonical form of the Block 381 Type Code, Block Number, and Block Processing Control Flags 382 associated with the BIB MUST be calculated and, in that order, 383 appended to the IPPT. 385 4. If the Integrity Scope parameter is present and the Target Header 386 flag is set to 1, then the canonical form of the Block Type Code, 387 Block Number, and Block Processing Control Flags associated with 388 the security target MUST be calculated and, in that order, 389 appended to the IPPT. 391 5. The canonical form of the security target block-type-specific 392 data MUST be calculated and appended to the IPPT. 394 3.7. Processing 396 3.7.1. Keyed Hash Generation 398 During keyed hash generation, two inputs are prepared for the the 399 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 400 data items MUST be generated as follows. 402 The HMAC key MUST have the appropriate length as required by local 403 security policy. The key may be generated specifically for this 404 integrity service, given as part of local security policy, or 405 through some other key management mechanism as discussed in 406 Section 3.5. 408 Prior to the generation of the IPPT, if a CRC value is present for 409 the target block of the BIB, then that CRC value MUST be removed 410 from the target block. This involves both removing the CRC value 411 from the target block and setting the CRC Type field of the target 412 block to "no CRC is present." 414 Once CRC information is removed, the IPPT MUST be generated as 415 discussed in Section 3.6. 417 Upon successful hash generation the following actions MUST occur. 419 The keyed hash produced by the HMAC/SHA2 variant MUST be added as 420 a security result for the BIB representing the security operation 421 on this security target, as discussed in Section 3.4). 423 Finally, the BIB containing information about this security operation 424 MUST be updated as follows. These operations may occur in any order. 426 The security context ID for the BIB MUST be set to the context 427 identifier for BIB-HMAC-SHA2. 429 Any local flags used to generate the IPPT SHOULD be placed in the 430 Integrity Scope flags security parameter for the BIB unless these 431 flags are expected to be correctly configured at security 432 verifiers and acceptors in the network. 434 The HMAC key MAY be encapsulated using some key encapsulation 435 mechanism (to include encrypting with a key encryption key) and 436 the results of the encapsulation added as the Encapsulated Key 437 security parameter for the BIB. 439 The SHA Variant used by this security context SHOULD be added as 440 the SHA Variant security parameter for the BIB if it differs from 441 the default key length. Otherwise, this parameter MAY be omitted 442 if doing so provides a useful reduction in message sizes. 444 Problems encountered in the keyed hash generation MUST be processed 445 in accordance with local BPSec security policy. 447 3.7.2. Keyed Hash Verification 449 During keyed hash verification, the input of the security target and 450 a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. 452 During keyed hash verification, two inputs are prepared for the the 453 appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These 454 data items MUST be generated as follows. 456 The HMAC key MUST be derived using the Encapsulated Key security 457 parameter if such a parameter is included in the security context 458 parameters of the BIB. Otherwise, this key MUST be derived in 459 accordance with security policy at the verifying node as discussed 460 in Section 3.5. 462 The IPPT MUST be generated as discussed in Section 3.6 with the 463 value of Integrity Scope flags being taken from the Integrity 464 Scope flags security context parameter. If the Integrity Scope 465 flags parameter is not included in the security context parameters 466 then these flags MAY be derived from local security policy. 468 The calculated HMAC output MUST be compared to the expected HMAC 469 output encoded in the security results of the BIB for the security 470 target. If the calculated HMAC and expected HMAC are identical, the 471 verification MUST be considered a success. Otherwise, the 472 verification MUST be considered a failure. 474 If the verification fails or if any needed parameters are missing 475 then the verification MUST be treated as failed and processed in 476 accordance with local security policy. 478 This security service is removed from the bundle at the security 479 acceptor as required by the BPSec specification. If the security 480 acceptor is not the bundle destination and if no other integrity 481 service is being applied to the target block, then a CRC MUST be 482 included for the target block. The CRC type, as determined by 483 policy, is set in the target block's CRC type field and the 484 corresponding CRC value is added as the CRC field for that block. 486 4. Security Context BCB-AES-GCM 488 4.1. Overview 490 The BCB-AES-GCM security context replaces the block-type-specific 491 data field of its security target with cipher text generated using 492 the Advanced Encryption Standard (AES) cipher operating in Galois/ 493 Counter Mode (GCM) [AES-GCM]. 495 Additionally, the BCB-AES-GCM security context generates an 496 authentication tag based on the plain text value of the block-type- 497 specific data and other additional authenticated data that may be 498 specified via parameters to this security context. 500 This security context supports two variants of AES-GCM, based on the 501 supported length of the symmetric key. These variants correspond to 502 A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value 503 for AES-GCM. 505 The BCB-AES-GCM security context shall have the Security Context ID 506 specified in Section 5.1. 508 4.2. Scope 510 There are two scopes associated with BCB-AES-GCM: the scope of the 511 confidentiality service and the scope of the authentication service. 512 The first defines the set of information provided to the AES-GCM 513 cipher for the purpose of producing cipher text. The second defines 514 the set of information used to generate an authentication tag. 516 The scope of the confidentiality service defines the set of 517 information provided to the AES-GCM cipher for the purpose of 518 producing cipher text. This MUST be the full set of plain text 519 contained in the block-type-specific data field of the security 520 target. 522 The scope of the authentication service defines the set of 523 information used to generate an authentication tag carried with the 524 security block. This information MUST include the plain text of the 525 block-type-specific data field of the security target. This 526 information MAY include other information (additional authenticated 527 data), as follows. 529 Primary block 530 The primary block identifies a bundle and, once created, the 531 contents of this block are immutable. Changes to the primary 532 block associated with the security target indicate that the 533 security target (and BCB) may no longer be in the correct bundle. 535 For example, if a security target and associated BCB are copied 536 from one bundle to another bundle, the BCB may still be able to 537 decrypt the security target even though these blocks were never 538 intended to exist in the copied-to bundle. 540 Including this information as part of additional authenticated 541 data ensures that security target (and security block) appear in 542 the same bundle at the time of decryption as at the time of 543 encryption. 545 Security target other fields 546 The other fields of the security target include block 547 identification and processing information. Changing this 548 information changes how the security target is treated by nodes 549 in the network even when the "user data" of the security target 550 are otherwise unchanged. 552 For example, if the block processing control flags of a security 553 target are different at a security verifier than they were 554 originally set at the security source then the policy for 555 handling the security target has been modified. 557 Including this information as part of additional authenticated 558 data ensures that the cipher text in the security target will not 559 be used with a different set of block policy than originally set 560 at the time of encryption. 562 BCB other fields 563 The other fields of the BCB include block identification and 564 processing information. Changing this information changes how 565 the BCB is treated by nodes in the network, even when other 566 aspects of the BCB are unchanged. 568 For example, if the block processing control flags of the BCB are 569 different at a security acceptor than they were originally set at 570 the security source then the policy for handling the BCB has been 571 modified. 573 Including this information as part of additional authenticated 574 data ensures that the policy and identification of the security 575 service in the bundle has not changed. 577 NOTE: The security context identifier and security context 578 parameters of the security block are not included as additional 579 authenticated data because these parameters, by definition, are 580 those needed to verify or accept the security service. 581 Therefore, it is expected that changes to these values would 582 result in failures at security verifiers and security acceptors. 584 The scope of the BCB-AES-GCM security context is configured using an 585 optional security context parameter. 587 4.3. Parameters 589 BCB-AES-GCM can be parameterized to specify the AES variant, 590 initialization vector, key information, and identify additional 591 authenticated data. 593 4.3.1. Initialization Vector (IV) 595 This optional parameter identifies the initialization vector (IV) 596 used to initialize the AES-GCM cipher. 598 The length of the initialization vector, prior to any CBOR encoding, 599 MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used 600 unless local security policy requires a different length. 602 This value MUST be encoded as a CBOR byte string. 604 The initialization vector may have any value with the caveat that a 605 value MUST NOT be re-used for multiple encryptions using the same 606 encryption key. This value MAY be re-used when encrypting with 607 different keys. For example, if each encryption operation using BCB- 608 AES-GCM uses a newly generated key, then the same IV may be reused. 610 4.3.2. AES Variant 612 This optional parameter identifies the AES variant being used for the 613 AES-GCM encryption, where the variant is identified by the length of 614 key used. 616 This value MUST be encoded as a CBOR unsigned integer. 618 Valid values for this parameter are as follows. 620 AES Variant Parameter Values 622 +-------+-----------------------------------------------------------+ 623 | Value | Description | 624 +-------+-----------------------------------------------------------+ 625 | 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values | 626 | | for AES-GCM | 627 | 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values | 628 | | for AES-GCM | 629 +-------+-----------------------------------------------------------+ 631 When not provided, implementations SHOULD assume a value of 3 632 (indicating use of A256GCM), unless an alternate default is 633 established by security policy at the security source, verifier, or 634 acceptor of this integrity service. 636 Regardless of the variant, the generated authentication tag MUST 637 always be 128 bits. 639 4.3.3. Encapsulated Key 641 This optional parameter contains the output of a Key Encapsulation 642 Mechanism (KEM) run at the security source of this security context. 644 This value MUST be encoded as a CBOR byte string. 646 If provided, this information is used to retrieve the symmetric AES 647 key used in the generation of security results for this security 648 context. If not provided, security verifiers and acceptors MUST 649 determine the proper key as a function of their local BPSec policy 650 and configuration, as discussed in Section 4.5. 652 4.3.4. AAD Scope Flags 654 This optional parameter contains a series of flags that describe what 655 information is to be included with the block-type-specific data of 656 the security target as part of additional authenticated data (AAD). 658 This value MUST be represented as a CBOR unsigned integer, the value 659 of which MUST be processed as a bit field containing no more than 16 660 bits. 662 Bits in this field represent additional information to be included 663 when generating an integrity signature over the security target. 664 These bits are defined as follows. 666 - Bit 0 (the low-order bit, 0x1): Primary Block Flag. 668 - Bit 1 (0x02): Target Header Flag. 670 - Bit 2 (0x03): Security Header Flag. 672 - Bits 3-7 are reserved. 674 - Bits 8-15 are unassigned. 676 4.3.5. Enumerations 678 BCB-AES-GCM defines the following security context parameters. 680 BCB-AES-GCM Security Parameters 682 +----+-----------------------+--------------------+---------------+ 683 | Id | Name | CBOR Encoding Type | Default Value | 684 +----+-----------------------+--------------------+---------------+ 685 | 1 | Initialization Vector | Byte String | NONE | 686 | 2 | AES Variant | UINT | 3 | 687 | 3 | Encapsulation Key | Byte String | NONE | 688 | 4 | AAD Scope Flags | UINT | 0x7 | 689 +----+-----------------------+--------------------+---------------+ 691 Table 4 693 4.4. Results 695 The BCB-AES-GCM security context produces a single security result 696 carried in the security block: the authentication tag. 698 NOTES: 700 The cipher text generated by the cipher suite is not considered a 701 security result as it is stored in the block-type-specific data 702 field of the security target block. When operating in GCM mode, 703 AES produces cipher text of the same size as its plain text and, 704 therefore, no additional logic is required to handle padding or 705 overflow caused by the encryption in most cases (see below). 707 If the generated cipher text contains the authentication tag and 708 the tag can be separated from the cipher text then the tag MUST be 709 separated and stored in the Authentication Tag security result 710 field. 712 If the generated cipher text contains the authentication tag and 713 the tag cannot be separated from the cipher text then the tag MUST 714 NOT be included in the Authentication tag security result field. 715 Instead the security target block MUST be resized to accommodate 716 the additional 128 bits of authentication tag included in the 717 generated cipher text. 719 4.4.1. Authentication Tag 721 The authentication tag is generated by the cipher suite over the 722 security target plain text input to the cipher suite as combined with 723 any optional additional authenticated data. This tag is used to 724 ensure that the plain text (and important information associated with 725 the plain text) is authenticated prior to decryption. 727 If the authentication tag is included in the cipher text placed in 728 the security target block-type-specific data field, then this 729 security result MUST NOT be included in the BCB for that security 730 target. 732 The length of the authentication tag, prior to any CBOR encoding, 733 MUST be 128 bits. 735 This value MUST be encoded as a CBOR byte string. 737 4.4.2. Enumerations 739 BCB-AES-GCM defines the following security context parameters. 741 BCB-AES-GCM Security Results 743 +-----------+--------------------+--------------------+ 744 | Result Id | Result Name | CBOR Encoding Type | 745 +-----------+--------------------+--------------------+ 746 | 1 | Authentication Tag | Byte String | 747 +-----------+--------------------+--------------------+ 749 Table 5 751 4.5. Key Considerations 753 BCB-AES-GCM does not define or otherwise mandate any method for key 754 exchange, encryption, or encapsulation. The derivation of an 755 appropriate key is considered separate from the application of the 756 authenticated confidentiality service provided by this context. 758 Keys used with this context MUST be symmetric and MUST have a key 759 length equal to the key length defined in the security context 760 parameters or as defined by local security policy at security 761 verifiers and acceptors. 763 It is assumed that any security verifier or security acceptor can 764 determine the proper key to be used. Potential sources of the key 765 include (but are not limited to) the following. 767 Pre-placed keys selected based on local policy. 769 Keys extracted from encapsulated key material carried in the BCB. 771 Session keys negotiated via a mechanism external to the BCB. 773 The security provided by block ciphers is reduced as more data is 774 processed with the same key. The total number of bytes processed 775 with a single key for AES-GCM is recommended to be less than 2^64, as 776 described in Appendix B of [AES-GCM]. 778 As discussed in Section 6 and emphasized here, it is strongly 779 recommended that keys be protected once generated, both when they are 780 stored and when they are transmitted. 782 4.6. GCM Considerations 784 The GCM cryptographic mode of AES has specific requirements that must 785 be followed by implementers for the secure function of the BCB-AES- 786 GCM security context. While these requirements are well documented 787 in [AES-GCM], some of them are repeated here for emphasis. 789 The pairing of an Initialization Vector (IV) and a security key 790 MUST be unique. The same IV must not be used with the same 791 security key. If an IV and key pair are repeated then the GCM 792 implementation may be vulnerable to forgery attacks. More 793 information regarding the importance of the uniqueness of the IV 794 value can be found in Appendix A of [AES-GCM]. 796 While any tag-based authentication mechanism has some likelihood 797 of being forged, this probability is increased when using AES-GCM. 798 In particular, short tag lengths combined with very long messages 799 should be avoided when using this mode. The BCB-AES-GCM security 800 context requires the use of 128-bit authentication tags at all 801 times. Concerns relating to the size of authentication tags is 802 discussed in Appendices B and C of [AES-GCM]. 804 As discussed in Appendix B of [AES-GCM], implementations should 805 limit the number of unsuccessful verification attempts for each 806 key to reduce the likelihood of guessing tag values. 808 As discussed in the Security Considerations section of 809 [I-D.ietf-dtn-bpsec], delay-tolerant networks may have a higher 810 occurrence of replay attacks due to the store-and-forward nature 811 of the network. Because GCM has no inherent replay attack 812 protection, implementors should attempt to detect replay attacks 813 by using mechanisms such as those described in Appendix D of 814 [AES-GCM]. 816 4.7. Canonicalization Algorithms 818 This section defines the canonicalization algorithms used to prepare 819 the inputs used to generate both the cipher text and the 820 authentication tag. 822 In all cases, the canonical form of any portion of an extension block 823 MUST be performed as described in [I-D.ietf-dtn-bpsec]. The 824 canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to 825 the canonical forms for extension blocks defined in 826 [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values 827 are represented in CBOR. 829 4.7.1. Cipher text related calculations 831 The plain text used during encryption MUST be calculated as the 832 single, definite-length CBOR byte string representing the block-type- 833 specific data field of the security target excluding the CBOR byte 834 string identifying byte and optional CBOR byte string length field. 836 For example, consider the following two CBOR byte strings and the 837 plain text that would be extracted from them. 839 CBOR Byte String Examples 841 +------------------------------+---------+--------------------------+ 842 | CBOR Byte String (Hex) | CBOR | Plain Text Part (Hex) | 843 | | Part | | 844 | | (Hex) | | 845 +------------------------------+---------+--------------------------+ 846 | 18ED | 18 | ED | 847 +------------------------------+---------+--------------------------+ 848 | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | 849 +------------------------------+---------+--------------------------+ 851 Table 6 853 Similarly, the cipher text used during decryption MUST be calculated 854 as the single, definite-length CBOR byte string representing the 855 block-type-specific data field excluding the CBOR byte string 856 identifying byte and optional CBOR byte string length field. 858 All other fields of the security target (such as the block type code, 859 block number, block processing control flags, or any CRC information) 860 MUST NOT be considered as part of encryption or decryption. 862 4.7.2. Additional Authenticated Data 864 The construction of additional authenticated data depends on the AAD 865 Scope flags that may be provided as part of customizing the behavior 866 of this security context. 868 The canonical form of the AAD input to the BCB-AES-GCM mechanism is 869 constructed using the following process. This process MUST be 870 followed when generating AAD for either encryption or decryption. 872 1. The canonical form of the AAD starts as the empty set with length 873 0. 875 2. If the AAD Scope parameter is present and the Primary Block Flag 876 is set to 1, then a canonical form of the bundle's primary block 877 MUST be calculated and the result appended to the AAD. 879 3. If the AAD Scope parameter is present and the Security Header 880 flag is set to 1, then the canonical form of the Block Type Code, 881 Block Number, and Block Processing Control Flags associated with 882 the BIB MUST be calculated and, in that order, appended to the 883 AAD. 885 4. If the AAD Scope parameter is present and the Target Header flag 886 is set to 1, then the canonical form of the Block Type Code, 887 Block Number, and Block Processing Control Flags associated with 888 the security target MUST be calculated and, in that order, 889 appended to the AAD. 891 If, after this process, the AAD remains at length 0, then no AAD 892 exists to be input to the cipher suite. 894 4.8. Processing 896 4.8.1. Encryption 898 During encryption, four inputs are prepared for input to the AES/GCM 899 cipher: the encryption key, the Initialization Vector (IV), the 900 security target plain text to be encrypted, and any additional 901 authenticated data. These data items MUST be generated as follows. 903 Prior to encryption, if a CRC value is present for the target block, 904 then that CRC value MUST be removed. This requires removing the CRC 905 field from the target block and setting the CRC Type field of the 906 target block to "no CRC is present." 908 The encryption key MUST have the appropriate length as required by 909 local security policy. The key may be generated specifically for 910 this encryption, given as part of local security policy, or 911 through some other key management mechanism as discussed in 912 Section 4.5. 914 The Initialization Vector (IV) selected MUST be of the appropriate 915 length. Because replaying an IV in counter mode voids the 916 confidentiality of all messages encrypted with said IV, this 917 context also requires a unique IV for every encryption performed 918 with the same key. This means the same key and IV combination 919 MUST NOT be used more than once. 921 The security target plain text for encryption MUST be generated as 922 discussed in Section 4.7.1. 924 Additional authenticated data, if present, MUST be generated as 925 discussed in Section 4.7.2 with the value of AAD Scope flags being 926 taken from local security policy. 928 Upon successful encryption the following actions MUST occur. 930 The cipher text produced by AES/GCM MUST replace the bytes used to 931 define the plain text in the security target block's block-type- 932 specific data field. The block length of the security target MUST 933 be updated if the generated cipher text is larger than the plain 934 text (which can occur when the authentication tag is included in 935 the cipher text calculation, as discussed in Section 4.4). 937 The authentication tag calculated by the AES/GCM cipher MUST be 938 added as a security result for the security target in the BCB 939 holding results for this security operation. 941 Cases where the authentication tag is generated as part of the 942 cipher text MUST be processed as described in Section 4.4. 944 Finally, the BCB containing information about this security operation 945 MUST be updated as follows. These operations may occur in any order. 947 The security context ID for the BCB MUST be set to the context 948 identifier for BCB-AES-GCM. 950 The IV input to the cipher MUST be added as the IV security 951 parameter for the BCB. 953 Any local flags used to generated AAD for this cipher MUST be 954 added as the AAD Scope flags security parameter for the BCB. 956 The encryption key MAY be encapsulated using some key 957 encapsulation mechanism (to include encrypting with a key 958 encryption key) and the results of the encapsulation added as the 959 Encapsulated Key security parameter for the BCB. 961 The key length used by this security context MUST be considered 962 when setting the AES Variant security parameter for the BCB if it 963 differs from the default AES Variant. Otherwise, the AES Variant 964 MAY be omitted if doing so provides a useful reduction in message 965 sizes. 967 Problems encountered in the encryption MUST be processed in 968 accordance with local security policy. This MAY include restoring a 969 CRC value removed from the target block prior to encryption, if the 970 target block is allowed to be transmitted after an encryption error. 972 4.8.2. Decryption 974 During encryption, five inputs are prepared for input to the AES/GCM 975 cipher: the decryption key, the Initialization Vector (IV), the 976 security target cipher text to be decrypted, any additional 977 authenticated data, and the authentication tag generated from the 978 original encryption. These data items MUST be generated as follows. 980 The decryption key MUST be derived using the Encapsulated Key 981 security parameter if such a parameter is included in the security 982 context parameters of the BCB. Otherwise this key MUST be derived 983 in accordance with security policy at the decrypting node as 984 discussed in Section 4.5. 986 The Initialization Vector (IV) MUST be set to the value of the IV 987 security parameter included in the BCB. If the IV parameter is 988 not included as a security parameter, an IV MAY be derived as a 989 function of local security policy and other BCB contents or a lack 990 of an IV security parameter in the BCB MAY be treated as an error 991 by the decrypting node. 993 The security target cipher text for decryption MUST be generated 994 as 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 the AAD Scope flags security context parameter. If the 999 AAD Scope flags parameter is not included in the security context 1000 parameters then these flags MAY be derived from local security 1001 policy in cases where the set of such flags is determinable in the 1002 network. 1004 The authentication tag MUST be present in the BCB security context 1005 parameters field if additional authenticated data are defined for 1006 the BCB (either in the AAD Scope flags parameter or as specified 1007 by local policy). This tag MUST be 128 bits in length. 1009 Upon successful decryption the following actions MUST occur. 1011 The plain text produced by AES/GCM MUST replace the bytes used to 1012 define the cipher text in the security target block's block-type- 1013 specific data field. Any changes to the security target block 1014 length field MUST be corrected in cases where the plain text has a 1015 different length than the replaced cipher text. 1017 If the security acceptor is not the bundle destination and if no 1018 other integrity or confidentiality service is being applied to the 1019 target block, then a CRC MUST be included for the target block. The 1020 CRC type, as determined by policy, is set in the target block's CRC 1021 type field and the corresponding CRC value is added as the CRC field 1022 for that block. 1024 If the cipher text fails to authenticate, if any needed parameters 1025 are missing, or if there are other problems in the decryption then 1026 the decryption MUST be treated as failed and processed in accordance 1027 with local security policy. 1029 5. IANA Considerations 1031 5.1. Security Context Identifiers 1033 This specification allocates two security context identifiers from 1034 the "BPSec Security Context Identifier" registry defined in 1035 [I-D.ietf-dtn-bpsec]. 1037 Additional Entries for the BPSec Security Context Identifiers 1038 Registry: 1040 +-------+---------------+---------------+ 1041 | Value | Description | Reference | 1042 +-------+---------------+---------------+ 1043 | TBA | BIB-HMAC-SHA2 | This document | 1044 | TBA | BCB-AES-GCM | This document | 1045 +-------+---------------+---------------+ 1047 Table 7 1049 6. Security Considerations 1051 Security considerations specific to a single security context are 1052 provided in the description of that context. This section discusses 1053 security considerations that should be evaluated by implementers of 1054 any security context described in this document. Considerations may 1055 also be found in documents listed as normative references and they 1056 should also be reviewed by security context implementors. 1058 6.1. Key Handling 1060 In addition to the key considerations listed in each security 1061 context, the following also apply to the generation, transmission, 1062 and use of keys associated with all of the security contexts defined 1063 in this document. 1065 It is strongly recommended that implementations protect keys both 1066 when they are stored and when they are transmitted. 1068 In the event that a key is compromised, any security operations 1069 using a security context associated with that key should also be 1070 considered compromised. This means that the BIB-HMAC-SHA2 1071 security context cannot provide integrity when used with a 1072 compromised key and BCB-AES-GCM cannot provide confidentiality 1073 when used with a compromised key. 1075 When keys are extracted from key material carried in a security 1076 block, the encapsulated key SHOULD be protected by an approved 1077 algorithm such as NIST SP-800-38F. The determination to use 1078 approved algorithms increases interoperability and the specific 1079 algorithm used should be specified as part of local security 1080 policy. 1082 The same key should not be used for different algorithms as doing 1083 so may leak information about the key. 1085 6.2. AES GCM 1087 There are a significant number of considerations related to the use 1088 of the GCM mode of AES to provide a confidentiality service. These 1089 considerations are provided in Section 4.6 as part of the 1090 documentation of the BCB-AES-GCM security context. 1092 6.3. Bundle Fragmentation 1094 Bundle fragmentation may prevent security services in a bundle from 1095 being verified after a bundle is fragmented and before the bundle is 1096 re-assembled. Examples of potential issues include the following. 1098 If a security block and its security target do not exist in the 1099 same fragment, then the security block cannot be processed until 1100 the bundle is re-assembled. If a fragment includes an encrypted 1101 target block, but not its BCB, then a receiving bundle processing 1102 agent (BPA) will not know that the target block has been 1103 encrypted. 1105 If a security block is cryptographically bound to a bundle, it 1106 cannot be processed even if the security block and target both 1107 coexist in the fragment. This is because fragments have different 1108 primary blocks than the original bundle. 1110 If security blocks and their target blocks are repeated in 1111 multiple fragments, policy must determine how to deal with issues 1112 where a security operation verifies in one fragment but fails in 1113 another fragment. This may happen, for example, if a BIB block 1114 becomes corrupted in one fragment but not in another fragment. 1116 Implementors should consider how security blocks are processed when a 1117 BPA fragments a received bundle. For example, security blocks and 1118 their targets could be placed in the same fragment if the security 1119 block is not otherwise cryptographically bound to the bundle being 1120 fragmented. Alternatively, if security blocks are cryptographically 1121 bound to a bundle, then a fragmenting BPA should consider 1122 encapsulating the bundle first and then fragmenting the encapsulating 1123 bundle. 1125 7. Normative References 1127 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 1128 Recommendation for Block Cipher Modes of Operation: 1129 Galois/Counter Mode (GCM) and GMAC.", November 2007. 1131 [HMAC] US NIST, "The Keyed-Hash Message Authentication Code 1132 (HMAC).", FIPS-198-1, Gaithersburg, MD, USA, July 2008. 1134 https://csrc.nist.gov/publications/detail/fips/198/1/final 1136 [I-D.ietf-dtn-bpbis] 1137 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1138 Version 7", draft-ietf-dtn-bpbis-31 (work in progress), 1139 January 2021. 1141 [I-D.ietf-dtn-bpsec] 1142 Birrane, E. and K. McKeever, "Bundle Protocol Security 1143 Specification", draft-ietf-dtn-bpsec-27 (work in 1144 progress), February 2021. 1146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1147 Requirement Levels", BCP 14, RFC 2119, 1148 DOI 10.17487/RFC2119, March 1997, 1149 . 1151 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1152 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1153 . 1155 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1156 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1157 May 2017, . 1159 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1160 Representation (CBOR)", STD 94, RFC 8949, 1161 DOI 10.17487/RFC8949, December 2020, 1162 . 1164 [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- 1165 180-4, Gaithersburg, MD, USA, August 2015. 1167 https://csrc.nist.gov/publications/detail/fips/180/4/final 1169 Appendix A. Acknowledgements 1171 The following participants contributed useful review and analysis of 1172 these security contexts: Amy Alford and Sarah Heiner of the Johns 1173 Hopkins University Applied Physics Laboratory. 1175 Author's Address 1177 Edward J. Birrane, III 1178 The Johns Hopkins University Applied 1179 Physics Laboratory 1180 11100 Johns Hopkins Rd. 1181 Laurel, MD 20723 1182 US 1184 Phone: +1 443 778 7423 1185 Email: Edward.Birrane@jhuapl.edu