idnits 2.17.1 draft-nslag-mpls-deprecate-md5-03.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 ([RFC3036], [RFC5036]), 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 (September 3, 2018) is 2060 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Intended status: Informational S. Bryant 5 Expires: March 7, 2019 A. Malis 6 Huawei Technologies 7 N. Leymann 8 Deutsche Telekom 9 G. Swallow 10 Independent 11 September 3, 2018 13 Deprecating MD5 for LDP 14 draft-nslag-mpls-deprecate-md5-03 16 Abstract 18 When the MPLS Label Distribution Protocol (LDP) was specified circa 19 1999, there were very strong requirements that LDP should use a 20 cryptographic hash function to sign LDP protocol messages. MD5 was 21 widely used at that time, and was the obvious choices. 23 However, even when this decision was being taken there were concerns 24 as to whether MD5 was a strong enough signing option. This 25 discussion was briefly reflected in section 5.1 of RFC 5036 [RFC5036] 26 (and also in RFC 3036 [RFC3036]). 28 Over time it has been shown that MD5 can be compromised. Thus, there 29 is a concern shared in the security community and the working groups 30 responsible for the development of the LDP protocol that LDP is no 31 longer adequately secured. 33 This document deprecates MD5 as the signing method for LDP messages. 34 The document also selects a future method to secure LDP messages - 35 the choice is TCP-AO. In addition, we specify that the TBD 36 cryptographic mechanism is to be the default TCP-AO security method. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on March 7, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 74 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2.1. LDP in RFC 5036 . . . . . . . . . . . . . . . . . . . . . 3 76 2.2. MD5 in BGP . . . . . . . . . . . . . . . . . . . . . . . 3 77 2.3. Prior Art . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Securing LDP . . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 84 7.2. Informative References . . . . . . . . . . . . . . . . . 6 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 87 1. Introduction 89 RFC 3036 was published in January 2001 as a Proposed Standard, and it 90 was replaced by RFC 5035, which is a Draft Standard, in October 2007. 91 Two decades after LDP was originally specified there is a concern 92 shared by the security community and the IETF working groups that 93 develop the LDP protocol that LDP is no longer adequately secured. 95 LDP currently uses MD5 to cryptographically sign its messages for 96 security security purposes. However, MD5 is a hash function that is 97 no longer considered adequate to meet current security requirements. 99 1.1. Requirement Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Background 109 2.1. LDP in RFC 5036 111 In Section 5.1 "Spoofing" of RFC 5036 [RFC5036], in list item 2 112 "Session communication carried by TCP" the following statements are 113 made: 115 LDP specifies use of the TCP MD5 Signature Option to provide for 116 the authenticity and integrity of session messages. 118 RFC 2385 [RFC2385] asserts that MD5 authentication is now 119 considered by some to be too weak for this application. It also 120 points out that a similar TCP option with a stronger hashing 121 algorithm (it cites SHA-1 as an example) could be deployed. To 122 our knowledge, no such TCP option has been defined and deployed. 123 However, we note that LDP can use whatever TCP message digest 124 techniques are available, and when one stronger than MD5 is 125 specified and implemented, upgrading LDP to use it would be 126 relatively straightforward. 128 2.2. MD5 in BGP 130 There has been a similar discussion among working groups developing 131 the BGP protocol. BGP has already replaced MD5 with TCP-AO. This 132 was specified in RFC 7454 [RFC7454]. 134 To secure LDP the same approach will be followed, TCP-AO will be used 135 for LDP also. 137 As far as we are able to ascertain, there is currently no 138 recommended, mandatory to implement, cryptographic function 139 specified. We are concerned that without such a mandatory function, 140 implementations will simply fall back to MD5 and nothing will really 141 be changed. The MPLS working group will need the expertise of the 142 security community to specify a viable security function that is 143 suitable for wide scale deployment on existing network platforms. 145 2.3. Prior Art 147 RFC 6952 [RFC6952] dicusses a set of routing protocols that all are 148 using TCP for transport of protocol messages, according to guidelines 149 set forth in Section 4.2 of "Keying and Authentication for Routing 150 Protocols Design Guidelines", RFC 6518 [RFC6518]. 152 RFC 6952 takes a much broader approach than this document, it 153 discusses several protcols and also securing the LDP session 154 initialization. This document has a narrower scope, securing LDP 155 session messages only. LDP in initialization mode is addressed in 156 RFC 7349 [RFC7349]. 158 RFC 6952 and this document, basically suggest the same thing, move to 159 TCP-AO and deploy a strong cryotoigraphic algorithm. 161 All the protcols discuseed in RFC 6952 should adopt the approach to 162 securing protocol messages over TCP. 164 3. Securing LDP 166 Implementations conforming to this RFC MUST implement TCP-AO to 167 secure the TCP sessions carrying LDP in addition to the currently 168 required TCP MD5 Signature Option. 170 A TBD cryptographic mechanism must be implemented and provided to 171 TCP-AO to secure LDP messages. 173 The TBD mechanism is the preferred option, and MD5 SHOULD only to be 174 used when TBD is unavailable. 176 Note: The authors are not experts on this part of the stack, but it 177 seems that TCP security negotiation is still work in progress. If we 178 are wrong, then we need to include a requirement that such 179 negotiation is also required. In the absence of a negotiation 180 protocol, however, we need to leave this as a configuration process 181 until such time as the negotiation protocol work is complete. On 182 completion of a suitable negotiation protocol we need to issue a 183 further update requiring its use. 185 Cryptographic mechanisms do not have an indefinite lifetime, the IETF 186 hence anticipates updating default cryptographic mechanisms over 187 time. 189 The TBD default security function will need to be chosen such that it 190 can reasonably be implemented on a typical router route processor, 191 and which will provide adequate security without significantly 192 degrading the convergence time of a Label Switching Router (LSR). 194 Without a function that does not significantly impact router 195 convergence we simply close one vulnerability and open another. 197 Note: As experts on the LDP protocol, but not on security mechanisms, 198 we need to ask the security area for a review of our proposed 199 approach, and help correcting any misunderstanding of the security 200 issues or our misunderstanding of the existing security mechanisms. 201 We also need a recommendation on a suitable security function (TBD in 202 the above text). 204 4. Security Considerations 206 This document is entirely about LDP operational security. It 207 describes best practices that one should adopt to secure LDP messages 208 and the TCP based LDP sessions between LSRs. 210 This document does not aim to describe existing LDP implementations, 211 their potential vulnerabilities, or ways they handle errors. It does 212 not detail how protection could be enforced against attack techniques 213 using crafted packets. 215 5. IANA Considerations 217 There are no requests for IANA actions in this document. 219 Note to the RFC Editor - this section can be removed before 220 publication. 222 6. Acknowledgements 224 - 226 - 228 7. References 230 7.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 238 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 239 1998, . 241 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 242 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 243 October 2007, . 245 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 246 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 247 May 2017, . 249 7.2. Informative References 251 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 252 B. Thomas, "LDP Specification", RFC 3036, 253 DOI 10.17487/RFC3036, January 2001, 254 . 256 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 257 Routing Protocols (KARP) Design Guidelines", RFC 6518, 258 DOI 10.17487/RFC6518, February 2012, 259 . 261 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 262 BGP, LDP, PCEP, and MSDP Issues According to the Keying 263 and Authentication for Routing Protocols (KARP) Design 264 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 265 . 267 [RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello 268 Cryptographic Authentication", RFC 7349, 269 DOI 10.17487/RFC7349, August 2014, 270 . 272 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 273 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 274 February 2015, . 276 Authors' Addresses 278 Loa Andersson 279 Bronze Dragon Consulting 281 Email: loa@pi.nu 282 Stewart Bryant 283 Huawei Technologies 285 Email: stewart.bryant@gmail.com 287 Andrew G. Malis 288 Huawei Technologies 290 Email: agmalis@gmail.com 292 Nicolai Leymann 293 Deutsche Telekom 295 Email: N.Leymann@telekom.de 297 George Swallow 298 Independent 300 Email: swallow.ietf@gmail.com