idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-06.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). -- The document date (October 11, 2018) is 2017 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-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft VMware 4 Intended status: Standards Track A. Mishra 5 Expires: April 14, 2019 SES Networks 6 A. Saxena 7 Ciena Corporation 8 M. Bhatia 9 Nokia 10 October 11, 2018 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-06 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 BCP 14 [RFC2119] 25 [RFC8174] when, and only when, they appear in all capitals, as shown 26 here. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 14, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 64 3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 6.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Authenticating every BFD [RFC5880] packet with a Simple Password, or 75 with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash 76 Algorithm (SHA-1) algorithms is computationally intensive process, 77 making it difficult if not impossible to authenticate every packet - 78 particularly at faster rates. Also, the recent escalating series of 79 attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise 80 concerns about their remaining useful lifetime as outlined in Updated 81 Security Considerations for the MD5 Message-Digest and the HMAC-MD5 82 Algorithm [RFC6151] and Security Considerations for the SHA-0 and 83 SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by stronger 84 algorithms, the computational overhead, will make the task of 85 authenticating every packet even more difficult to achieve. 87 This document proposes that only BFD frames that signal a state 88 change in BFD be authenticated. Rest of the frames can be 89 transmitted and received without authentication enabled. Most frames 90 that are transmitted and received have no state change associated 91 with them. Limiting authentication to frames that affect a BFD 92 session state allows more sessions to be supported for 93 authentication. Moreover, most BFD frames that signal a state change 94 are generally transmitted at a slower interval of 1s leaving enough 95 time to compute the hash. To detect a Man In the Middle (MITM) 96 attack, it is also proposed that a non-state change frame be 97 authenticated occasionally. The interval of this non-state change 98 frame can be configured depending on the detect multiplier and the 99 capability of the system. As an example, this could be equal to the 100 detect multiplier number of packets. 102 The rest of the document is structured as follows. Section 2 talks 103 about the changes to authentication mode as described in BFD 104 [RFC5880]. Section 3 goes into the details of the new Authentication 105 TLV. 107 2. Authentication Mode 109 The cryptographic authentication mechanisms specified in BFD 110 [RFC5880] describes enabling and disabling of authentication as a one 111 time operation. As a security precaution, it mentions that 112 authentication state be allowed to change at most once. Once 113 enabled, every packet must have Authentication Bit set and the 114 associated Authentication TLV appended. In addition, it states that 115 an implementation SHOULD NOT allow the authentication state to be 116 changed based on the receipt of a BFD Control packet. 118 This document proposes that the authentication mode be modified to be 119 enabled on demand. Instead of authenticating every packet, BFD peers 120 are configured for which frames need to be authenticated, and 121 authenticate only those frames. Rest of the frames can be 122 transmitted and received without authentication. For example, the 123 two ends can be configured such that BFD frames that indicate a state 124 change should be authenticated and enable authentication on those 125 frames only. If the two ends have previously been configured as 126 such, but at least one side decides not to authenticate a state 127 change frame, then the BFD session will fail to come up. 129 This proposal outlines which frames need to be authenticated (carry 130 the A-bit), and which frames can be transmitted or received without 131 authentication enabled. A frame that fails authentication is 132 discarded, or a frame that was supposed to be authenticated, but was 133 not, e.g. a state-change frame, is discarded. However, there is no 134 change to the state machine for BFD, as the decision of a state 135 change is still decided by how many valid consecutive frames were 136 received, authenticated or otherwise. 138 The state changes for which authentication is being suggested 139 include: 141 Read : On state change from to 142 Auth : Authenticate frame 143 NULL : No Authentication. Use NULL AUTH TLV. 144 n/a : Invalid state transition. 145 Select : Most frames NULL AUTH. Selective (periodic) 146 frames authenticated. 147 +--------+--------+--------+--------+--------+--------+ 148 | | DOWN | INIT | UP | POLL | DEMAND | 149 +--------+--------+--------+--------+--------+--------+ 150 | DOWN | NULL | Auth | Auth | Auth | Auth | 151 +--------+--------+--------+--------+--------+--------+ 152 | INIT | Auth | NULL | Auth | Auth | Auth | 153 +--------+--------+--------+--------+--------+--------+ 154 | UP | Auth | n/a | Select | Auth | Auth | 155 +--------+--------+--------+--------+--------+--------+ 156 | POLL | Auth | n/a | Auth | Auth | Auth | 157 +--------+--------+--------+--------+--------+--------+ 158 | DEMAND | Auth | Auth | Auth | Auth | Auth | 159 +--------+--------+--------+--------+--------+--------+ 161 Optimized Authentication Map 163 All frames already carry the sequence number. The NULL AUTH frames 164 MUST contain the TLV specified in Section 3. This enables a 165 monotonically increasing sequence number to be carried in each frame, 166 and prevents man-in-the-middle from capturing and replaying the same 167 frame again. Since all frames still carry a sequence number, the 168 logic for sequence number maintenance remains unchanged from 169 [RFC5880]. If at a later time, a different scheme is adopted for 170 changing sequence number, this method can use the updated scheme 171 without any impact. 173 Most frames transmitted on a BFD session are BFD CC UP frames. 174 Authenticating a small subset of these frames, for example, a detect 175 multiplier number of packets per configured period, significantly 176 reduces the computational demand for the system while maintaining 177 security of the session across the configured authentication periods. 178 The configuration of the periodic authentication interval for BFD CC 179 UP frames is an open issue, left for implementations to decide. 181 3. NULL Auth TLV 183 This section describes a new Authentication TLV as: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Auth Type | Auth Len | Auth Key ID | Reserved | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Sequence Number | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 NULL Auth TLV 195 where: 197 Auth Type: The Authentication Type, which in this case is TBD (NULL 198 Auth TLV, to be assigned by IANA) 200 Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 202 Auth Key ID: The authentication key ID in use for this packet. Must 203 be set to zero. 205 Reserved: This byte MUST be set to zero on transmit and ignored on 206 receive. 208 Sequence Number: The sequence number for this packet. Implementation 209 may use sequence numbers as defined in [RFC5880], or secure sequence 210 numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers]. 212 The NULL Auth TLV must be used for all frames that are not 213 authenticated. This protects against replay-attacks by allowing the 214 session to maintain an incrementing sequence number for all frames 215 (authenticated and un-authenticated). 217 In the future, if a new scheme is adopted for changing the sequence 218 number, this method can adopt the new scheme without any impact. 220 4. IANA Considerations 222 This document requests an update to the registry titled "BFD 223 Authentication Types". IANA is requested to to assign a new BFD Auth 224 Type for "NULL Auth TLV" (see Section 3). 226 Note to RFC Editor: this section may be removed on publication as an 227 RFC. 229 5. Security Considerations 231 The approach described in this document enhances the ability to 232 authentication a BFD session by taking away the onerous requirement 233 that every frame be authenticated. By authenticating frames that 234 affect the state of the session, the security of the BFD session is 235 maintained. As such this document does not change the security 236 considerations for BFD. 238 6. References 240 6.1. Normative References 242 [I-D.ietf-bfd-secure-sequence-numbers] 243 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 244 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 245 secure-sequence-numbers-02 (work in progress), May 2018. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, 249 DOI 10.17487/RFC2119, March 1997, 250 . 252 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 253 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 254 May 2017, . 256 6.2. Informative References 258 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 259 DOI 10.17487/RFC1321, April 1992, 260 . 262 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 263 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 264 . 266 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 267 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 268 RFC 6151, DOI 10.17487/RFC6151, March 2011, 269 . 271 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 272 Considerations for the SHA-0 and SHA-1 Message-Digest 273 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 274 . 276 [SHA-1-attack1] 277 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 278 Full SHA-1", 2005. 280 [SHA-1-attack2] 281 Wang, X., Yao, A., and F. Yao, "New Collision Search for 282 SHA-1", 2005. 284 Authors' Addresses 286 Mahesh Jethanandani 287 VMware 288 USA 290 Email: mjethanandani@gmail.com 292 Ashesh Mishra 293 SES Networks 295 Email: mishra.ashesh@gmail.com 297 Ankur Saxena 298 Ciena Corporation 299 3939 N 1st Street 300 San Jose, CA 95134 301 USA 303 Email: ankurpsaxena@gmail.com 305 Manav Bhatia 306 Nokia 307 Bangalore 308 India 310 Email: manav.bhatia@nokia.com