idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-05.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 (May 25, 2018) is 2162 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-01 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 4 Intended status: Standards Track A. Mishra 5 Expires: November 26, 2018 SES Networks 6 A. Saxena 7 Ciena Corporation 8 M. Bhatia 9 Nokia 10 May 25, 2018 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-05 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 November 26, 2018. 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. 97 Section 2 talks about the changes to authentication mode as described 98 in BFD [RFC5880]. 100 2. Authentication Mode 102 The cryptographic authentication mechanisms specified in BFD 103 [RFC5880] describes enabling and disabling of authentication as a one 104 time operation. As a security precaution, it mentions that 105 authentication state be allowed to change at most once. Once 106 enabled, every packet must have Authentication Bit set and the 107 associated Authentication TLV appended. In addition, it states that 108 an implementation SHOULD NOT allow the authentication state to be 109 changed based on the receipt of a BFD Control packet. 111 This document proposes that the authentication mode be modified to be 112 enabled on demand. Instead of authenticating every packet, BFD peers 113 decide which frames need to be authenticated, and authenticate only 114 those frames. For example, the two ends can decide that BFD frames 115 that indicate a state change should be authenticated and enable 116 authentication on those frames only. If the two ends have not 117 previously negotiated which frames they will transmit or receive with 118 authentication enabled, then the BFD session will fail to come up, 119 because at least one end will expect every frame to be authenticated. 120 The state changes for which authentication is being suggested 121 include: 123 Read : On state change from to 124 Auth : Authenticate frame 125 NULL : No Authentication. Use NULL AUTH TLV. 126 n/a : Invalid state transition. 127 Select : Most frames NULL AUTH. Selective (periodic) 128 frames authenticated. 129 +--------+--------+--------+--------+--------+--------+ 130 | | DOWN | INIT | UP | POLL | DEMAND | 131 +--------+--------+--------+--------+--------+--------+ 132 | DOWN | NULL | Auth | Auth | Auth | Auth | 133 +--------+--------+--------+--------+--------+--------+ 134 | INIT | Auth | NULL | Auth | Auth | Auth | 135 +--------+--------+--------+--------+--------+--------+ 136 | UP | Auth | n/a | Select | Auth | Auth | 137 +--------+--------+--------+--------+--------+--------+ 138 | POLL | Auth | n/a | Auth | Auth | Auth | 139 +--------+--------+--------+--------+--------+--------+ 140 | DEMAND | Auth | Auth | Auth | Auth | Auth | 141 +--------+--------+--------+--------+--------+--------+ 143 Optimized Authentication Map 145 All frames already carry the sequence number. The NULL AUTH frames 146 MUST contain the TLV specified in Section 3. This enables a 147 monotonically increasing sequence number to be carried in each frame, 148 and prevents man-in-the-middle from capturing and replaying the same 149 frame again. Since all frames still carry a sequence number, the 150 logic for sequence number maintenance remains unchanged from 151 [RFC5880]. If at a later time, a different scheme is adopted for 152 changing sequence number, this method can use the updated scheme 153 without any impact. 155 Most frames transmitted on a BFD session are BFD CC UP frames. 156 Authenticating a small subset of these frames (one per configured 157 period) significantly reduces the computational demand for the system 158 while maintaining security of the session across the configured 159 authentication periods. The configuration of the periodic 160 authentication interval for BFD CC UP frames is an open issue. 162 3. NULL Auth TLV 164 This section describes a new Authentication TLV as: 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Auth Type | Auth Len | Auth Key ID | Reserved | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Sequence Number | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 NULL Auth TLV 176 where: 178 Auth Type: The Authentication Type, which in this case is 0 (NULL 179 Auth TL) 181 Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 183 Auth Key ID: The authentication key ID in use for this packet. Must 184 be set to zero. 186 Reserved: The authentication key ID in use for this packet. This 187 allows multiple keys to be active simultaneously. 189 Sequence Number: The sequence number for this packet. Implementation 190 may use sequence numbers as defined in [RFC5880], or secure sequence 191 numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers]. 193 The NULL Auth TLV must be used for all frames that are not 194 authenticated. This protects against replay-attacks by allowing the 195 session to maintain an incrementing sequence number for all frames 196 (authenticated and un-authenticated). 198 In the future, if a new scheme is adopted for changing the sequence 199 number, this method can adopt the new scheme without any impact. 201 4. IANA Considerations 203 This document requests an update to the registry titled "BFD 204 Authentication Types". IANA is requested to update the Value of 0 205 which is currently named as Reserved to NULL (see Section 3). 207 Note to RFC Editor: this section may be removed on publication as an 208 RFC. 210 5. Security Considerations 212 The approach described in this document enhances the ability to 213 authentication a BFD session by taking away the onerous requirement 214 that every frame be authenticated. By authenticating frames that 215 affect the state of the session, the security of the BFD session is 216 maintained. As such this document does not change the security 217 considerations for BFD. 219 6. References 221 6.1. Normative References 223 [I-D.ietf-bfd-secure-sequence-numbers] 224 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 225 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 226 secure-sequence-numbers-01 (work in progress), November 227 2017. 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, 231 DOI 10.17487/RFC2119, March 1997, 232 . 234 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 235 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 236 May 2017, . 238 6.2. Informative References 240 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 241 DOI 10.17487/RFC1321, April 1992, 242 . 244 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 245 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 246 . 248 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 249 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 250 RFC 6151, DOI 10.17487/RFC6151, March 2011, 251 . 253 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 254 Considerations for the SHA-0 and SHA-1 Message-Digest 255 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 256 . 258 [SHA-1-attack1] 259 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 260 Full SHA-1", 2005. 262 [SHA-1-attack2] 263 Wang, X., Yao, A., and F. Yao, "New Collision Search for 264 SHA-1", 2005. 266 Authors' Addresses 268 Mahesh Jethanandani 269 USA 271 Email: mjethanandani@gmail.com 273 Ashesh Mishra 274 SES Networks 276 Email: mishra.ashesh@gmail.com 278 Ankur Saxena 279 Ciena Corporation 280 3939 N 1st Street 281 San Jose, CA 95134 282 USA 284 Email: ankurpsaxena@gmail.com 286 Manav Bhatia 287 Nokia 288 Bangalore 289 India 291 Email: manav.bhatia@nokia.com