idnits 2.17.1 draft-bhatia-bfd-hmac-sha-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 == Line 344 has weird spacing: '... online at...' -- The document date (October 9, 2011) is 4555 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 312, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 337, 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' == Outdated reference: A later version (-06) exists of draft-ietf-bfd-generic-crypto-auth-00 ** 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 == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-05 Summary: 3 errors (**), 0 flaws (~~), 9 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: April 11, 2012 Alcatel-Lucent 6 V. Manral 7 Hewlett-Packard Co. 8 October 9, 2011 10 Authenticating BFD using HMAC-SHA-2 procedures 11 draft-bhatia-bfd-hmac-sha-00 13 Abstract 15 This document describes how Hashed Message Authentication Mode (HMAC) 16 in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can 17 be used for authenticating Bidirectional Forwarding Detection (BFD). 18 It uses the Generic Cryptographic Authentication and Generic 19 Meticulous Cryptographic Authentication sections to carry the 20 authentication data. This updates, but does not supercede, the 21 cryptographic authentication mechanism specified in RFC 5880. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 11, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . . 3 65 3. Procedures at the Sending Side . . . . . . . . . . . . . . . . 5 66 4. Procedure at the Receiving Side . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The cryptographic authentication mechanisms specified in BFD 77 [RFC5880] defines MD5 [RFC1321] and Secure Hash Algorithm (SHA-1) 78 algorithms to authenticate BFD packets. The recent escalating series 79 of attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise 80 concerns about their remaining useful lifetime [RFC6151] [RFC6194]. 82 These attacks may not necessarily result in direct vulnerabilities 83 for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes 84 because the colliding message may not correspond to a syntactically 85 correct BFD protocol packet. Regardless, there is a need felt to 86 deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor 87 of stronger digest algorithms. 89 This document adds support for Secure Hash Algorithms (SHA) defined 90 in the US NIST Secure Hash Standard (SHS), which is defined by NIST 91 FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, SHA- 92 256, SHA-384, and SHA-512. The HMAC authentication mode defined in 93 NIST FIPS 198 is used [FIPS-198]. 95 It is believed that [RFC2104] is mathematically identical to 96 [FIPS-198] and it is also believed that algorithms in [RFC6234] are 97 mathematically identical to [FIPS-180-2]. 99 It should be noted that if SHA-1 is used in the HMAC construction 100 then collision attacks currently known against SHA-1 do not apply. 101 The new attacks on SHA-1 have no impact on the security of 102 HMAC-SHA-1. NIST will be supporting HMAC-SHA-1 even after 2010 103 [NIST-HMAC-SHA] , whereas it would be dropping support for SHA-1 in 104 digital signatures. 106 [I-D.ietf-bfd-generic-crypto-auth] defines new authentication types - 107 Generic Cryptographic Authentication and Generic Meticulous 108 Cryptographic Authenticationan extension that can be used for 109 carrying the authentication digests defined in this document. 111 Implementations of this specification must include support for at 112 least HMAC-SHA-256 and may include support for either of HMAC-SHA-384 113 or HMAC-SHA-512. 115 2. Cryptographic Aspects 117 In the algorithm description below, the following nomenclature, which 118 is consistent with [FIPS-198], is used: 120 H is the specific hashing algorithm (e.g. SHA-256). 122 K is the password for the BFD packet. 124 Ko is the cryptographic key used with the hash algorithm. 126 B is the block size of H, measured in octets rather than bits. Note 127 that B is the internal block size, not the hash size. For SHA-1 and 128 SHA-256: B == 64 For SHA-384 and SHA-512: B == 128 L is the length of 129 the hash, measured in octets rather than bits. 131 XOR is the exclusive-or operation. 133 Opad is the hexadecimal value 0x5c repeated B times. 135 Ipad is the hexadecimal value 0x36 repeated B times. 137 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 139 (1) Preparation of the Key 141 In this application, Ko is always L octets long. 143 If the Authentication Key (K) is L octets long, then Ko is equal to 144 K. If the Authentication Key (K) is more than L octets long, then Ko 145 is set to H(K). If the Authentication Key (K) is less than L octets 146 long, then Ko is set to the Authentication Key (K) with zeros 147 appended to the end of the Authentication Key (K) such that Ko is L 148 octets long. 150 (2) First Hash 152 First, the Authentication Data field in the Generic Authentication 153 Section is filled with the value Apad and the Authentication Type 154 field is set to 6 or 7 depending upon which Authentication Type is 155 being used. The Sequence Number field MUST be set to 156 bfd.XmitAuthSeq. 158 Then, a first hash, also known as the inner hash, is computed as 159 follows: 161 First-Hash = H(Ko XOR Ipad || (BFD Packet)) 163 (3) Second Hash T 165 Then a second hash, also known as the outer hash, is computed as 166 follows: 168 Second-Hash = H(Ko XOR Opad || First-Hash) 169 (4) Result 171 The resultant Second-Hash becomes the Authentication Data that is 172 sent in the Authentication Data field of the BFD Authentication 173 Section. The length of the Authentication Data field is always 174 identical to the message digest size of the specific hash function H 175 that is being used. 177 This also means that the use of hash functions with larger output 178 sizes will also increase the size of BFD Packet as transmitted on the 179 wire. 181 3. Procedures at the Sending Side 183 Before a BFD device sends a BFD packet out, the device needs to 184 select an appropriate BFD SA from its local key table if a keyed 185 digest for the packet is required. If no appropriate SA is 186 avaliable, the BFD packet MUST be discarded. 188 If an appropriate SA is avaliable, the device then derives the key 189 and the associated authentication algorithm (HMAC-SHA-256, HMAC-SHA- 190 384 or HMAC-SHA-512) from the SA. 192 The device then start performing the operations illustrated in 193 Section 2. Before the authentication data is computed, the device 194 MUST fill the Auth Type and the Auth length . The Sequence Number 195 field MUST be set to bfd.XmitAuthSeq. 197 The value of Auth Length in the generic authentication section is 198 various according to different authentication algorithms being used. 199 Specifically, the value is 40 for HMAC-SHA-256, 56 for HMAC-SHA-384 200 and 72 for HMAC- SHA-512. 202 The Key ID is then filled. 204 After that, the authentication data is computed as illustrated in 205 Section 3. 207 The result of the authentication algorithm is placed in the 208 Authentication data, following the Key ID. 210 4. Procedure at the Receiving Side 212 Upon receiving a BFD packet with an generic authentication section 213 appended, the receiving device needs to find an appropriate BFD SA 214 from its local key table to verify the packet. The SA is located by 215 the Key ID in the authentication section of the packet. 217 If there is no SA is associated with the Key ID, the received packet 218 MUST be discarded. 220 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 221 Cryptographic Authentication, if the Sequence Number lies outside of 222 the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) 223 inclusive (when treated as an unsigned 32 bit circular number space), 224 the received packet MUST be discarded. For Meticulous Cryptographic 225 Authentication, if the Sequence Number lies outside of the range of 226 bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 227 treated as an unsigned 32 bit circular number space, the received 228 packet MUST be discarded. 230 Authentication Algorithm dependent processing, needs to be performed, 231 using the algorithm specified by the appropriate BFD SA for the 232 received packet. 234 Before the device performs any processing, it needs to save the 235 values of the Authentication Value field. 237 The device then needs to set the Authentication Value field with Apad 238 before the authentication data is computed. The calculated data is 239 compared with the received authentication data in the packet. 241 The packet MUST be discarded if the calculated data and the received 242 authentication data do not match each other. In such a case, an 243 error event SHOULD be logged. 245 A BFD implementation MAY be in a transition mode where it includes 246 CRYPTO_AUTH or the MET_CRYPTO_AUTH information in packets but never 247 verifies it. This is provided as a transition aid for networks in 248 the process of migrating to the new CRYPTO_AUTH and MET_CRYPTO_AUTH 249 based authentication schemes. 251 5. IANA Considerations 253 This document makes no request of IANA. 255 Note to RFC Editor: this section may be removed on publication as an 256 RFC. 258 6. Security Considerations 260 The approach described in this document enhances the security of the 261 BFD protocol by adding, to the existing BFD cryptographic 262 authentication methods, support for the SHA-2 algorithms defined in 263 the NIST Secure Hash Standard (SHS) using the HMAC mode. However, 264 the confidentiality protection for BFD packets is out of scope of 265 this work . 267 Because all of the currently specified algorithms use symmetric 268 cryptography, one cannot authenticate precisely which BFD device sent 269 a given packet. However, one can authenticate that the sender knew 270 the BFD Security Association (including the BFD SA's parameters) 271 currently in use. 273 To enhance system security, the applied keys should be changed 274 periodically and implementations SHOULD be able to store and use more 275 than one key at the same time. The quality of the security provided 276 by the cryptographic authentication option depends completely on the 277 strength of the cryptographic algorithm and cryptographic mode in 278 use, the strength of the key being used, and the correct 279 implementation of the security mechanism in all communicating BFD 280 implementations. Accordingly, the use of high assurance development 281 methods is recommended. It also requires that all parties maintain 282 the secrecy of the shared secret key. [RFC4086] provides guidance on 283 methods for generating cryptographically random bits. 285 The value Apad is used here primarily for consistency with IETF 286 specifications for HMAC-SHA authentication for RIPv2 [RFC4822], IS-IS 287 [RFC5310] and OSPFv2 [RFC5709]. 289 7. References 291 7.1. Normative References 293 [FIPS-180-2] 294 National Institute of Standards and Technology, FIPS PUB 295 180-2, "The Keyed-Hash Message Authentication Code 296 (HMAC)", August 2002. 298 [FIPS-198] 299 National Institute of Standards and Technology, FIPS PUB 300 198, "The Keyed-Hash Message Authentication Code (HMAC)", 301 March 2002. 303 [I-D.ietf-bfd-generic-crypto-auth] 304 Bhatia, M., Manral, V., and D. Zhang, "BFD Generic 305 Cryptographic Authentication", 306 draft-ietf-bfd-generic-crypto-auth-00 (work in progress), 307 October 2011. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 313 with Existing Cryptographic Protection Methods for Routing 314 Protocols", RFC 6039, October 2010. 316 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 317 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 318 RFC 6151, March 2011. 320 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 321 Considerations for the SHA-0 and SHA-1 Message-Digest 322 Algorithms", RFC 6194, March 2011. 324 7.2. Informative References 326 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 328 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 329 CryptoBytes", 1996. 331 [I-D.ietf-karp-design-guide] 332 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 333 Routing Protocols (KARP) Design Guidelines", 334 draft-ietf-karp-design-guide-05 (work in progress), 335 September 2011. 337 [MD5-attack] 338 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 339 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", 340 August 2004. 342 [NIST-HMAC-SHA] 343 National Institute of Standards and Technology, Available 344 online at 345 http://csrc.nist.gov/groups/ST/hash/policy.html, "NIST's 346 Policy on Hash Functions", 2006. 348 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 349 April 1992. 351 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 352 Hashing for Message Authentication", RFC 2104, 353 February 1997. 355 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 356 Requirements for Security", BCP 106, RFC 4086, June 2005. 358 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 359 Authentication", RFC 4822, February 2007. 361 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 362 and M. Fanto, "IS-IS Generic Cryptographic 363 Authentication", RFC 5310, February 2009. 365 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 366 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 367 Authentication", RFC 5709, October 2009. 369 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 370 (BFD)", RFC 5880, June 2010. 372 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 373 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 375 [SHA-1-attack1] 376 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 377 Full SHA-1", 2005. 379 [SHA-1-attack2] 380 Wang, X., Yao, A., and F. Yao, "New Collision Search for 381 SHA-1", 2005. 383 Authors' Addresses 385 Dacheng Zhang 386 Huawei 387 Beijing, 388 China 390 Email: zhangdacheng@huawei.com 392 Manav Bhatia 393 Alcatel-Lucent 394 Bangalore 395 India 397 Email: manav.bhatia@alcatel-lucent.com 398 Vishwas Manral 399 Hewlett-Packard Co. 400 19111 Pruneridge Ave. 401 Cupertino, CA 95014 402 USA 404 Email: vishwas.manral@hp.com