idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-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 : ---------------------------------------------------------------------------- ** 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 (December 6, 2015) is 3064 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 182, but no explicit reference was found in the text == Unused Reference: 'FIPS-198' is defined on line 187, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-generic-crypto-auth' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'RFC6039' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 224, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'NIST-HMAC-SHA' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC4822' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'RFC5310' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 276, 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 (-05) exists of draft-ashesh-bfd-stability-03 ** 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 (~~), 17 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: June 8, 2016 Ciena Corporation 6 A. Saxena 7 Citrix 8 M. Bhatia 9 Ionos Networks 10 December 6, 2015 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-00 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 June 8, 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 . . . . . . . . . . . . . . . . . . 5 67 6.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. 118 The state changes for which authentication is being suggested 119 include: 121 Poll Sequence 123 Demand Mode 125 BFD packet with the Diag flag set 127 Authenticated frames already carry the sequence number. The rest of 128 the frames MUST contain the TLV specified in Section 3. This enables 129 a monotonically increasing sequence number to be carried in each 130 frame, and prevents man-in-the-middle from capturing and replaying 131 the same frame again. 133 3. NULL Auth TLV 135 This section describes a new Authentication TLV as: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | TLV Type | TLV Len | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Sequence Number | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Sender timestamp | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 NULL Auth TLV 149 where: 151 TLV Type: The TLV Type. This field MUST be set to . 153 TLV Length: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 155 Sequence Number: is a monotonically increasing number while the 156 session state is UP. Once the session goes down the Sequence number 157 SHOULD be set to 0. 159 Sender timestamp: is not used by authentication, and is documented to 160 be compatible with BFD Stability [I-D.ashesh-bfd-stability]. It 161 should be set to 0, and should be ignored by the receiver. 163 4. IANA Considerations 165 IANA is requested to assign a new Auth Type for the NULL Auth TLV. 167 Note to RFC Editor: this section may be removed on publication as an 168 RFC. 170 5. Security Considerations 172 The approach described in this document enhances the ability to 173 authentication a BFD session by taking away the onerous requirement 174 that every frame be authenticated. By authenticating frames that 175 affect the state of the session, the security of the BFD session is 176 maintained. As such this document does not change the security 177 considerations for BFD. 179 6. References 180 6.1. Normative References 182 [FIPS-180-2] 183 National Institute of Standards and Technology, FIPS PUB 184 180-2, "The Keyed-Hash Message Authentication Code 185 (HMAC)", August 2002. 187 [FIPS-198] 188 National Institute of Standards and Technology, FIPS PUB 189 198, "The Keyed-Hash Message Authentication Code (HMAC)", 190 March 2002. 192 [I-D.ashesh-bfd-stability] 193 Mishra, A., Jethanandani, M., Saxena, A., Networks, J., 194 Chen, M., and P. Fan, "BFD Stability", draft-ashesh-bfd- 195 stability-03 (work in progress), June 2015. 197 [I-D.ietf-bfd-generic-crypto-auth] 198 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 199 "BFD Generic Cryptographic Authentication", draft-ietf- 200 bfd-generic-crypto-auth-06 (work in progress), April 2014. 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, 204 DOI 10.17487/RFC2119, March 1997, 205 . 207 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 208 with Existing Cryptographic Protection Methods for Routing 209 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 210 . 212 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 213 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 214 RFC 6151, DOI 10.17487/RFC6151, March 2011, 215 . 217 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 218 Considerations for the SHA-0 and SHA-1 Message-Digest 219 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 220 . 222 6.2. Informative References 224 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 226 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 227 CryptoBytes", 1996. 229 [I-D.ietf-karp-design-guide] 230 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 231 Routing Protocols (KARP) Design Guidelines", draft-ietf- 232 karp-design-guide-10 (work in progress), December 2011. 234 [MD5-attack] 235 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 236 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 237 2004. 239 [NIST-HMAC-SHA] 240 National Institute of Standards and Technology, Available 241 online at http://csrc.nist.gov/groups/ST/hash/policy.html, 242 "NIST's Policy on Hash Functions", 2006. 244 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 245 DOI 10.17487/RFC1321, April 1992, 246 . 248 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 249 Hashing for Message Authentication", RFC 2104, 250 DOI 10.17487/RFC2104, February 1997, 251 . 253 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 254 "Randomness Requirements for Security", BCP 106, RFC 4086, 255 DOI 10.17487/RFC4086, June 2005, 256 . 258 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 259 Authentication", RFC 4822, DOI 10.17487/RFC4822, February 260 2007, . 262 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 263 and M. Fanto, "IS-IS Generic Cryptographic 264 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 265 2009, . 267 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 268 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 269 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 270 2009, . 272 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 273 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 274 . 276 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 277 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 278 DOI 10.17487/RFC6234, May 2011, 279 . 281 [SHA-1-attack1] 282 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 283 Full SHA-1", 2005. 285 [SHA-1-attack2] 286 Wang, X., Yao, A., and F. Yao, "New Collision Search for 287 SHA-1", 2005. 289 Authors' Addresses 291 Mahesh Jethanandani 292 Cisco Systems 293 170 W. Tasman Drive 294 San Jose, CA 95134 295 USA 297 Phone: +1 (408) 526-8763 298 Email: mjethanandani@gmail.com 300 Ashesh Mishra 301 Ciena Corporation 302 3939 North 1st Street 303 San Jose, CA 95134 304 USA 306 Phone: +1 (408) 904-2114 307 Email: mishra.ashesh@gmail.com 309 Ankur Saxena 310 Citrix 311 4988 Great America Pkwy 312 Santa Clara, CA 95054 313 USA 315 Email: ankurpsaxena@gmail.com 316 Manav Bhatia 317 Ionos Networks 318 Bangalore 319 India 321 Email: manav@ionosnetworks.com