idnits 2.17.1 draft-nayak-tcp-sha2-03.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 11, 2018) is 1963 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. 'FIPS-180-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SP800-108' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance (TCPM) A. Sujeet Nayak 3 Internet-Draft B. Weis 4 Intended status: Standards Track Cisco Systems 5 Expires: June 14, 2019 December 11, 2018 7 SHA-2 Algorithm for the TCP Authentication Option (TCP-AO) 8 draft-nayak-tcp-sha2-03 10 Abstract 12 The TCP Authentication Option (TCP-AO) relies on security algorithms 13 to provide connection authentication between the two end-points. 14 This document specifies how to use SHA-256 algorithm and attributes 15 with TCP-AO. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 14, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . . 3 55 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Key Derivation Functions (KDF) . . . . . . . . . . . . . 3 57 3.1.1. KDF_HMAC_SHA256 . . . . . . . . . . . . . . . . . . . 4 58 3.1.2. Tips for User Interfaces Regarding KDFs . . . . . . . 4 59 3.2. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. The Use of HMAC-SHA256-128 . . . . . . . . . . . . . 5 61 4. Interaction with TCP . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 [RFC5925] describes TCP-AO mechanism to provide cryptographic 73 authentication and message integrity verification between two end- 74 points of a TCP connection. [RFC5926] specifies HMAC-SHA-1-96 and 75 AES-128-CMAC-96 message authentication codes (MACs) algorithms for 76 TCP-AO. 78 Although SHA-1 is considered safe for non-digital signature 79 applications at the time of this writing [NIST-SP800-131A], there is 80 a naturally growing demand, especially from the government and 81 service provider community, for protecting their TCP sessions with 82 SHA-2 family of authentication algorithms, which is considered to be 83 relatively stronger. SHA-256, being widely preferred and deployed, 84 provides a reasonable alternative with stronger algorithm and larger 85 MAC length. 87 This document specifies usage of SHA-256 MAC algorithm on TCP-AO 88 enabled connections. It is a companion to [RFC5925] and [RFC5926]. 90 2. Requirements 92 2.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 When used in lowercase, these words convey their typical use in 99 common language, and they are not to be interpreted as described in 100 [RFC2119]. 102 2.2. Algorithm Requirements 104 This document adopts the style and conventions of [RFC5926] in 105 specifying how the use of new data integrity algorithm is indicated 106 in TCP-AO. It indicates a MAC algorithm and a key derivation 107 function (KDF). 109 The following table indicates the defined SHA-2 algorithm for TCP-AO: 111 +-------------+----------------------------------------+ 112 | Requirement | Authentication Algorithm | 113 +-------------+----------------------------------------+ 114 | RECOMMENDED | HMAC-SHA-256-128 [RFC2104][FIPS-180-4] | 115 +-------------+----------------------------------------+ 117 Table 1 119 +-------------+-------------------------------+ 120 | Requirement | Key Derivation Function (KDF) | 121 +-------------+-------------------------------+ 122 | RECOMMENDED | KDF_HMAC-SHA-256 | 123 +-------------+-------------------------------+ 125 Table 2 127 3. Algorithms Specified 129 TCP-AO requires two classes of algorithms to be used on a particular 130 connection namely, Key Derivation Functions (KDF) and Message 131 Authentication Code (MAC) algorithm. Both these classes are 132 generically described in Section 3 in [RFC5926], while focusing 133 specifically on SHA-1 and AES-128 algorithms. 135 In this document, the same concept is applied to use SHA-256 136 algorithm. 138 3.1. Key Derivation Functions (KDF) 140 KDFs have the following interface: 142 Traffic_Key = KDF_alg(Master_Key, Context, Output_Length) 144 where: 146 Traffic_Key, KDF_alg, Master_Key, Context, Output_Length stand for 147 entities, as described in [RFC5926], Section 3.1. 149 The KDF algorithm paired with corresponding pseudorandom function 150 (PRF) is: 152 * KDF_HMAC-SHA-256 based on PRF-HMAC-SHA256 [RFC2104][FIPS-180-4] 154 It is based on the iteration-mode KDF specified in [NIST-SP800-108]. 155 It uses an underlying PRF with a fixed length output of 256-bits. 156 The KDF generates an arbitrary number of output bits by operating the 157 PRF in a "counter" mode, where each invocation of the PRF uses a 158 different input block, which is differentiated by a block counter. 160 Each input block is constructed as follows: 162 (i || Label || Context || Output_Length) 164 Where: 166 "||", i, Label, Context, Output_Length stand for entities, as 167 described in [RFC5926], Section 3.1.1. 169 3.1.1. KDF_HMAC_SHA256 171 For KDF_HMAC_SHA256: 173 - PRF for KDF_alg: HMAC-SHA256 [RFC2104][FIPS-180-4] 175 - Use: HMAC-SHA256(Key, Input) 177 - Key: Master_Key, configured by user, and passed to KDF 179 - Input: ( i || Label || Context || Output_Length) 181 - Output_Length: 256 bits 183 - Result: Traffic_Key, used in MAC function by TCP-AO 185 3.1.2. Tips for User Interfaces Regarding KDFs 187 This section provides suggested representations for the KDFs in 188 implementation of user interfaces (UIs). Following these guidelines 189 across common implementations will make interoperability easier and 190 simpler for users deploying TCP-AO. 192 UIs SHOULD refer to the choice of KDF_HMAC_SHA256 as simply "SHA256". 194 The IANA registry values reflect this entry. 196 3.2. MAC Algorithm 198 Each MAC_alg defined for TCP-AO has three fixed elements as part of 199 its definition: 201 - KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the 202 Traffic_Key. 204 - Key_Length: Length, in bits, required for the Traffic_Key used in 205 this MAC. 207 - MAC_Length: The final length of the bits used in the TCP-AO MAC 208 field. This value may be a truncation of the MAC function's original 209 output length. 211 As described in [RFC5926], Section 3.2, MACs computed for TCP-AO have 212 the following interface: 214 MAC = MAC_alg(Traffic_Key, Message) 216 The MAC_alg for generating MAC, as used by TCP-AO: 218 * HMAC-SHA256-128 based on [RFC2104] and [FIPS-180-4] 220 HMAC-SHA256 produces 256 bits output. The MAC output is then 221 truncated to provide a reasonable trade-off between security and 222 message size, for fitting into the TCP-AO option field. As 223 recommended in [RFC2104], Section 5, the HMAC-SHA256 is truncated to 224 128 bits. 226 3.2.1. The Use of HMAC-SHA256-128 228 The three fixed elements for HMAC-SHA256-128 are: 230 - KDF_Alg: KDF_HMAC_SHA256 232 - Key_Length: 256 bits 234 - MAC_Length: 128 bits 236 For: 238 MAC = MAC_alg (Traffic_Key, Message) 240 HMAC-SHA256-128 for TCP-AO has the following values: 242 - MAC_alg: HMAC-SHA256 244 - Traffic_Key: Variable; the result of the KDF 246 - Message: The message to be authenticated, as specified in 247 [RFC5925], Section 5.1 249 4. Interaction with TCP 251 As described in [RFC5925], Section 7.6, TCP option space is most 252 critical in SYN segments. As compared to 96-bit Mac length of 253 [RFC5925], using a 128-bit MAC length increases the TCP-AO space from 254 16 bytes to 20 bytes. Since 9 bytes of space was already available 255 in the SYN segment (9 bytes further reduces to 5 in the presence of 256 MSS option), implementors of this document could use it to provide a 257 stronger authentication algorithm for the TCP connections. 259 For non-SYN segments, TCP-AO with 128-bit Mac length would use 20 260 bytes, leaving 20 bytes for other options. Out of these, 10 bytes 261 would be consumed by timestamp, leaving around 10 bytes for a single 262 SACK block. This limit remains the same as described in [RFC5925], 263 Section 7.6. 265 Another important point to be considered by the implementations is 266 that, in the presence of this feature, since the option space is 267 getting pushed further, care SHOULD be taken to ensure all the 268 options are tightly packed to avoid total options length from 269 spilling beyond the available 40 bytes. 271 5. Security Considerations 273 This document inherits all the security considerations of the TCP-AO 274 [RFC5925] and HMAC-SHA-1 related to [RFC5926]. 276 NOTE REGARDING OTHER SHA-2 ALGORITHMS: 278 In the SHA-2 family, another widely used algorithm in the industry is 279 SHA512. Adopting SHA512 algorithm would mean using a MAC length of 280 256-bits, as recommended in [RFC2104], Section 5. At the time of 281 writing this document, there is no sufficient space available in the 282 TCP SYN segment to accommodate this large length, without causing 283 backward incompatibility. To avoid this scenario, usage of SHA512 284 algorithm is deferred, till the time a larger TCP option space 285 evolves. 287 6. IANA Considerations 289 As described in [RFC5926], Section 5, IANA has a registry with the 290 following details: 292 Registry Name: Cryptographic Algorithms for TCP-AO Registration 294 Procedure: RFC Publication after Expert Review 296 The following needs to be added to this registry: 298 +-----------+----------------------+ 299 | Algorithm | Reference | 300 +-----------+----------------------+ 301 | SHA256 | This document Number | 302 +-----------+----------------------+ 304 Table 3 306 7. Acknowledgements 308 Bertrand Duvivier, M. Rohit and Srinivas Ramprasad first suggested 309 the need for this work. 311 8. References 313 8.1. Normative References 315 [FIPS-180-4] 316 FIPS Publication 180-4, "Secured Hash Standard", March 317 2012. 319 [NIST-SP800-108] 320 National Institute of Standards and Technology, 321 "Recommendation for Key Derivation Using Pseudorandom 322 Functions, NIST SP800-108", October 2009. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 330 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 331 June 2010, . 333 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 334 for the TCP Authentication Option (TCP-AO)", RFC 5926, 335 DOI 10.17487/RFC5926, June 2010, 336 . 338 8.2. Informative References 340 [NIST-SP800-131A] 341 National Institute of Standards and Technology, 342 "Transitions: Recommendation for Transitioning the Use of 343 Cryptographic Algorithms and Key Lengths, NIST 344 SP800-131A", January 2011. 346 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 347 Hashing for Message Authentication", RFC 2104, 348 DOI 10.17487/RFC2104, February 1997, 349 . 351 Authors' Addresses 353 Sujeet Nayak Ammunje 354 Cisco Systems 355 Cessna Business Park 356 Bangalore, Karnataka 560 087 357 India 359 Email: sujeetnayak@yahoo.com 361 Brian Weis 362 Cisco Systems 364 Email: bew.stds@gmail.com