idnits 2.17.1 draft-birrane-dtn-bpsec-suiteb-ciphersuites-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 : ---------------------------------------------------------------------------- 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 (December 31, 2015) is 3032 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'FIPS180-3' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'FIPS197' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'I-D.hennessy-bsp-suiteb-profile' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC5050' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'SP800-56A' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'SuiteB' is defined on line 367, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: Experimental December 31, 2015 5 Expires: July 3, 2016 7 Suite B Ciphersuites for Bundle Protocol Security (BPSec) 8 draft-birrane-dtn-bpsec-suiteb-ciphersuites-00 10 Abstract 12 This document proposes ciphersuites to be used for Bundle Protocol 13 Security (BPSec). These new ciphersuites provide compatibility with 14 the United States National Security Agency's Suite B specifications. 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 http://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 July 3, 2016. 33 Copyright Notice 35 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . . . . . 2 52 3. Suite B Ciphersuites . . . . . . . . . . . . . . . . . . . . 2 53 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3.2. Suites BIB-ECDSA-SHA256 and BIB-ECDSA-SHA384 . . . . . . 3 55 3.3. Suites BCB-ECDH-SHA256-AES128 and BCB-ECDH-SHA384-AES256 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 60 6.2. Informative References . . . . . . . . . . . . . . . . . 8 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 This document specifies ciphersuites to be used with Bundle Protocol 66 Security (BPSec) [I-D.ietf-dtn-bpsec]. These suites provide 67 compatibility with the United States National Security Agency's Suite 68 B specifications. 70 This document is an update to the Suite-B profile created by Burgin 71 and Hennessy [I-D.hennessy-bsp-suiteb-ciphersuites]. This update 72 adapts the profile from BSP [RFC6257] to BPSec. 74 2. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in 79 [RFC2119]. 81 3. Suite B Ciphersuites 83 3.1. Overview 85 This section defines new ciphersuites for use with the security block 86 types BIB and BCB. The BIB ciphersuites are based on digital 87 signatures using ECDSA. The BCB ciphersuites use ECDH for key 88 agreement, AES in Galois/Counter Mode (GCM) for content encryption, 89 and AES Key Wrap for key encryption. All proposed ciphersuites use 90 SHA-256 or SHA-384 as the hash algorithm. 92 The ciphersuites use the mechanisms defined in Cryptographic Message 93 Syntax (CMS) [RFC5652] for packaging the keys, signatures, etc., for 94 transport in the appropriate security block. Additionally, the 95 ciphersuites follow the guidance and requirements of RFC 6318 97 [RFC6318] which specifies the conventions for using Suite B 98 algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME). 100 CMS values are generated using ASN.1 [X.208-88], the Basic Encoding 101 Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER) 102 [X.509-88]. 104 3.2. Suites BIB-ECDSA-SHA256 and BIB-ECDSA-SHA384 106 The BIB-ECDSA-SHA256 ciphersuite has ciphersuite ID value 0xB1, and 107 the BIB-ECDSA-SHA384 ciphersuite has ciphersuite ID value 0xB2. 109 In BIB-ECDSA-SHA256, ECDSA MUST be used with the SHA-256 message 110 digest algorithm and the P-256 elliptic curve, as specified in 111 [RFC6318]. In BIB-ECDSA-SHA384, ECDSA MUST be used with the SHA-384 112 message digest algorithm and the P-384 elliptic curve, as specified 113 in [RFC6318]. The P-256 and P-384 elliptic curves are specified in 114 [DSS]. 116 The SHA-256 and SHA-384 message digest algorithms are defined in FIPS 117 Pub 180-3 [RFC5754]. The algorithm identifiers for SHA-256 and 118 SHA-384 are defined in [RFC5754]. RFC 5754 specifies the conventions 119 for using SHA-256 and SHA-384 with CMS. Within the CMS signed-data 120 content type, message digest algorithm identifiers are located in the 121 SignedData digestAlgorithms field and the SignerInfo digestAlgorithm 122 field. 124 RFC 5753 [RFC5753] specifies the conventions for using ECDSA with 125 CMS. RFC 5480 [RFC5480] defines the signature algorithm identifiers 126 used in CMS for ECDSA with SHA-256 and ECDSA with SHA-384. Relevant 127 details are repeated here. 129 Within the CMS signed-data content type, signature algorithm 130 identifiers are located in the SignerInfo signatureAlgorithm field of 131 SignedData. In addition, signature algorithm identifiers are located 132 in the SignerInfo signatureAlgorithm field of countersignature 133 attributes. When either signature algorithm identifier is used, the 134 AlgorithmIdentifier parameters field MUST be absent. 136 When signing, the ECDSA algorithm generates two values, commonly 137 called r and s. To transfer these two values as one signature, they 138 MUST be encoded using the ECDSA-Sig-Value type specified in RFC 5480 139 [RFC5480]. 141 Because the signature field in SignedData SignatureValue is a 142 security-result field, the entire key-information item MUST be placed 143 in the BIB's security-result field, rather than security- parameters. 145 3.3. Suites BCB-ECDH-SHA256-AES128 and BCB-ECDH-SHA384-AES256 147 The BCB-ECDH-SHA256-AES128 ciphersuite has ciphersuite ID value 0xB3, 148 and the BCB-ECDH-SHA384-AES256 ciphersuite has ciphersuite ID value 149 0xB4. 151 These schemes encrypt any block in a bundle except the primary block 152 and another BCB block. Both ciphersuites use ephemeral-static ECDH, 153 which means that the security source possesses an ephemeral ECDH key 154 pair and the security destination possesses a static ECDH key pair. 156 In BCB-ECDH-SHA256-AES128, ephemeral-static ECDH MUST be used with 157 the SHA-256 KDF, AES-128 Key Wrap, and the P-256 elliptic curve, as 158 specified in [RFC6318]. In BCB-ECDH-SHA384-AES256, ephemeral-static 159 ECDH MUST be used with the SHA-384 KDF, AES-256 Key Wrap, and the 160 P-384 elliptic curve, as specified in [RFC6318]. The P-256 and P-384 161 elliptic curves are specified in [DSS]. 163 When a key agreement algorithm is used in CMS, a key-encryption 164 algorithm is also needed to encrypt the content encryption key (CEK). 165 These ciphersuites use Advanced Encryption Standard (AES) Key Wrap, 166 as specified in RFC 3394 [RFC3394] and [AESWRAP], as the key- 167 encryption algorithm. The key-encryption key used with the AES Key 168 Wrap algorithm is obtained from a key derivation function (KDF). 169 These ciphersuites use a KDF based on SHA-256 and SHA-384. 171 Section 3.1 of RFC 5753 [RFC5753] specifies the conventions for using 172 ECDH with CMS. Here the bundle encryption key (BEK), used to encrypt 173 the target block, is the data to be carried in a CMS enveloped-data 174 content type. CMS encrypts the BEK with a freshly generated content 175 encryption key (CEK) and the result is placed in the encryptedContent 176 field of an EnvelopedData EncryptedContentInfo structure. The CEK is 177 encrypted with the ECDH-generated pairwise key-encryption key (KEK) 178 using the AES Key Wrap algorithm. The result is placed in the 179 EnvelopedData RecipientInfos KeyAgreeRecipientInfo 180 RecipientEncryptedKey EncryptedKey field. 182 Algorithm identifiers needed when using ECDH with CMS are provided in 183 RFC 6318 [RFC6318] section 4. Within the CMS enveloped-data content 184 type, the key agreement algorithm identifier is placed in the 185 EnvelopedData RecipientInfos KeyAgreeRecipientInfo 186 keyEncryptionAlgorithm field. The key wrap algorithm identifier is 187 placed in the KeyWrapAlgorithm parameters within the EnvelopedData 188 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 190 KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key- 191 encryption key from the shared secret produced by ephemeral-static 192 ECDH. Section 4.3 of RFC 6318 [RFC6318] specify the conventions for 193 using the KDF with the shared secret generated with ephemeral-static 194 ECDH with the CMS. 196 Target block BSP encryption is done using the AES algorithm in 197 Galois/ Counter Mode (GCM) as described in [RFC5084]. For 198 consistency with the description in [RFC5084], we refer to the GCM IV 199 as a nonce. The same key and nonce combination MUST NOT be used more 200 than once. The nonce is constructed by concatenating a salt field 201 and an initialization vector, as follows. 203 The salt field is a four-octet value, usually chosen at random. The 204 salt need not be kept secret. The initialization vector (IV) is an 205 eight-octet value, usually chosen at random. The value need not be 206 kept secret. 208 The BEK is a 16-octet (128 bits) value in BCB-ECDH-SHA256-AES128, and 209 is a 32-octet value (256 bits) in BCB-ECDH-SHA384-AES256. The BEK 210 SHOULD be chosen randomly and MUST be kept secret. 212 The Integrity Check Value (ICV) from the AES-GCM content encryption 213 is a 16-octet value used to verify that the protected data has not 214 been altered. Normally, the ICV is concatenated with the ciphertext 215 to produce the output of AES-GCM encryption. However, to avoid 216 expansion of the payload, the ICV value is placed in the security- 217 result field of the BCB. The value need not be kept secret. 219 Each ciphersuite populates a single BCB in the bundle. This BCB MUST 220 contain security-parameters and security-result fields. The 221 security-parameters field includes the salt, IV, and key-information 222 items where the key- information item contains the encrypted BEK 223 encoded in a CMS EnvelopedData structure. The security-results-field 224 contains the ICV. The ciphertext is NOT stored in the BCB, but 225 replaces the plaintext from the target block. The other bytes of the 226 target block, such as type, flags, and length, are not modified. 228 4. Security Considerations 230 Two levels of security may be achieved using this specification. 231 Users must consider their risk environment to determine which level 232 is appropriate for their own use. 234 The security considerations in [I-D.ietf-dtn-bpsec] discuss the BPSec 235 Protocol and apply here as well. 237 The security considerations in [RFC5652] discuss the CMS as a method 238 for digitally signing data and encrypting data. 240 The security considerations in [RFC3370] discuss cryptographic 241 algorithm implementation concerns in the context of the CMS. 243 The security considerations in [RFC5753] discuss the use of elliptic 244 curve cryptography (ECC) in the CMS. 246 The security considerations in [RFC3565] discuss the use of AES in 247 the CMS, and the security considerations in [RFC5084] discuss the 248 Galois/Counter Mode. 250 5. IANA Considerations 252 This protocol has fields that have been registered by IANA. 254 The BPSec has a ciphersuite number field and certain ciphersuites are 255 defined. The registration policy for this registry is: Specification 256 Required. The Value range is: Variable Length. 258 IANA is requested to assign the following values for the ciphersuite 259 number field. 261 Ciphersuite Numbers Registry: 263 +-------+--------------------------------------+----------------+ 264 | Value | Description | Reference | 265 +-------+--------------------------------------+----------------+ 266 | 0xB1 | BIB-ECDSA-SHA256 | This document | 267 | 0xB2 | BIB-ECDSA-SHA384 | This document | 268 | 0xB3 | BCB-ECDH-SHA256-AES128 | This document | 269 | 0xB4 | BCB-ECDH-SHA384-AES256 | This document | 270 +-------+--------------------------------------+----------------+ 272 6. References 274 6.1. Normative References 276 [AESWRAP] National Institute of Standards and Technology, "AES Key 277 Wrap Specification", November 2001. 279 [DSS] National Institute of Standards and Technology, "Digital 280 Signature Standard (DSS)", FIPS PUB 186-3, June 2009. 282 [FIPS180-3] 283 National Institute of Standards and Technology, "Secure 284 Hash Standard", FIPS PUB 180-3, October 2008. 286 [FIPS197] National Institute of Standards and Technology, "Advanced 287 Encryption Standard (AES)", FIPS PUB 197, November 2001. 289 [I-D.ietf-dtn-bpsec] 290 Birrane, E., Pierce-Mayer, J., and D. Iannicca, "Bundle 291 Protocol Security Specification", draft-ietf-dtn-bpsec-00 292 (work in progress), December 2015. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, 296 DOI 10.17487/RFC2119, March 1997, 297 . 299 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 300 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 301 . 303 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 304 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 305 September 2002, . 307 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 308 Encryption Algorithm in Cryptographic Message Syntax 309 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 310 . 312 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 313 Encryption in the Cryptographic Message Syntax (CMS)", 314 RFC 5084, DOI 10.17487/RFC5084, November 2007, 315 . 317 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 318 "Elliptic Curve Cryptography Subject Public Key 319 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 320 . 322 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 323 RFC 5652, DOI 10.17487/RFC5652, September 2009, 324 . 326 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 327 Cryptography (ECC) Algorithms in Cryptographic Message 328 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 329 2010, . 331 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 332 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 333 2010, . 335 [RFC6318] Housley, R. and J. Solinas, "Suite B in Secure/ 336 Multipurpose Internet Mail Extensions (S/MIME)", RFC 6318, 337 DOI 10.17487/RFC6318, June 2011, 338 . 340 6.2. Informative References 342 [I-D.hennessy-bsp-suiteb-ciphersuites] 343 Burgin, K. and A. Hennessy, "Suite B Ciphersuites for the 344 Bundle Security Protocol", draft-hennessy-bsp-suiteb- 345 ciphersuites-00 (work in progress), March 2012. 347 [I-D.hennessy-bsp-suiteb-profile] 348 Burgin, K. and A. Hennessy, "Suite B Profile for the 349 Bundle Security Protocol", draft-hennessy-bsp-suiteb- 350 profile-00 (work in progress), March 2012. 352 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 353 Specification", RFC 5050, DOI 10.17487/RFC5050, November 354 2007, . 356 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 357 "Bundle Security Protocol Specification", RFC 6257, 358 DOI 10.17487/RFC6257, May 2011, 359 . 361 [SP800-56A] 362 National Institute of Standards and Technology, 363 "Recommendation for Pair-wise Key Establishment Schemes 364 Using Discrete Logarithm Cryptography", NIST Special 365 Publication 800-56A, March 2007. 367 [SuiteB] U.S. National Security Agency, "Fact Sheet NSA Suite B 368 Cryptography", NIST Special Publication 800-56A, January 369 2009, 370 . 372 Author's Address 374 Edward J. Birrane 375 The Johns Hopkins University Applied Physics Laboratory 376 11100 Johns Hopkins Rd. 377 Laurel, MD 20723 378 US 380 Phone: +1 443 778 7423 381 Email: Edward.Birrane@jhuapl.edu