idnits 2.17.1 draft-mahesh-bfd-authentication-01.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 abstract seems to contain references ([RFC5880]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2015) is 3133 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: 'FIPS-180-2' is defined on line 170, but no explicit reference was found in the text == Unused Reference: 'FIPS-198' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-generic-crypto-auth' is defined on line 180, but no explicit reference was found in the text == Unused Reference: 'RFC6039' is defined on line 190, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'NIST-HMAC-SHA' is defined on line 222, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC4822' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'RFC5310' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 259, 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: 4 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Mishra 5 Expires: March 31, 2016 Ciena Corporation 6 A. Saxena 7 Citrix 8 M. Bhatia 9 Ionos Networks 10 September 28, 2015 12 Optimizing BFD Authentication 13 draft-mahesh-bfd-authentication-01 15 Abstract 17 This document describes an optimization to BFD Authentication as 18 described in Section 6.7 of BFD [RFC5880]. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 31, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 62 3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 6.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Authenticating every BFD [RFC5880] packet with a Simple Password, or 73 with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash 74 Algorithm (SHA-1) algorithms is computationally intensive process, 75 making it difficult if not impossible to authenticate every packet - 76 particularly at faster rates. Also, the recent escalating series of 77 attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise 78 concerns about their remaining useful lifetime as outlined in Updated 79 Security Considerations for the MD5 Message-Digest and the HMAC-MD5 80 Algorithm [RFC6151] and Security Considerations for the SHA-0 and 81 SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by stronger 82 algorithms, the computational overhead, will make the task of 83 authenticating every packet even more difficult to achieve. 85 This document proposes that only BFD frames that signal a state 86 change in BFD be authenticated. Rest of the frames can be 87 transmitted and received without authentication enabled. Most frames 88 that are transmitted and received have no state change associated 89 with them. Limiting authentication to frames that affect a BFD 90 session state allows more sessions to be supported for 91 authentication. Moreover, most BFD frames that signal a state change 92 are generally transmitted at a slower interval of 1s leaving enough 93 time to compute the hash. 95 Section 2 talks about the changes to authentication mode as described 96 in BFD [RFC5880]. 98 2. Authentication Mode 100 The cryptographic authentication mechanisms specified in BFD 101 [RFC5880] describes enabling and disabling of authentication as a one 102 time operation. As a security precaution, it mentions that 103 authentication state be allowed to change at most once. Once 104 enabled, every packet must have Authentication Bit set and the 105 associated Authentication TLV appended. In addition, it states that 106 an implementation SHOULD NOT allow the authentication state to be 107 changed based on the receipt of a BFD Control packet. 109 This document proposes that the authentication mode be modified to be 110 enabled on demand. Instead of authenticating every packet, BFD peers 111 decide which frames need to be authenticated, and authenticate only 112 those frames. For example, the two ends can decide that BFD frames 113 that indicate a state change should be authenticated and enable 114 authentication on those frames only. If the two ends have not 115 previously negotiated which frames they will transmit or receive with 116 authentication enabled, then the BFD session will fail to come up, 117 because at least one end will expect every frame to be authenticated. 119 Authenticated frames already carry the sequence number. The rest of 120 the frames MUST contain the TLV specified in Section 3. This enables 121 a monotonically increasing sequence number to be carried in each 122 frame, and prevents man-in-the-middle from capturing and replaying 123 the same frame again. 125 3. NULL Auth TLV 127 This section describes a new Authentication TLV as: 129 0 1 2 3 130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | TLV Type | TLV Len | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Sequence Number | 135 | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 NULL Auth TLV 140 where: 142 TLV Type: The TLV Type. This field MUST be set to . 144 TLV Length: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 146 Sequence Number: is a monotonically increasing number while the 147 session state is UP. Once the session goes down the Sequence number 148 SHOULD be set to 0. 150 4. IANA Considerations 152 IANA is requested to assign a new Auth Type for the NULL Auth TLV. 154 Note to RFC Editor: this section may be removed on publication as an 155 RFC. 157 5. Security Considerations 159 The approach described in this document enhances the ability to 160 authentication a BFD session by taking away the onerous requirement 161 that every frame be authenticated. By authenticating frames that 162 affect the state of the session, the security of the BFD session is 163 maintained. As such this document does not change the security 164 considerations for BFD. 166 6. References 168 6.1. Normative References 170 [FIPS-180-2] 171 National Institute of Standards and Technology, FIPS PUB 172 180-2, "The Keyed-Hash Message Authentication Code 173 (HMAC)", August 2002. 175 [FIPS-198] 176 National Institute of Standards and Technology, FIPS PUB 177 198, "The Keyed-Hash Message Authentication Code (HMAC)", 178 March 2002. 180 [I-D.ietf-bfd-generic-crypto-auth] 181 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 182 "BFD Generic Cryptographic Authentication", draft-ietf- 183 bfd-generic-crypto-auth-06 (work in progress), April 2014. 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 191 with Existing Cryptographic Protection Methods for Routing 192 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 193 . 195 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 196 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 197 RFC 6151, DOI 10.17487/RFC6151, March 2011, 198 . 200 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 201 Considerations for the SHA-0 and SHA-1 Message-Digest 202 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 203 . 205 6.2. Informative References 207 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 209 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 210 CryptoBytes", 1996. 212 [I-D.ietf-karp-design-guide] 213 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 214 Routing Protocols (KARP) Design Guidelines", draft-ietf- 215 karp-design-guide-10 (work in progress), December 2011. 217 [MD5-attack] 218 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 219 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 220 2004. 222 [NIST-HMAC-SHA] 223 National Institute of Standards and Technology, Available 224 online at http://csrc.nist.gov/groups/ST/hash/policy.html, 225 "NIST's Policy on Hash Functions", 2006. 227 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 228 DOI 10.17487/RFC1321, April 1992, 229 . 231 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 232 Hashing for Message Authentication", RFC 2104, 233 DOI 10.17487/RFC2104, February 1997, 234 . 236 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 237 "Randomness Requirements for Security", BCP 106, RFC 4086, 238 DOI 10.17487/RFC4086, June 2005, 239 . 241 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 242 Authentication", RFC 4822, DOI 10.17487/RFC4822, February 243 2007, . 245 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 246 and M. Fanto, "IS-IS Generic Cryptographic 247 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 248 2009, . 250 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 251 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 252 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 253 2009, . 255 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 256 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 257 . 259 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 260 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 261 DOI 10.17487/RFC6234, May 2011, 262 . 264 [SHA-1-attack1] 265 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 266 Full SHA-1", 2005. 268 [SHA-1-attack2] 269 Wang, X., Yao, A., and F. Yao, "New Collision Search for 270 SHA-1", 2005. 272 Authors' Addresses 274 Mahesh Jethanandani 275 Cisco Systems 276 170 W. Tasman Drive 277 San Jose, CA 95134 278 USA 280 Phone: +1 (408) 526-8763 281 Email: mjethanandani@gmail.com 282 Ashesh Mishra 283 Ciena Corporation 284 3939 North 1st Street 285 San Jose, CA 95134 286 USA 288 Phone: +1 (408) 904-2114 289 Email: mishra.ashesh@gmail.com 291 Ankur Saxena 292 Citrix 293 4988 Great America Pkwy 294 Santa Clara, CA 95054 295 USA 297 Email: ankurpsaxena@gmail.com 299 Manav Bhatia 300 Ionos Networks 301 Bangalore 302 India 304 Email: manav@ionosnetworks.com