idnits 2.17.1 draft-ietf-dtn-bpsec-interop-sc-00.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 (March 11, 2019) is 1871 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-12 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-09 ** 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 March 11, 2019 5 Expires: September 12, 2019 7 BPSec Interoperability Security Contexts 8 draft-ietf-dtn-bpsec-interop-sc-00 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 September 12, 2019. 33 Copyright Notice 35 Copyright (c) 2019 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-HMAC256-SHA256 . . . . . . . . . . . . . 3 53 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Key Considerations . . . . . . . . . . . . . . . . . . . 3 55 3.3. Canonicalization Algorithms . . . . . . . . . . . . . . . 3 56 3.4. Security Context Parameter Definitions . . . . . . . . . 3 57 3.5. Security Result Definitions . . . . . . . . . . . . . . . 4 58 4. Security Context BCB-AES-GCM-256 . . . . . . . . . . . . . . 4 59 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Key Considerations . . . . . . . . . . . . . . . . . . . 4 61 4.3. Canonicalization Algorithms . . . . . . . . . . . . . . . 5 62 4.4. Processing . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.4.1. Encryption . . . . . . . . . . . . . . . . . . . . . 5 64 4.4.2. Decryption . . . . . . . . . . . . . . . . . . . . . 5 65 4.5. Security Context Parameter Definitions . . . . . . . . . 6 66 4.6. Security Result Definitions . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 7 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The Bundle Protocol Security (BPSec) [I-D.ietf-dtn-bpsec] 76 specification provides inter-bundle integrity and confidentiality 77 features for networks deploying the Bundle Protocol (BP) 78 [I-D.ietf-dtn-bpbis]. BPSec defines a set of BP extension blocks to 79 carry security information produced under the auspices of some 80 security context, but does not define a common set of these security 81 contexts. 83 This document defines two security contexts (one for integrity 84 services and one for confidentiality services) suitable for 85 populating BPSec Block Integrity Blocks (BIBs) and Block 86 Confidentiality Blocks (BCBs). 88 This purpose of the security contexts described in this document is 89 twofold. First, these contexts should be used to test the 90 interoperability of BPSec implementations. Second, this 91 specification can serve as a template to be followed by other BPSec 92 security context authors. 94 The intent of these security context definitions is to provide a 95 mechanism for interoperability testing. There is no claim that these 96 contexts are suitable for operational deployment in any particular 97 networking scenario. Further, there is no requirement that these 98 contexts be used in any operational network deployments. 100 These contexts generate information that MUST be encoded using the 101 CBOR specification documented in [RFC7049]. 103 2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 [RFC2119]. 110 3. Security Context BIB-HMAC256-SHA256 112 3.1. Overview 114 This integrity context provides a signed hash over the security 115 target based on the use of the SHA-256 message digest algorithm 116 [RFC4634] combined with HMAC [RFC2104] with a 256 bit truncation 117 length. This formulation is based on the HMAC 256/256 algorithm 118 defined in [RFC8152] Table 7: HMAC Algorithm Values. 120 The BIB-HMAC256-SHA256 context has a Security Context ID of 0x1. 122 3.2. Key Considerations 124 Keys used with this specification MUST be symmetric and 256 bits in 125 length. 127 This context provides no requirements on the configuration or 128 management of keys. 130 3.3. Canonicalization Algorithms 132 BIB-HMAC256-SHA256 uses the standard canonicalization algorithms 133 defined in [I-D.ietf-dtn-bpsec] and operates over all of the block- 134 type-specific data fields for the security target. This context does 135 not include hashing over other parts of the target block header, such 136 as the block type code, block number, block processing control flags, 137 or any CRC information. 139 3.4. Security Context Parameter Definitions 141 BIB-HMAC256-SHA256 defines the following security context parameters. 143 BIB-HMAC256-SHA256 Parameters 145 +------+------+--------+--------------------------------------------+ 146 | Parm | Parm | CBOR | Description | 147 | Id | Name | Type | | 148 +------+------+--------+--------------------------------------------+ 149 | 1 | Key | byte | Material encoded or protected by the key | 150 | | | string | management system and used to transport an | 151 | | | | ephemeral key protected by a long-term | 152 | | | | key. | 153 +------+------+--------+--------------------------------------------+ 155 Table 1 157 3.5. Security Result Definitions 159 BIB-HMAC256-SHA256 defines the following security results. 161 BIB-HMAC256-SHA256 Security Results 163 +-----------+-------------+-------------+---------------------------+ 164 | Result Id | Result Name | CBOR Type | Description | 165 +-----------+-------------+-------------+---------------------------+ 166 | 1 | Tag | byte string | The tag produced by HMAC. | 167 +-----------+-------------+-------------+---------------------------+ 169 Table 2 171 4. Security Context BCB-AES-GCM-256 173 4.1. Overview 175 This confidentiality context provides cipher-text to replace the 176 plain-text block-type-specific data fields of its target block. BCB- 177 AES-GCM-256 uses the Advanced Encryption Standard (AES) cipher 178 operating in Galois/Counter Mode (GCM) [AES-GCM]. This formulation 179 is based on the A256GCM algorithm defined in [RFC8152] Table 9: 180 Algorithm Value for AES-GCM. 182 The BCB-AES-GCM-256 context has a Security Context ID of 0x02. 184 This context modifies the size of the target block. 186 4.2. Key Considerations 188 Keys used with this specification MUST be symmetric and 256 bits in 189 length. 191 This context provides no requirements on the configuration or 192 management of keys. 194 4.3. Canonicalization Algorithms 196 BCB-AES-GCM-256 uses the standard canonicalization algorithms defined 197 in [I-D.ietf-dtn-bpsec] and operates over all of the block-type- 198 specific data fields for the security target. This context does not 199 include hashing over other parts of the target block header, such as 200 the block type code, block number, block processing control flags, or 201 any CRC information. 203 4.4. Processing 205 4.4.1. Encryption 207 When encrypting, the BCB-AES-GCM-256 context treats the catenation of 208 the target block's block-type-specific data fields as a single set of 209 plain-text. 211 Cipher-text, once calculated, is stored as a CBOR byte string 212 replacing the value of the target block's block-type-specific data. 213 Because the plain-text and cipher-text will have the same length, the 214 CBOR byte string encoding will have the same encoding of the byte 215 string type and length. This allows the replacement of plain-text 216 with cipher-text without any additional consideration of block-type- 217 specific data field processing. 219 4.4.2. Decryption 221 When decrypting, the target block's block-type-specific field is 222 verified to be only a CBOR byte string. If this is not the case the 223 decryption is treated as failed and processed in accordance with 224 local security policy. Otherwise, the byte string and key 225 information is passed to the cipher for decryption. 227 If the cipher-text fails to authenticate, or if there are other 228 problems in the decryption (such as the creation of invalid CBOR 229 plain-text) then the decryption MUST be treated as failed and 230 processed in accordance with local security policy. 232 If the decryption succeeds, the resultant plain-text MUST replace the 233 cipher-text in the target-block. 235 4.5. Security Context Parameter Definitions 237 BCB-AES-GCM-256 defines the following security context parameters. 238 It should be noted in this specification there is no additional 239 authenticated data passed in to the AES-GCM cipher. The plain-text 240 is the only data input and MUST be the entire data contents of the 241 target block. Because replaying an IV in counter mode voids the 242 confidentiality of all messages encryption with said IV, this context 243 also requires a unique IV for every encryption performed with the 244 same key. This means the same key and IV combination must never be 245 used more than once. 247 BCB-AES-GCM-256 Parameters 249 +------+----------------+--------+----------------------------------+ 250 | Parm | Parm Name | CBOR | Description | 251 | Id | | Type | | 252 +------+----------------+--------+----------------------------------+ 253 | 1 | Key | byte | Material encoded or protected by | 254 | | | string | the key management system and | 255 | | | | used to transport an ephemeral | 256 | | | | key protected by a long-term | 257 | | | | key. | 258 | 2 | Initialization | byte | The initialization vector. A | 259 | | Vector | string | random value between 8-16 bytes. | 260 | | | | 12 bytes is recommended. | 261 +------+----------------+--------+----------------------------------+ 263 Table 3 265 4.6. Security Result Definitions 267 BCB-AES-GCM-256 defines the following security results. It should be 268 noted that cipher-text is not a security result as the resultant 269 cipher-text is stored in the target block. When operating in GCM 270 mode, AES produces cipher-text of the same size as its plain-text 271 and, therefore, no security results are necessary to capture padding 272 information. 274 BCB-AES-GCM-256 Security Results 276 +--------+----------------+--------+--------------------------------+ 277 | Result | Result Name | CBOR | Description | 278 | Id | | Type | | 279 +--------+----------------+--------+--------------------------------+ 280 | 1 | Authentication | byte | Output from the AES-GCM | 281 | | Tag | string | cipher. This value (prior to | 282 | | | | CBOR encoding) MUST be 16 | 283 | | | | bytes long. | 284 +--------+----------------+--------+--------------------------------+ 286 Table 4 288 5. IANA Considerations 290 5.1. Bundle Block Types 292 This specification allocates two block types from the "BPSec Security 293 Context IDs" registry defined in [I-D.ietf-dtn-bpsec]. 295 Additional BPSec Security Context IDs: 297 +-------+--------------------+---------------+ 298 | Value | Description | Reference | 299 +-------+--------------------+---------------+ 300 | 1 | BIB-HMAC256-SHA256 | This document | 301 | 2 | BCB-AES-GCM-256 | This document | 302 +-------+--------------------+---------------+ 304 Table 5 306 6. Normative References 308 [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: 309 Recommendation for Block Cipher Modes of Operation: 310 Galois/Counter Mode (GCM) and GMAC.", November 2007. 312 [I-D.ietf-dtn-bpbis] 313 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 314 Version 7", draft-ietf-dtn-bpbis-12 (work in progress), 315 November 2018. 317 [I-D.ietf-dtn-bpsec] 318 Birrane, E. and K. McKeever, "Bundle Protocol Security 319 Specification", draft-ietf-dtn-bpsec-09 (work in 320 progress), February 2019. 322 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 323 Hashing for Message Authentication", RFC 2104, 324 DOI 10.17487/RFC2104, February 1997, 325 . 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, 329 DOI 10.17487/RFC2119, March 1997, 330 . 332 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 333 (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 334 2006, . 336 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 337 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 338 October 2013, . 340 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 341 RFC 8152, DOI 10.17487/RFC8152, July 2017, 342 . 344 Appendix A. Acknowledgements 346 The following participants contributed useful analysis of this 347 specification: Prathibha Rama of the Johns Hopkins University Applied 348 Physics Laboratory. 350 Author's Address 352 Edward J. Birrane, III 353 The Johns Hopkins University Applied Physics Laboratory 354 11100 Johns Hopkins Rd. 355 Laurel, MD 20723 356 US 358 Phone: +1 443 778 7423 359 Email: Edward.Birrane@jhuapl.edu