idnits 2.17.1 draft-ietf-bfd-optimizing-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 (February 15, 2016) is 2986 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 214, but no explicit reference was found in the text == Unused Reference: 'FIPS-198' is defined on line 219, but no explicit reference was found in the text == Unused Reference: 'I-D.ashesh-bfd-stability' is defined on line 224, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-generic-crypto-auth' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'RFC6039' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'NIST-HMAC-SHA' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC4822' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RFC5310' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 308, 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 (~~), 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: August 18, 2016 A. Saxena 6 Ciena Corporation 7 M. Bhatia 8 Ionos Networks 9 February 15, 2016 11 Optimizing BFD Authentication 12 draft-ietf-bfd-optimizing-authentication-01 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 August 18, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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]. 150 Most frames transmitted on a BFD session are BFD CC UP frames. 151 Authenticating a small subset of these frames (one per configured 152 period) significantly reduces the computational demand for the system 153 while maintaining security of the session across the configured 154 authentication periods. The configuration of the periodic 155 authentication interval for BFD CC UP frames is an open issue. 157 3. NULL Auth TLV 159 This section describes a new Authentication TLV as: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Auth Type | Auth Len | Auth Key ID | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Sequence Number | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 NULL Auth TLV 171 where: 173 Auth Type: The Authentication Type, which in this case is 0 (NULL 174 Auth TL) 176 Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 178 Auth Key ID: The authentication key ID in use for this packet. Must 179 be set to zero. 181 Reserved: The authentication key ID in use for this packet. This 182 allows multiple keys to be active simultaneously. 184 Sequence Number: The sequence number for this packet. This value is 185 incremented for each successive packet transmitted for a session. 186 This provides protection against replay attacks. Must use the same 187 sequence number counter as the authenticated frames. 189 The NULL Auth TLV must be used for all frames that are not 190 authenticated. This protects against replay-attacks by allowing the 191 session to maintain an incrementing sequence number for all frames 192 (authenticated and un-authenticated). 194 4. IANA Considerations 196 IANA is requested to assign a new Auth Type for the NULL Auth TLV. 198 Note to RFC Editor: this section may be removed on publication as an 199 RFC. 201 5. Security Considerations 203 The approach described in this document enhances the ability to 204 authentication a BFD session by taking away the onerous requirement 205 that every frame be authenticated. By authenticating frames that 206 affect the state of the session, the security of the BFD session is 207 maintained. As such this document does not change the security 208 considerations for BFD. 210 6. References 212 6.1. Normative References 214 [FIPS-180-2] 215 National Institute of Standards and Technology, FIPS PUB 216 180-2, "The Keyed-Hash Message Authentication Code 217 (HMAC)", August 2002. 219 [FIPS-198] 220 National Institute of Standards and Technology, FIPS PUB 221 198, "The Keyed-Hash Message Authentication Code (HMAC)", 222 March 2002. 224 [I-D.ashesh-bfd-stability] 225 Mishra, A., Jethanandani, M., Saxena, A., Networks, J., 226 Chen, M., and P. Fan, "BFD Stability", draft-ashesh-bfd- 227 stability-03 (work in progress), June 2015. 229 [I-D.ietf-bfd-generic-crypto-auth] 230 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 231 "BFD Generic Cryptographic Authentication", draft-ietf- 232 bfd-generic-crypto-auth-06 (work in progress), April 2014. 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 240 with Existing Cryptographic Protection Methods for Routing 241 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 242 . 244 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 245 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 246 RFC 6151, DOI 10.17487/RFC6151, March 2011, 247 . 249 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 250 Considerations for the SHA-0 and SHA-1 Message-Digest 251 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 252 . 254 6.2. Informative References 256 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 258 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 259 CryptoBytes", 1996. 261 [I-D.ietf-karp-design-guide] 262 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 263 Routing Protocols (KARP) Design Guidelines", draft-ietf- 264 karp-design-guide-10 (work in progress), December 2011. 266 [MD5-attack] 267 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 268 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 269 2004. 271 [NIST-HMAC-SHA] 272 National Institute of Standards and Technology, Available 273 online at http://csrc.nist.gov/groups/ST/hash/policy.html, 274 "NIST's Policy on Hash Functions", 2006. 276 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 277 DOI 10.17487/RFC1321, April 1992, 278 . 280 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 281 Hashing for Message Authentication", RFC 2104, 282 DOI 10.17487/RFC2104, February 1997, 283 . 285 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 286 "Randomness Requirements for Security", BCP 106, RFC 4086, 287 DOI 10.17487/RFC4086, June 2005, 288 . 290 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 291 Authentication", RFC 4822, DOI 10.17487/RFC4822, February 292 2007, . 294 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 295 and M. Fanto, "IS-IS Generic Cryptographic 296 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 297 2009, . 299 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 300 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 301 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 302 2009, . 304 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 305 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 306 . 308 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 309 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 310 DOI 10.17487/RFC6234, May 2011, 311 . 313 [SHA-1-attack1] 314 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 315 Full SHA-1", 2005. 317 [SHA-1-attack2] 318 Wang, X., Yao, A., and F. Yao, "New Collision Search for 319 SHA-1", 2005. 321 Authors' Addresses 323 Mahesh Jethanandani 324 Cisco Systems 325 170 W. Tasman Drive 326 San Jose, CA 95134 327 USA 329 Phone: +1 (408) 526-8763 330 Email: mjethanandani@gmail.com 331 Ashesh Mishra 332 Ciena Corporation 333 3939 North 1st Street 334 San Jose, CA 95134 335 USA 337 Email: mishra.ashesh@gmail.com 339 Ankur Saxena 340 Ciena Corporation 341 3939 N 1st Street 342 San Jose, CA 95134 343 USA 345 Email: ankurpsaxena@gmail.com 347 Manav Bhatia 348 Ionos Networks 349 Bangalore 350 India 352 Email: manav@ionosnetworks.com