Internet DRAFT - draft-nslag-ietf-deprecate-md5
draft-nslag-ietf-deprecate-md5
MPLS Working Group L. Andersson
Internet-Draft Bronze Dragon Consulting
Intended status: Informational S. Bryant
Expires: September 2, 2018 A. Malis
Huawei Technologies
N. Leymann
Deutshe Telekom
G. Swallow
Independent
March 1, 2018
Deprecating MD5 for LDP
draft-nslag-ietf-deprecate-md5-00.txt
Abstract
When the MPLS Label Distribution Protocol (LDP) was specified circa
1999, there were very strong requirements that LDP should use a
cryptographic hash function to sign LDP protocol messages. MD5 was
widely used at that time, and was the obvious choices.
However, even when this decision was being taken there were concerns
as to whether MD5 was a strong enough signing option. This
discussion was briefly reflected in section 5.1 of RFC 5036 [RFC5036]
(and also in RFC 3036 [RFC3036]).
Over time it has been shown that MD5 can be compromised. Thus, there
is a concern shared in the security community and the working groups
responsible for the development of the LDP protocol that LDP is no
longer adequately secured.
This document deprecates MD5 as the signing method for LDP messages.
The document also selects a future method to secure LDP messages -
the choice is TCP-AO. In addition, we specify that the TBD
cryptographic mechanism is to be the default TCP-AO security method.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Andersson, et al. Expires September 2, 2018 [Page 1]
Internet-Draft Deprecating MD5 for LDP March 2018
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. LDP in RFC 5036 . . . . . . . . . . . . . . . . . . . . . 3
2.2. MD5 in BGP . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Prior Art . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Securing LDP . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
RFC 3036 was published in January 2001 as a Proposed Standard, and it
was replaced by RFC 5035, which is a Draft Standard, in October 2007.
Two decades after LDP was originally specified there is a concern
shared by the security community and the IETF working groups that
develop the LDP protocol that LDP is no longer adequately secured.
Andersson, et al. Expires September 2, 2018 [Page 2]
Internet-Draft Deprecating MD5 for LDP March 2018
LDP currently uses MD5 to cryptographically sign its messages for
security security purposes. However, MD5 is a hash function that is
no longer considered adequate to meet current security requirements.
1.1. Requirement Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Background
2.1. LDP in RFC 5036
In Section 5.1 "Spoofing" of RFC 5036 [RFC5036], in list item 2
"Session communication carried by TCP" the following statements are
made:
LDP specifies use of the TCP MD5 Signature Option to provide for
the authenticity and integrity of session messages.
RFC 2385 [RFC2385] asserts that MD5 authentication is now
considered by some to be too weak for this application. It also
points out that a similar TCP option with a stronger hashing
algorithm (it cites SHA-1 as an example) could be deployed. To
our knowledge, no such TCP option has been defined and deployed.
However, we note that LDP can use whatever TCP message digest
techniques are available, and when one stronger than MD5 is
specified and implemented, upgrading LDP to use it would be
relatively straightforward.
2.2. MD5 in BGP
There has been a similar discussion among working groups developing
the BGP protocol. BGP has already replaced MD5 with TCP-AO. This
was specified in RFC 7454 [RFC7454].
To secure LDP the same approach will be followed, TCP-AO will be used
for LDP also.
As far as we are able to ascertain, there is currently no
recommended, mandatory to implement, cryptographic function
specified. We are concerned that without such a mandatory function,
implementations will simply fall back to MD5 and nothing will really
be changed. The MPLS working group will need the expertise of the
Andersson, et al. Expires September 2, 2018 [Page 3]
Internet-Draft Deprecating MD5 for LDP March 2018
security community to specify a viable security function that is
suitable for wide scale deployment on existing network platforms.
2.3. Prior Art
RFC 6952 [RFC6952] dicusses a set of routing protocols that all are
using TCP for transport of protocol messages, according to guidelines
set forth in Section 4.2 of "Keying and Authentication for Routing
Protocols Design Guidelines", RFC 6518 [RFC6518].
RFC 6952 takes a much broader approach than this document, it
discusses several protcols and also securing the LDP session
initialization. This document has a narrower scope, securing LDP
session messages only. LDP in initialization mode is addressed in
RFC 7349 [RFC7349].
RFC 6952 and this document, basically suggest the same thing, move to
TCP-AO and deploy a strong cryotoigraphic algorithm.
All the protcols discuseed in RFC 6952 should adopt the approach to
securing protocol messages over TCP.
3. Securing LDP
Implementations conforming to this RFC MUST implement TCP-AO to
secure the TCP sessions carrying LDP in addition to the currently
required TCP MD5 Signature Option.
A TBD cryptographic mechanism must be implemented and provided to
TCP-AO to secure LDP messages.
The TBD mechanism is the preferred option, and MD5 SHOULD only to be
used when TBD is unavailable.
Note: The authors are not experts on this part of the stack, but it
seems that TCP security negotiation is still work in progress. If we
are wrong, then we need to include a requirement that such
negotiation is also required. In the absence of a negotiation
protocol, however, we need to leave this as a configuration process
until such time as the negotiation protocol work is complete. On
completion of a suitable negotiation protocol we need to issue a
further update requiring its use.
Cryptographic mechanisms do not have an indefinite lifetime, the IETF
hence anticipates updating default cryptographic mechanisms over
time.
Andersson, et al. Expires September 2, 2018 [Page 4]
Internet-Draft Deprecating MD5 for LDP March 2018
The TBD default security function will need to be chosen such that it
can reasonably be implemented on a typical router route processor,
and which will provide adequate security without significantly
degrading the convergence time of a Label Switching Router (LSR).
Without a function that does not significantly impact router
convergence we simply close one vulnerability and open another.
Note: As experts on the LDP protocol, but not on security mechanisms,
we need to ask the security area for a review of our proposed
approach, and help correcting any misunderstanding of the security
issues or our misunderstanding of the existing security mechanisms.
We also need a recommendation on a suitable security function (TBD in
the above text).
4. Security Considerations
This document is entirely about LDP operational security. It
describes best practices that one should adopt to secure LDP messages
and the TCP based LDP sessions between LSRs.
This document does not aim to describe existing LDP implementations,
their potential vulnerabilities, or ways they handle errors. It does
not detail how protection could be enforced against attack techniques
using crafted packets.
5. IANA Considerations
There are no requests for IANA actions in this document.
Note to the RFC Editor - this section can be removed before
publication.
6. Acknowledgements
-
-
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Andersson, et al. Expires September 2, 2018 [Page 5]
Internet-Draft Deprecating MD5 for LDP March 2018
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036,
DOI 10.17487/RFC3036, January 2001,
<https://www.rfc-editor.org/info/rfc3036>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012,
<https://www.rfc-editor.org/info/rfc6518>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication", RFC 7349,
DOI 10.17487/RFC7349, August 2014,
<https://www.rfc-editor.org/info/rfc7349>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <https://www.rfc-editor.org/info/rfc7454>.
Authors' Addresses
Loa Andersson
Bronze Dragon Consulting
Email: loa@pi.nu
Andersson, et al. Expires September 2, 2018 [Page 6]
Internet-Draft Deprecating MD5 for LDP March 2018
Stewart Bryant
Huawei Technologies
Email: stewart.bryant@gmail.com
Andrew G. Malis
Huawei Technologies
Email: stewart.bryant@gmail.com
Nicolai Leymanm
Deutshe Telekom
Email: N.Leymann@telekom.de
George Swallow
Independent
Email: swallow.ietf@gmail.com
Andersson, et al. Expires September 2, 2018 [Page 7]
