idnits 2.17.1 draft-ietf-bfd-hmac-sha-05.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 (May 24, 2014) is 3624 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) == Unused Reference: 'RFC6039' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 282, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' ** Downref: Normative reference to an Informational RFC: RFC 6039 ** Downref: Normative reference to an Informational RFC: RFC 6151 ** Downref: Normative reference to an Informational RFC: RFC 6194 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft Huawei 4 Intended status: Standards Track M. Bhatia 5 Expires: November 25, 2014 Alcatel-Lucent 6 V. Manral 7 Ionos Networks 8 M. Jethanandani 9 Ciena Corporation 10 May 24, 2014 12 Authenticating BFD using HMAC-SHA-2 procedures 13 draft-ietf-bfd-hmac-sha-05 15 Abstract 17 This document describes the mechanism to authenticate Bidirectional 18 Forwarding Detection (BFD) protocol packets using Hashed Message 19 Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 20 algorithms. The described mechanism uses the Generic Cryptographic 21 Authentication and Generic Meticulous Cryptographic Authentication 22 sections to carry the authentication data. This document updates, 23 but does not supersede, the cryptographic authentication mechanism 24 specified in RFC 5880. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 25, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Preperation of the Key . . . . . . . . . . . . . . . . . 4 69 2.2. First Hash . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. Second Hash T . . . . . . . . . . . . . . . . . . . . . . 4 71 2.4. Result . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 5.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 The cryptographic authentication mechanisms specified in BFD 82 [RFC5880] defines MD5 Message-Digest Algorithm [RFC1321] and Secure 83 Hash Algorithm (SHA-1) algorithms to authenticate BFD packets. The 84 recent escalating series of attacks on MD5 and SHA-1 [SHA-1-attack1] 85 [SHA-1-attack2] raise concerns about their remaining useful lifetime 86 as outlined in Updated Security Considerations for the MD5 Message- 87 Digest and the HMAC-MD5 Algorithm [RFC6151] and Security 88 Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm 89 [RFC6194]. 91 These attacks may not necessarily result in direct vulnerabilities 92 for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes 93 because the colliding message may not correspond to a syntactically 94 correct BFD protocol packet. Regardless, there is a need felt to 95 deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor 96 of stronger digest algorithms. 98 This document adds support for Secure Hash Algorithms (SHA) defined 99 in the US NIST Secure Hash Standard (SHS), which is defined by NIST 100 FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, 101 SHA-256, SHA-384, and SHA-512. The HMAC authentication mode defined 102 in NIST FIPS 198 is used [FIPS-198]. 104 It is believed that the HMAC algorithms defined in HMAC: Keyed- 105 Hashing for Message Authentication [RFC2104] is mathematically 106 identical to their counterparts in [FIPS-198] and it is also believed 107 that algorithms in US Secure Hash Algorithms [RFC6234] are 108 mathematically identical to those defined in [FIPS-180-2]. 110 It should be noted that the collision attacks currently known against 111 SHA-1 do not apply when SHA-1 is used in the HMAC construction. NIST 112 will be supporting HMAC-SHA-1 even after 2010 [NIST-HMAC-SHA] , 113 whereas it would be dropping support for SHA-1 in digital signatures. 115 BFD Generic Cryptographic Authentication 116 [I-D.ietf-bfd-generic-crypto-auth] defines new authentication types - 117 Generic Cryptographic Authentication (TBD1) and Generic Meticulous 118 Cryptographic Authentication (TBD2) that can be used for carrying the 119 authentication digests defined in this document. Also please refer 120 to this document for the procedures at the sending and the receiving 121 side. 123 Implementations of this specification must include support for at 124 least HMAC-SHA-256 and may include support for either of HMAC-SHA-384 125 or HMAC-SHA-512. 127 2. Cryptographic Aspects 129 In the algorithm description below, the following nomenclature, which 130 is consistent with [FIPS-198], is used. 132 H is the specific hashing algorithm (e.g. SHA-256). 134 K is the password for the BFD packet. 136 Ko is the cryptographic key used with the hash algorithm. 138 B is the block size of H, measured in octets rather than bits. Note, 139 that B is the internal block size, not the hash size. For SHA-1 and 140 SHA-256 B is equal to 64. For SHA-384 and SHA-512 B is equal to 128. 142 L is the length of the hash, measured in octets rather than bits. 144 XOR is the exclusive-or operation. 146 Opad is the hexadecimal value 0x5c repeated B times. 148 Ipad is the hexadecimal value 0x36 repeated B times. 150 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 152 2.1. Preperation of the Key 154 In this application, Ko is always L octets long. 156 If the Authentication Key (K) is L octets long, then Ko is equal to 157 K. If the Authentication Key (K) is more than L octets long, then Ko 158 is set to H(K). If the Authentication Key (K) is less than L octets 159 long, then Ko is set to the Authentication Key (K) with zeros 160 appended to the end of the Authentication Key (K) such that Ko is L 161 octets long. 163 2.2. First Hash 165 First, the Authentication Data field in the Generic Authentication 166 Section is filled with the value of Apad and the Authentication Type 167 field is set to TBD1 or TBD2 depending upon which Authentication Type 168 being used. The Sequence Number field MUST be set to 169 bfd.XmitAuthSeq. 171 Then, a first hash, also known as the inner hash, is computed as 172 follows: 174 First-Hash = H(Ko XOR Ipad || (BFD Packet)) 176 2.3. Second Hash T 178 Then a second hash, also known as the outer hash, is computed as 179 follows: 181 Second-Hash = H(Ko XOR Opad || First-Hash) 183 2.4. Result 185 The resultant Second-Hash becomes the Authentication Data that is 186 sent in the Authentication Data field of the BFD Authentication 187 Section. The length of the Authentication Data field is always 188 identical to the message digest size of the specific hash function H 189 that is being used. 191 This also means that the use of hash functions with larger output 192 sizes will also increase the size of BFD Packet as transmitted on the 193 wire. 195 3. IANA Considerations 197 This document makes no request of IANA. 199 Note to RFC Editor: this section may be removed on publication as an 200 RFC. 202 4. Security Considerations 204 The approach described in this document enhances the security of the 205 BFD protocol by adding, to the existing BFD cryptographic 206 authentication methods, support for the SHA-2 algorithms defined in 207 the NIST Secure Hash Standard (SHS) using the HMAC mode. However, 208 the confidentiality protection for BFD packets is out of scope of 209 this work . 211 Because all of the currently specified algorithms use symmetric 212 cryptography, one cannot authenticate precisely which BFD device sent 213 a given packet. However, one can authenticate that the sender knew 214 the BFD Security Association (including the BFD SA's parameters) 215 currently in use. 217 To enhance system security, the applied keys should be changed 218 periodically and implementations SHOULD be able to store and use more 219 than one key at the same time. The quality of the security provided 220 by the cryptographic authentication option depends completely on the 221 strength of the cryptographic algorithm and cryptographic mode in 222 use, the strength of the key being used, and the correct 223 implementation of the security mechanism in all communicating BFD 224 implementations. Accordingly, the use of high assurance development 225 methods is recommended. It also requires that all parties maintain 226 the secrecy of the shared secret key. Randomness Requirements for 227 Security [RFC4086] provides guidance on methods for generating 228 cryptographically random bits. 230 The value Apad is used here primarily for consistency with IETF 231 specifications for HMAC-SHA authentication for RIPv2 RIPv2 232 Cryptographic Authentication [RFC4822], IS-IS IS-IS Generic 233 Cryptographic Authentication [RFC5310] and OSPFv2 OSPFv2 HMAC-SHA 234 Cryptographic Authentication [RFC5709]. 236 5. References 238 5.1. Normative References 240 [FIPS-180-2] 241 National Institute of Standards and Technology, FIPS PUB 242 180-2, "The Keyed-Hash Message Authentication Code 243 (HMAC)", August 2002. 245 [FIPS-198] 246 National Institute of Standards and Technology, FIPS PUB 247 198, "The Keyed-Hash Message Authentication Code (HMAC)", 248 March 2002. 250 [I-D.ietf-bfd-generic-crypto-auth] 251 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 252 "BFD Generic Cryptographic Authentication", draft-ietf- 253 bfd-generic-crypto-auth-06 (work in progress), April 2014. 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, March 1997. 258 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 259 with Existing Cryptographic Protection Methods for Routing 260 Protocols", RFC 6039, October 2010. 262 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 263 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 264 RFC 6151, March 2011. 266 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 267 Considerations for the SHA-0 and SHA-1 Message-Digest 268 Algorithms", RFC 6194, March 2011. 270 5.2. Informative References 272 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 274 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 275 CryptoBytes", 1996. 277 [I-D.ietf-karp-design-guide] 278 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 279 Routing Protocols (KARP) Design Guidelines", draft-ietf- 280 karp-design-guide-10 (work in progress), December 2011. 282 [MD5-attack] 283 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 284 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 285 2004. 287 [NIST-HMAC-SHA] 288 National Institute of Standards and Technology, Available 289 online at http://csrc.nist.gov/groups/ST/hash/policy.html, 290 "NIST's Policy on Hash Functions", 2006. 292 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 293 April 1992. 295 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 296 Hashing for Message Authentication", RFC 2104, February 297 1997. 299 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 300 Requirements for Security", BCP 106, RFC 4086, June 2005. 302 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 303 Authentication", RFC 4822, February 2007. 305 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 306 and M. Fanto, "IS-IS Generic Cryptographic 307 Authentication", RFC 5310, February 2009. 309 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 310 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 311 Authentication", RFC 5709, October 2009. 313 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 314 (BFD)", RFC 5880, June 2010. 316 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 317 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 319 [SHA-1-attack1] 320 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 321 Full SHA-1", 2005. 323 [SHA-1-attack2] 324 Wang, X., Yao, A., and F. Yao, "New Collision Search for 325 SHA-1", 2005. 327 Authors' Addresses 329 Dacheng Zhang 330 Huawei 331 Beijing 332 China 334 Email: zhangdacheng@huawei.com 335 Manav Bhatia 336 Alcatel-Lucent 337 Bangalore 560045 338 India 340 Email: manav.bhatia@alcatel-lucent.com 342 Vishwas Manral 343 Ionos Networks 344 CA 345 USA 347 Email: vishwas@ionosnetworks.com 349 Mahesh Jethanandani 350 Ciena Corporation 351 3939 North 1st Street 352 San Jose, CA 95134 353 USA 355 Phone: +1 (408) 904-2160 356 Email: mjethanandani@gmail.com