idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-02.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 (January 5, 2017) is 2668 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.ashesh-bfd-stability' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-generic-crypto-auth' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC6039' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'NIST-HMAC-SHA' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC4822' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC5310' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 315, 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-04 ** 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 (~~), 18 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: July 9, 2017 A. Saxena 6 Ciena Corporation 7 M. Bhatia 8 Ionos Networks 9 January 5, 2017 11 Optimizing BFD Authentication 12 draft-ietf-bfd-optimizing-authentication-02 14 Abstract 16 This document describes an optimization to BFD Authentication as 17 described in Section 6.7 of BFD [RFC5880]. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 9, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 61 3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 6.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Authenticating every BFD [RFC5880] packet with a Simple Password, or 72 with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash 73 Algorithm (SHA-1) algorithms is computationally intensive process, 74 making it difficult if not impossible to authenticate every packet - 75 particularly at faster rates. Also, the recent escalating series of 76 attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise 77 concerns about their remaining useful lifetime as outlined in Updated 78 Security Considerations for the MD5 Message-Digest and the HMAC-MD5 79 Algorithm [RFC6151] and Security Considerations for the SHA-0 and 80 SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by stronger 81 algorithms, the computational overhead, will make the task of 82 authenticating every packet even more difficult to achieve. 84 This document proposes that only BFD frames that signal a state 85 change in BFD be authenticated. Rest of the frames can be 86 transmitted and received without authentication enabled. Most frames 87 that are transmitted and received have no state change associated 88 with them. Limiting authentication to frames that affect a BFD 89 session state allows more sessions to be supported for 90 authentication. Moreover, most BFD frames that signal a state change 91 are generally transmitted at a slower interval of 1s leaving enough 92 time to compute the hash. 94 Section 2 talks about the changes to authentication mode as described 95 in BFD [RFC5880]. 97 2. Authentication Mode 99 The cryptographic authentication mechanisms specified in BFD 100 [RFC5880] describes enabling and disabling of authentication as a one 101 time operation. As a security precaution, it mentions that 102 authentication state be allowed to change at most once. Once 103 enabled, every packet must have Authentication Bit set and the 104 associated Authentication TLV appended. In addition, it states that 105 an implementation SHOULD NOT allow the authentication state to be 106 changed based on the receipt of a BFD Control packet. 108 This document proposes that the authentication mode be modified to be 109 enabled on demand. Instead of authenticating every packet, BFD peers 110 decide which frames need to be authenticated, and authenticate only 111 those frames. For example, the two ends can decide that BFD frames 112 that indicate a state change should be authenticated and enable 113 authentication on those frames only. If the two ends have not 114 previously negotiated which frames they will transmit or receive with 115 authentication enabled, then the BFD session will fail to come up, 116 because at least one end will expect every frame to be authenticated. 117 The state changes for which authentication is being suggested 118 include: 120 Read : On state change from to 121 Auth : Authenticate frame 122 NULL : No Authentication. Use NULL AUTH TLV. 123 n/a : Invalid state transition. 124 Select : Most frames NULL AUTH. Selective (periodic) 125 frames authenticated. 126 +--------+--------+--------+--------+--------+--------+ 127 | | DOWN | INIT | UP | POLL | DEMAND | 128 +--------+--------+--------+--------+--------+--------+ 129 | DOWN | NULL | Auth | Auth | Auth | Auth | 130 +--------+--------+--------+--------+--------+--------+ 131 | INIT | Auth | NULL | Auth | Auth | Auth | 132 +--------+--------+--------+--------+--------+--------+ 133 | UP | Auth | n/a | Select | Auth | Auth | 134 +--------+--------+--------+--------+--------+--------+ 135 | POLL | Auth | n/a | Auth | Auth | Auth | 136 +--------+--------+--------+--------+--------+--------+ 137 | DEMAND | Auth | Auth | Auth | Auth | Auth | 138 +--------+--------+--------+--------+--------+--------+ 140 Optimized Authentication Map 142 All frames already carry the sequence number. The NULL AUTH frames 143 MUST contain the TLV specified in Section 3. This enables a 144 monotonically increasing sequence number to be carried in each frame, 145 and prevents man-in-the-middle from capturing and replaying the same 146 frame again. Since all frames still carry a sequence number, the 147 logic for sequence number maintenance remains unchanged from 148 [RFC5880]. If at a later time, a different scheme is adopted for 149 changing sequence number, this method can use the updated scheme 150 without any impact. 152 Most frames transmitted on a BFD session are BFD CC UP frames. 153 Authenticating a small subset of these frames (one per configured 154 period) significantly reduces the computational demand for the system 155 while maintaining security of the session across the configured 156 authentication periods. The configuration of the periodic 157 authentication interval for BFD CC UP frames is an open issue. 159 3. NULL Auth TLV 161 This section describes a new Authentication TLV as: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Auth Type | Auth Len | Auth Key ID | Reserved | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Sequence Number | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 NULL Auth TLV 173 where: 175 Auth Type: The Authentication Type, which in this case is 0 (NULL 176 Auth TL) 178 Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 180 Auth Key ID: The authentication key ID in use for this packet. Must 181 be set to zero. 183 Reserved: The authentication key ID in use for this packet. This 184 allows multiple keys to be active simultaneously. 186 Sequence Number: The sequence number for this packet. This value is 187 incremented for each successive packet transmitted for a session. 188 This provides protection against replay attacks. Must use the same 189 sequence number counter as the authenticated frames. 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.ashesh-bfd-stability] 232 Mishra, A., Jethanandani, M., Saxena, A., Networks, J., 233 Chen, M., and P. Fan, "BFD Stability", draft-ashesh-bfd- 234 stability-04 (work in progress), March 2016. 236 [I-D.ietf-bfd-generic-crypto-auth] 237 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 238 "BFD Generic Cryptographic Authentication", draft-ietf- 239 bfd-generic-crypto-auth-06 (work in progress), April 2014. 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, 243 DOI 10.17487/RFC2119, March 1997, 244 . 246 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 247 with Existing Cryptographic Protection Methods for Routing 248 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 249 . 251 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 252 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 253 RFC 6151, DOI 10.17487/RFC6151, March 2011, 254 . 256 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 257 Considerations for the SHA-0 and SHA-1 Message-Digest 258 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 259 . 261 6.2. Informative References 263 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 265 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 266 CryptoBytes", 1996. 268 [I-D.ietf-karp-design-guide] 269 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 270 Routing Protocols (KARP) Design Guidelines", draft-ietf- 271 karp-design-guide-10 (work in progress), December 2011. 273 [MD5-attack] 274 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 275 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 276 2004. 278 [NIST-HMAC-SHA] 279 National Institute of Standards and Technology, Available 280 online at http://csrc.nist.gov/groups/ST/hash/policy.html, 281 "NIST's Policy on Hash Functions", 2006. 283 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 284 DOI 10.17487/RFC1321, April 1992, 285 . 287 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 288 Hashing for Message Authentication", RFC 2104, 289 DOI 10.17487/RFC2104, February 1997, 290 . 292 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 293 "Randomness Requirements for Security", BCP 106, RFC 4086, 294 DOI 10.17487/RFC4086, June 2005, 295 . 297 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 298 Authentication", RFC 4822, DOI 10.17487/RFC4822, February 299 2007, . 301 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 302 and M. Fanto, "IS-IS Generic Cryptographic 303 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 304 2009, . 306 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 307 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 308 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 309 2009, . 311 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 312 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 313 . 315 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 316 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 317 DOI 10.17487/RFC6234, May 2011, 318 . 320 [SHA-1-attack1] 321 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 322 Full SHA-1", 2005. 324 [SHA-1-attack2] 325 Wang, X., Yao, A., and F. Yao, "New Collision Search for 326 SHA-1", 2005. 328 Authors' Addresses 329 Mahesh Jethanandani 330 Cisco Systems 331 170 W. Tasman Drive 332 San Jose, CA 95134 333 USA 335 Phone: +1 (408) 526-8763 336 Email: mjethanandani@gmail.com 338 Ashesh Mishra 339 Ciena Corporation 340 3939 North 1st Street 341 San Jose, CA 95134 342 USA 344 Email: mishra.ashesh@gmail.com 346 Ankur Saxena 347 Ciena Corporation 348 3939 N 1st Street 349 San Jose, CA 95134 350 USA 352 Email: ankurpsaxena@gmail.com 354 Manav Bhatia 355 Ionos Networks 356 Bangalore 357 India 359 Email: manavbhatia@gmail.com