idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2020) is 1380 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) == Outdated reference: A later version (-13) exists of draft-ietf-bfd-secure-sequence-numbers-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft Kloud Services 4 Updates: 5880 (if approved) A. Mishra 5 Intended status: Standards Track SES Networks 6 Expires: January 14, 2021 A. Saxena 7 Ciena Corporation 8 M. Bhatia 9 Nokia 10 July 13, 2020 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-10 15 Abstract 17 This document describes an optimization to BFD Authentication as 18 described in Section 6.7 of BFD RFC 5880. This document updates RFC 19 5880. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 14, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 59 3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Authenticating every BFD [RFC5880] packet with a Simple Password, or 70 with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash 71 Algorithm (SHA-1) algorithms is a computationally intensive process. 72 This makes it difficult, if not impossible to authenticate every 73 packet - particularly at faster rates. Also, the recent escalating 74 series of attacks on MD5 and SHA-1 described in Finding Collisions in 75 the Full SHA-1 [SHA-1-attack1] and New Collision Search for SHA-1 76 [SHA-1-attack2] raise concerns about their remaining useful lifetime 77 as outlined in Updated Security Considerations for the MD5 Message- 78 Digest and the HMAC-MD5 Algorithm [RFC6151] and Security 79 Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm 80 [RFC6194]. If replaced by stronger algorithms, the computational 81 overhead, will make the task of authenticating every packet even more 82 difficult to achieve. 84 This document proposes that only BFD packets that signal a state 85 change, a demand mode change (to D bit) or a poll sequence change (P 86 or F bit change) in a BFD packet be categorized as a significant 87 change. This document also proposes that all BFD control packets 88 which signal a significant change MUST be authenticated if the 89 session's bfd.AuthType is non-zero. Other BFD Control packets MAY be 90 transmitted and received without the A bit set. 92 Most packets that are transmitted and received have no state change 93 associated with them. Limiting authentication to packets that affect 94 a BFD session state allows more sessions to be supported with this 95 optimized method of authentication. Moreover, most BFD packets that 96 signal a significant change are generally transmitted at a slower 97 interval of 1s, leaving enough time to compute the hash. 99 To detect a Man In the Middle (MITM) attack, it is also proposed that 100 a BFD control packet without a significant change be authenticated 101 occasionally. The interval of this non-state change frame can be 102 configured depending on the detect multiplier and the capability of 103 the system. As an example, this could be equal to the detect 104 multiplier number of packets. 106 The rest of the document is structured as follows. Section 2 talks 107 about the changes to authentication mode as described in BFD 108 [RFC5880]. Section 3 goes into the details of the new Authentication 109 Type. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in BCP 14 [RFC2119] 116 [RFC8174] when, and only when, they appear in all capitals, as shown 117 here. 119 1.2. Terminology 121 The following terms used in this document have been defined in BFD 122 [RFC5880]. 124 o Detect Multiplier 126 o Detection Time 128 +--------------+----------------------------------------------------+ 129 | Term | Meaning | 130 +--------------+----------------------------------------------------+ 131 | significant | State change, a demand model change (to D bit) or | 132 | change | a poll sequence change (P or F bit). | 133 | configured | configured authentication periodic interval | 134 | interval | | 135 +--------------+----------------------------------------------------+ 137 2. Authentication Mode 139 The cryptographic authentication mechanisms specified in BFD 140 [RFC5880] describes enabling and disabling of authentication as a one 141 time operation. As a security precaution, it mentions that 142 authentication state be allowed to change at most once. Once 143 enabled, every packet must have Authentication Bit set and the 144 associated Authentication Type appended. In addition, it states that 145 an implementation SHOULD NOT allow the authentication state to be 146 changed based on the receipt of a BFD Control packet. 148 This document proposes that the authentication mode be modified to be 149 enabled on demand. Instead of authenticating every packet, BFD peers 150 are configured for which packets need to be authenticated, and 151 authenticate only those packets. Rest of the packets can be 152 transmitted and received without authentication. For example, the 153 two ends can be configured such that BFD packets that indicate a 154 significant change should be authenticated and enable authentication 155 on those packets only. If the two ends have previously been 156 configured as such, but at least one side decides not to authenticate 157 a significant change frame, then the BFD session will fail to come 158 up. 160 This proposal outlines which packets need to be authenticated (carry 161 the A-bit), and which packets can be transmitted or received without 162 authentication enabled. A frame that fails authentication is 163 discarded, or a frame that was supposed to be authenticated, but was 164 not, e.g. a significant change frame, is discarded. However, there 165 is no change to the state machine for BFD, as the decision of a 166 significant change is still decided by how many valid consecutive 167 packets were received, authenticated or otherwise. 169 The following table summarizes when the A bit should be set. The 170 table should be read with the column indicating the BFD state the 171 receiver is currently in, and the row indicating the BFD state the 172 receiver might transition to based on the packet received. The 173 interesection of the two indicates whether the received packet should 174 have the A bit set (Auth), no authentication is needed (NULL), most 175 packets are NULL AUTH (Select) or the state transition is not 176 applicable. 178 Read : On state change from to 179 Auth : Authenticate frame 180 NULL : No Authentication. Use NULL AUTH Type. 181 n/a : Invalid state transition. 182 Select : Most packets NULL AUTH. Selective (periodic) 183 packets authenticated. 184 +--------+--------+--------+--------+------------+ 185 | | DOWN | INIT | UP | ADMIN DOWN | 186 +--------+--------+--------+--------+------------+ 187 | DOWN | NULL | Auth | Auth | NULL | 188 +--------+--------+--------+--------+------------+ 189 | INIT | Auth | NULL | n/a | n/a | 190 +--------+--------+--------+--------+------------+ 191 | UP | Auth | Auth | Select | n/a | 192 +--------+--------+--------+--------+------------+ 193 | ADMIN | NULL | Auth | Auth | NULL | 194 +--------+--------+--------+--------+------------+ 196 Optimized Authentication Map 198 If P or F bit changes value, the packet MUST be authenticated. If 199 the D bit changes value, the packet MUST be authenticated. 201 All packets already carry the sequence number. The NULL AUTH packets 202 MUST contain the Type specified in Section 3. This enables a 203 monotonically increasing sequence number to be carried in each frame, 204 and prevents man-in-the-middle from capturing and replaying the same 205 frame again. Since all packets still carry a sequence number, the 206 logic for sequence number maintenance remains unchanged from BFD 207 [RFC5880]. If at a later time, a different scheme is adopted for 208 changing sequence number, e.g. Secure BFD Sequence Numbers 209 [I-D.ietf-bfd-secure-sequence-numbers], this method can use the 210 updated scheme without any impact. 212 Most packets transmitted on a BFD session are BFD UP packets. 213 Authenticating a small subset of these packets, for example, a detect 214 multiplier number of packets per configured period, significantly 215 reduces the computational demand for the system while maintaining 216 security of the session across the configured authentication periods. 217 A minimum of Detect Multiplier packets MUST be transmitted per 218 configured periodic authentication interval. This ensures that the 219 BFD session should see at least one authenticated packet during that 220 interval. 222 3. NULL Auth Type 224 This section describes a new Authentication Type as: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Auth Type | Auth Len | Auth Key ID | Reserved | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Sequence Number | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 NULL Auth Type 236 where: 238 Auth Type: The Authentication Type, which in this case is TBD (NULL, 239 to be assigned by IANA) 241 Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes 243 Auth Key ID: The authentication key ID in use for this packet. Must 244 be set to zero. 246 Reserved: This byte MUST be set to zero on transmit and ignored on 247 receive. 249 Sequence Number: The sequence number for this packet. Implementation 250 may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD 251 [RFC5880], or secure sequence numbers as defined in Secure BFD 252 Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 254 The NULL Auth Type must be used for all packets that are not 255 authenticated. This protects against replay-attacks by allowing the 256 session to maintain an incrementing sequence number for all packets 257 (authenticated and un-authenticated). 259 In the future, if a new scheme is adopted for changing the sequence 260 number, this method can adopt the new scheme without any impact. 262 4. IANA Considerations 264 This document requests an update to the registry titled "BFD 265 Authentication Types". IANA is requested to to assign a new BFD Auth 266 Type for "NULL" (see Section 3). 268 Note to RFC Editor: this section may be removed on publication as an 269 RFC. 271 5. Security Considerations 273 The approach described in this document enhances the ability to 274 authenticate a BFD session by taking away the onerous requirement 275 that every BFD control packet be authenticated. By authenticating 276 packets that affect the state of the session, the security of the BFD 277 session is maintained. In this mode, packets that are a significant 278 change but are not authenticated, are dropped by the system. 279 Therefore, a malicious user that tries to inject a non-authenticated 280 packet, e.g. with a Down state to take a session down will fail. 281 That combined with the proposal of using sequence number defined in 282 Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers] 283 further enhances the security of BFD sessions. 285 6. References 287 6.1. Normative References 289 [I-D.ietf-bfd-secure-sequence-numbers] 290 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 291 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 292 secure-sequence-numbers-05 (work in progress), February 293 2020. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 301 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 302 . 304 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 305 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 306 May 2017, . 308 6.2. Informative References 310 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 311 DOI 10.17487/RFC1321, April 1992, 312 . 314 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 315 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 316 RFC 6151, DOI 10.17487/RFC6151, March 2011, 317 . 319 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 320 Considerations for the SHA-0 and SHA-1 Message-Digest 321 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 322 . 324 [SHA-1-attack1] 325 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 326 Full SHA-1", 2005. 328 [SHA-1-attack2] 329 Wang, X., Yao, A., and F. Yao, "New Collision Search for 330 SHA-1", 2005. 332 Authors' Addresses 334 Mahesh Jethanandani 335 Kloud Services 336 USA 338 Email: mjethanandani@gmail.com 340 Ashesh Mishra 341 SES Networks 343 Email: mishra.ashesh@gmail.com 345 Ankur Saxena 346 Ciena Corporation 347 3939 N 1st Street 348 San Jose, CA 95134 349 USA 351 Email: ankurpsaxena@gmail.com 353 Manav Bhatia 354 Nokia 355 Bangalore 356 India 358 Email: manav.bhatia@nokia.com