idnits 2.17.1 draft-ietf-dtn-bpsec-interop-sc-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 4, 2020) is 1541 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' == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-21 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-18 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 4, 2020 5 Expires: August 7, 2020 7 BPSec Interoperability Security Contexts 8 draft-ietf-dtn-bpsec-interop-sc-01 10 Abstract 12 This document defines an integrity security context and a 13 confidentiality security context suitable for testing the 14 interoperability of Bundle Protocol Security (BPSec) implementations. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 7, 2020. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 52 3. Security Context BIB-IOP-HMAC256-SHA256 . . . . . . . . . . . 3 53 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Key Considerations . . . . . . . . . . . . . . . . . . . 3 55 3.3. Canonicalization Algorithms . . . . . . . . . . . . . . . 3 56 3.4. Processing . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.4.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 4 58 3.4.2. Keyed Hash Verification . . . . . . . . . . . . . . . 4 59 3.5. Security Context Parameter Definitions . . . . . . . . . 4 60 3.6. Security Context Result Definitions . . . . . . . . . . . 4 61 4. Security Context BCB-IOP-AES-GCM-256 . . . . . . . . . . . . 5 62 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Key Considerations . . . . . . . . . . . . . . . . . . . 5 64 4.3. Canonicalization Algorithms . . . . . . . . . . . . . . . 5 65 4.4. Processing . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.4.1. Encryption . . . . . . . . . . . . . . . . . . . . . 6 67 4.4.2. Decryption . . . . . . . . . . . . . . . . . . . . . 7 68 4.5. Security Context Parameter Definitions . . . . . . . . . 7 69 4.6. Security Result Definitions . . . . . . . . . . . . . . . 8 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Security Context Identifiers . . . . . . . . . . . . . . 8 72 6. Normative References . . . . . . . . . . . . . . . . . . . . 9 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The Bundle Protocol Security (BPSec) [I-D.ietf-dtn-bpsec] 79 specification provides inter-bundle integrity and confidentiality 80 features for networks deploying the Bundle Protocol (BP) 81 [I-D.ietf-dtn-bpbis]. BPSec defines a set of BP extension blocks to 82 carry security information produced under the auspices of some 83 security context, but does not define a mandatory set of security 84 contexts. 86 This document defines two security contexts (one for integrity 87 services and one for confidentiality services) for populating BPSec 88 Block Integrity Blocks (BIBs) and Block Confidentiality Blocks 89 (BCBs). 91 The intent of these security context definitions is to provide a 92 mechanism for interoperability testing. There is no claim that these 93 contexts are suitable for operational deployment in any particular 94 networking scenario. Further, there is no requirement that these 95 contexts be used in any operational network deployments. 97 These contexts generate information that MUST be encoded using the 98 CBOR specification documented in [RFC7049]. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 [RFC2119]. 107 3. Security Context BIB-IOP-HMAC256-SHA256 109 3.1. Overview 111 The BIB-IOP-HMAC256-SHA256 security context provides a keyed hash 112 over a security target. This security context uses the SHA-256 113 secure hash algorithm discussed in [RFC4634] combined with the HMAC 114 keyed hash discussed in [RFC2104]. This combination is based on the 115 HMAC 256/256 algorithm defined in [RFC8152] Table 7: HMAC Algorithm 116 Values. 118 The HMAC shall use a truncation length of 256 bits. 120 The BIB-IOP-HMAC256-SHA256 security context shall have the Security 121 Context ID specified in Section 5.1. 123 3.2. Key Considerations 125 HMAC keys used with this context MUST be symmetric and 256 bits in 126 length. 128 It is assumed that the node performing the integrity verification 129 knows the HMAC key used to create the original keyed hash. 131 BIB-IOP-HMAC256-SHA256 provides no explicit requirements on the 132 configuration, storage, or exchange of HMAC keys. 134 3.3. Canonicalization Algorithms 136 BIB-IOP-HMAC256-SHA256 uses the canonicalization algorithms defined 137 in [I-D.ietf-dtn-bpsec] with the following exceptions. 139 The keyed hash MUST be calculated over the single, definite-length 140 CBOR byte string representing the security target's block-type- 141 specific-data field. All other fields of the security target (such 142 as the block type code, block number, block processing control flags, 143 or any CRC information) MUST NOT be included in the calculation. 145 3.4. Processing 147 3.4.1. Keyed Hash Generation 149 During keyed hash generation, the plain text of the security target 150 and a HMAC key (given by local security policy) are input to the 151 HMAC/SHA algorithm. 153 Upon successful hash generation, the output of the HMAC MUST be added 154 as the security result for the security target. 156 Problems encountered in the keyed hash generation MUST be processed 157 in accordance with local security policy. 159 3.4.2. Keyed Hash Verification 161 During keyed hash verification, the plain text of the security target 162 and a HMAC key (given by local security policy) are input to the 163 HMAC/SHA algorithm. The resulting HMAC output MUST be compared to 164 the expected HMAC output encoded in the security results for the 165 security target. 167 If the calculated HMAC and expected HMAC are identical, the 168 verification MUST be considered a success. Otherwise, the 169 verification MUST be considered a failure and processed according to 170 local security policy. 172 3.5. Security Context Parameter Definitions 174 BIB-IOP-HMAC256-SHA256 defines no security context parameters. 176 3.6. Security Context Result Definitions 178 BIB-IOP-HMAC256-SHA256 defines the following security results. 180 BIB-IOP-HMAC256-SHA256 Security Results 182 +--------+----------+-------------+---------------------------------+ 183 | Result | Result | CBOR | Description | 184 | Id | Name | Encoding | | 185 | | | Type | | 186 +--------+----------+-------------+---------------------------------+ 187 | 1 | Expected | byte string | The output of the HMAC | 188 | | HMAC | | calculation at the security | 189 | | | | source. | 190 +--------+----------+-------------+---------------------------------+ 192 Table 1 194 4. Security Context BCB-IOP-AES-GCM-256 196 4.1. Overview 198 The BCB-IOP-AES-GCM-256 security context generates cipher text to 199 replace the plain text in the block-type-specific-data field of its 200 security target. BCB-IOP-AES-GCM-256 uses the Advanced Encryption 201 Standard (AES) cipher operating in Galois/Counter Mode (GCM) 202 [AES-GCM]. This formulation is based on the A256GCM algorithm 203 defined in [RFC8152] Table 9: Algorithm Value for AES-GCM. 205 The BCB-IOP-AES-GCM-256 security context shall have the Security 206 Context ID specified in Section 5.1. 208 4.2. Key Considerations 210 Keys used with this specification MUST be symmetric and 256 bits in 211 length. 213 It is assumed that the node performing the decryption knows the 214 symmetric key used for encryption. 216 BCB-IOP-AES-GCM-256 provides no explicit requirements on the 217 configuration, storage, or exchange of keys. 219 4.3. Canonicalization Algorithms 221 BCB-IOP-AES-GCM-256 uses the canonicalization algorithms defined in 222 [I-D.ietf-dtn-bpsec] with the following exceptions. 224 The plain text used during encryption MUST be calculated as the 225 single, definite-length CBOR byte string representing the block-type- 226 specific-data field excluding the CBOR byte string identifying byte 227 and optional CBOR byte string length field. 229 For example, consider the following two CBOR byte strings and the 230 plain text that would be extracted from them. 232 CBOR byte string Examples 234 +-----------------------------+----------+--------------------------+ 235 | CBOR Byte String | CBOR | Plain Text | 236 | | Encoding | | 237 +-----------------------------+----------+--------------------------+ 238 | 0x18ED | 0x18 | 0xED | 239 +-----------------------------+----------+--------------------------+ 240 | 0xC24CDEADBEEFDEADBEEFDEADB | 0xC24C | 0xDEADBEEFDEADBEEFDEADBE | 241 | EEF | | EF | 242 +-----------------------------+----------+--------------------------+ 244 Table 2 246 Similarly, the cipher text used during decryption MUST be calculated 247 as the single, definite-length CBOR byte string representing the 248 block-type-specific-data field excluding the CBOR byte string 249 identifying byte and optional CBOR byte string length field. 251 All other fields of the security target (such as the block type code, 252 block number, block processing control flags, or any CRC information) 253 MUST NOT be considered as part of encryption or decryption. 255 4.4. Processing 257 4.4.1. Encryption 259 During encryption, the plain text of the security target MUST be 260 input to the AES/GCM cipher with a unique Initialization Vector (IV) 261 and an appropriate key (given by local security policy). 263 Upon successful encryption, the cipher text produced by AES/GCM 264 (which will have the same length as the plain text provided to it) 265 MUST replace the bytes used to define the plain text in the target 266 block's block-type-specific-data field. 268 The IV input to the cipher MUST be added as a security parameter for 269 the security target. Because replaying an IV in counter mode voids 270 the confidentiality of all messages encrypted with said IV, this 271 context also requires a unique IV for every encryption performed with 272 the same key. This means the same key and IV combination MUST NOT be 273 used more than once. 275 The authentication tag calculated by the AES/GCM cipher MUST be added 276 as a security result for the security target. 278 Problems encountered in the encryption MUST be processed in 279 accordance with local security policy. 281 NOTE: Because the cipher text and the plain text have the same 282 length, the encoding information for the CBOR byte string (the CBOR 283 byte string identifying byte and optional CBOR byte string length 284 field) MUST remain unchanged in the target block's block-type- 285 specific-data field. This allows for the replacement of plain text 286 with cipher text without any additional consideration of block-type- 287 specific-data field processing. 289 4.4.2. Decryption 291 During decryption, the cipher text of the security target MUST be 292 input to the AES/GCM cipher with the IV present in the security 293 parameters, an appropriate key (given by local security policy), and 294 the authentication tag present in the security results. 296 The plain text produced by AES/GCM (which will have the same length 297 as the cipher text provided to it) MUST replace the bytes used to 298 define the cipher text in the target block's block-type-specific-data 299 field. 301 If the cipher text fails to authenticate, if any needed parameters 302 are missing, or if there are other problems in the decryption then 303 the decryption MUST be treated as failed and processed in accordance 304 with local security policy. 306 Upon successful decryption, the recovered plain text MUST replace the 307 bytes used to define the cipher text in the target block's block- 308 type-specific-data field. 310 NOTE: Because the cipher text and the plain text have the same 311 length, the encoding information for the CBOR byte string (the CBOR 312 byte string identifying byte and optional CBOR byte string length 313 field) MUST remain unchanged in the target block's block-type- 314 specific-data field. This allows for the replacement of cipher text 315 with plain text without any additional consideration of block-type- 316 specific-data field processing. 318 4.5. Security Context Parameter Definitions 320 BCB-IOP-AES-GCM-256 defines the following security context 321 parameters. 323 BCB-IOP-AES-GCM-256 Parameters 325 +------+----------------+----------+--------------------------------+ 326 | Parm | Parm Name | CBOR | Description | 327 | Id | | Encoding | | 328 | | | Type | | 329 +------+----------------+----------+--------------------------------+ 330 | 1 | Initialization | byte | The initialization vector. A | 331 | | Vector | string | value with a length, prior to | 332 | | | | CBOR encoding, between 8-16 | 333 | | | | bytes. 12 bytes | 334 | | | | is recommended. | 335 +------+----------------+----------+--------------------------------+ 337 Table 3 339 4.6. Security Result Definitions 341 BCB-IOP-AES-GCM-256 defines the following security results. 343 NOTE: Cipher text is not a security result as it is stored in the 344 target block. When operating in GCM mode, AES produces cipher text 345 of the same size as its plain text and, therefore, no additional 346 logic is required to handle padding or overflow. 348 BCB-IOP-AES-GCM-256 Security Results 350 +--------+----------------+----------+------------------------------+ 351 | Result | Result Name | CBOR | Description | 352 | Id | | Encoding | | 353 | | | Type | | 354 +--------+----------------+----------+------------------------------+ 355 | 1 | Authentication | byte | Output from | 356 | | Tag | string | the AES-GCM cipher. This | 357 | | | | value, prior to CBOR | 358 | | | | byte string encoding, MUST | 359 | | | | have a length of 16 bytes. | 360 +--------+----------------+----------+------------------------------+ 362 Table 4 364 5. IANA Considerations 366 5.1. Security Context Identifiers 368 This specification allocates two security context identifiers from 369 the "BPSec Security Context Identifier" registry defined in 370 [I-D.ietf-dtn-bpsec]. 372 Additional Entries for the BPSec Security Context Identifiers 373 Registry: 375 +-------+------------------------+---------------+ 376 | Value | Description | Reference | 377 +-------+------------------------+---------------+ 378 | TBA | BIB-IOP-HMAC256-SHA256 | This document | 379 | TBA | BCB-IOP-AES-GCM-256 | This document | 380 +-------+------------------------+---------------+ 382 Table 5 384 6. Normative References 386 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 387 Recommendation for Block Cipher Modes of Operation: 388 Galois/Counter Mode (GCM) and GMAC.", November 2007. 390 [I-D.ietf-dtn-bpbis] 391 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 392 Version 7", draft-ietf-dtn-bpbis-21 (work in progress), 393 January 2020. 395 [I-D.ietf-dtn-bpsec] 396 Birrane, E. and K. McKeever, "Bundle Protocol Security 397 Specification", draft-ietf-dtn-bpsec-18 (work in 398 progress), January 2020. 400 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 401 Hashing for Message Authentication", RFC 2104, 402 DOI 10.17487/RFC2104, February 1997, 403 . 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 408 . 410 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 411 (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 412 2006, . 414 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 415 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 416 October 2013, . 418 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 419 RFC 8152, DOI 10.17487/RFC8152, July 2017, 420 . 422 Appendix A. Acknowledgements 424 The following participants contributed useful review and analysis of 425 these security contexts: Amy Alford and Sarah Heiner of the Johns 426 Hopkins University Applied Physics Laboratory. 428 Author's Address 430 Edward J. Birrane, III 431 The Johns Hopkins University Applied 432 Physics Laboratory 433 11100 Johns Hopkins Rd. 434 Laurel, MD 20723 435 US 437 Phone: +1 443 778 7423 438 Email: Edward.Birrane@jhuapl.edu