idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-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 : ---------------------------------------------------------------------------- ** 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 (June 27, 2017) is 2488 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 221, but no explicit reference was found in the text == Unused Reference: 'FIPS-198' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-generic-crypto-auth' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-stability' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'RFC6039' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'NIST-HMAC-SHA' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC4822' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC5310' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 320, 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 (-13) exists of draft-ietf-bfd-secure-sequence-numbers-00 == Outdated reference: A later version (-12) exists of draft-ietf-bfd-stability-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 Summary: 4 errors (**), 0 flaws (~~), 19 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: December 29, 2017 O3b Networks 6 A. Saxena 7 Ciena Corporation 8 M. Bhatia 9 Ionos Networks 10 June 27, 2017 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-03 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 December 29, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 6.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 Read : On state change from to 122 Auth : Authenticate frame 123 NULL : No Authentication. Use NULL AUTH TLV. 124 n/a : Invalid state transition. 125 Select : Most frames NULL AUTH. Selective (periodic) 126 frames authenticated. 127 +--------+--------+--------+--------+--------+--------+ 128 | | DOWN | INIT | UP | POLL | DEMAND | 129 +--------+--------+--------+--------+--------+--------+ 130 | DOWN | NULL | Auth | Auth | Auth | Auth | 131 +--------+--------+--------+--------+--------+--------+ 132 | INIT | Auth | NULL | Auth | Auth | Auth | 133 +--------+--------+--------+--------+--------+--------+ 134 | UP | Auth | n/a | Select | Auth | Auth | 135 +--------+--------+--------+--------+--------+--------+ 136 | POLL | Auth | n/a | Auth | Auth | Auth | 137 +--------+--------+--------+--------+--------+--------+ 138 | DEMAND | Auth | Auth | Auth | Auth | Auth | 139 +--------+--------+--------+--------+--------+--------+ 141 Optimized Authentication Map 143 All frames already carry the sequence number. The NULL AUTH frames 144 MUST contain the TLV specified in Section 3. This enables a 145 monotonically increasing sequence number to be carried in each frame, 146 and prevents man-in-the-middle from capturing and replaying the same 147 frame again. Since all frames still carry a sequence number, the 148 logic for sequence number maintenance remains unchanged from 149 [RFC5880]. If at a later time, a different scheme is adopted for 150 changing sequence number, this method can use the updated scheme 151 without any impact. 153 Most frames transmitted on a BFD session are BFD CC UP frames. 154 Authenticating a small subset of these frames (one per configured 155 period) significantly reduces the computational demand for the system 156 while maintaining security of the session across the configured 157 authentication periods. The configuration of the periodic 158 authentication interval for BFD CC UP frames is an open issue. 160 3. NULL Auth TLV 162 This section describes a new Authentication TLV as: 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Auth Type | Auth Len | Auth Key ID | Reserved | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Sequence Number | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 NULL Auth TLV 174 where: 176 Auth Type: The Authentication Type, which in this case is 0 (NULL 177 Auth TL) 179 Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 181 Auth Key ID: The authentication key ID in use for this packet. Must 182 be set to zero. 184 Reserved: The authentication key ID in use for this packet. This 185 allows multiple keys to be active simultaneously. 187 Sequence Number: The sequence number for this packet. Implementation 188 may use sequence numbers as defined in [RFC5880], or secure sequence 189 numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers]. 191 The NULL Auth TLV must be used for all frames that are not 192 authenticated. This protects against replay-attacks by allowing the 193 session to maintain an incrementing sequence number for all frames 194 (authenticated and un-authenticated). 196 In the future, if a new scheme is adopted for changing the sequence 197 number, this method can adopt the new scheme without any impact. 199 4. IANA Considerations 201 This document requests an update to the registry titled "BFD 202 Authentication Types". IANA is requested to update the Value of 0 203 which is currently named as Reserved to NULL (see Section 3). 205 Note to RFC Editor: this section may be removed on publication as an 206 RFC. 208 5. Security Considerations 210 The approach described in this document enhances the ability to 211 authentication a BFD session by taking away the onerous requirement 212 that every frame be authenticated. By authenticating frames that 213 affect the state of the session, the security of the BFD session is 214 maintained. As such this document does not change the security 215 considerations for BFD. 217 6. References 219 6.1. Normative References 221 [FIPS-180-2] 222 National Institute of Standards and Technology, FIPS PUB 223 180-2, "The Keyed-Hash Message Authentication Code 224 (HMAC)", August 2002. 226 [FIPS-198] 227 National Institute of Standards and Technology, FIPS PUB 228 198, "The Keyed-Hash Message Authentication Code (HMAC)", 229 March 2002. 231 [I-D.ietf-bfd-generic-crypto-auth] 232 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 233 "BFD Generic Cryptographic Authentication", draft-ietf- 234 bfd-generic-crypto-auth-06 (work in progress), April 2014. 236 [I-D.ietf-bfd-secure-sequence-numbers] 237 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 238 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 239 secure-sequence-numbers-00 (work in progress), May 2017. 241 [I-D.ietf-bfd-stability] 242 Mishra, A., Jethanandani, M., Saxena, A., Networks, J., 243 Chen, M., and P. Fan, "BFD Stability", draft-ietf-bfd- 244 stability-00 (work in progress), May 2017. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 252 with Existing Cryptographic Protection Methods for Routing 253 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 254 . 256 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 257 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 258 RFC 6151, DOI 10.17487/RFC6151, March 2011, 259 . 261 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 262 Considerations for the SHA-0 and SHA-1 Message-Digest 263 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 264 . 266 6.2. Informative References 268 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 270 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 271 CryptoBytes", 1996. 273 [I-D.ietf-karp-design-guide] 274 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 275 Routing Protocols (KARP) Design Guidelines", draft-ietf- 276 karp-design-guide-10 (work in progress), December 2011. 278 [MD5-attack] 279 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 280 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 281 2004. 283 [NIST-HMAC-SHA] 284 National Institute of Standards and Technology, Available 285 online at http://csrc.nist.gov/groups/ST/hash/policy.html, 286 "NIST's Policy on Hash Functions", 2006. 288 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 289 DOI 10.17487/RFC1321, April 1992, 290 . 292 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 293 Hashing for Message Authentication", RFC 2104, 294 DOI 10.17487/RFC2104, February 1997, 295 . 297 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 298 "Randomness Requirements for Security", BCP 106, RFC 4086, 299 DOI 10.17487/RFC4086, June 2005, 300 . 302 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 303 Authentication", RFC 4822, DOI 10.17487/RFC4822, February 304 2007, . 306 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 307 and M. Fanto, "IS-IS Generic Cryptographic 308 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 309 2009, . 311 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 312 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 313 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 314 2009, . 316 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 317 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 318 . 320 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 321 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 322 DOI 10.17487/RFC6234, May 2011, 323 . 325 [SHA-1-attack1] 326 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 327 Full SHA-1", 2005. 329 [SHA-1-attack2] 330 Wang, X., Yao, A., and F. Yao, "New Collision Search for 331 SHA-1", 2005. 333 Authors' Addresses 335 Mahesh Jethanandani 336 Cisco Systems 337 170 W. Tasman Drive 338 San Jose, CA 95134 339 USA 341 Phone: +1 (408) 526-8763 342 Email: mjethanandani@gmail.com 344 Ashesh Mishra 345 O3b Networks 347 Email: mishra.ashesh@gmail.com 349 Ankur Saxena 350 Ciena Corporation 351 3939 N 1st Street 352 San Jose, CA 95134 353 USA 355 Email: ankurpsaxena@gmail.com 357 Manav Bhatia 358 Ionos Networks 359 Bangalore 360 India 362 Email: manavbhatia@gmail.com