Network Working Group Steven M. Bellovin Internet Draft AT&T Labs Research Expiration Date: October 2003 April 2003 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) draft-bellovin-tcpmd5app-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering do so for RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option", with regard to BGP-4, and in particular to permit publication of a revised version of RFC 1771 as a Draft Standard. Bellovin [Page 1] Internet Draft draft-bellovin-tcpmd5app-00.txt April 2003 1. Introduction The IETF Standards Process [RFC2026] requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. Pursuant to that, it is considering publishing the updated BGP-4 specification [RLH] as Draft Standard, despite the normative reference to [RFC2385], "Protection of BGP Sessions via the TCP MD5 Signature Option"; that protocol will remain a Proposed Standard. [RFC2385], which is widely implemented, is the only transmission security mechanism defined for BGP-4. Other possible mechanisms, such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used for this purpose. Given the long-standing requirement for security features in protocols, it is not possible to advance BGP-4 with no security; however, [RFC2385] is not strong enough for general use. 2. Draft Standard Requirements The requirements for Proposed Standards and Draft Standards are given in [RFC2026]. For Proposed Standards, [RFC2026] warns that: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. In other words, it is considered reasonable for flaws to be discovered in Proposed Standards. The requirements for Draft Standards are higher: A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. In other words, any document that has known deficiencies should not be promoted to Draft Standard. Bellovin [Page 2] Internet Draft draft-bellovin-tcpmd5app-00.txt April 2003 3. The TCP MD5 Signature Option [RFC2385], despite its 1998 publication date, describes a Message Authentication Code (MAC) that is considerably older. It utilizes a technique known as a "keyed hash function", using MD5 [RFC1321] as the hash function. At the time the original code was developed, this was believed to be a reasonable technique, especially if the key was appended to the data being protected, rather than being prepended. But cryptographic hash functions were never intended for use as MACs, and later cryptanalytic results showed that the construct was not as strong as was originally believed [PV1,PV2]. Worse yet, the underlying hash function, MD5, has shown signs of weakness [Dobbertin]. Accordingly, the IETF community has adopted HMAC [RFC2104], a scheme with provable security properties, as its standard MAC. Beyond that, [RFC2385] does not include any sort of key management technique. Common practice is to use a password as a shared secret between pairs of sites. This is not a good idea [Leech]. Other problems are documented in [RFC2385] itself, including the lack of a type code or version number, and the inability of systems using this scheme to accept certain TCP resets. Despite the widespread deployment of [RFC2385], the IESG has thus concluded that it is not appropriate for use in other contexts. [RFC2385] is not suitable for advancement to Draft Standard. 4. Usage Patterns for RFC 2385 Given the above analysis, it is reasonable to ask why [RFC2385] is still used for BGP. The answer lies in the deployment patterns peculiar to BGP. BGP connections inherently tend to travel over short paths. Indeed, most external BGP links are one hop. Furthermore, though internal BGP sesions are usually multi-hop, the links involved are generally inhabited only by routers rather than general-purpose computers; general-purpose computers are easier for attackers to use as TCP hijacking tools [Joncheray]. It is also the case that BGP peering associations tend to be long- lived and static. By contrast, many other security situations are more dynamic. This is not to say that such attacks cannot happen. (If they Bellovin [Page 3] Internet Draft draft-bellovin-tcpmd5app-00.txt April 2003 couldn't happen at all, there would be no point to any security measures.) Attackers could divert links at layers 1 or 2, or they could (in some situations) use ARP-spoofing at Ethernet-based exchange points. Still, on balance, BGP is employed in an environment that is less susceptible to this sort of attack. There is another class of attack against which BGP is extremely vulnerable: false route advertisements from more than one autonomous system (AS) hop away. However, neither [RFC2385] nor any other transmission security mechanism can block such attacks. Rather, a scheme such as S-BGP [Kent] would be needed. 5. LDP The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385]. Since LDP connections are always between routers and are always one hop long, the threat environment is similar to BGP's. Accordingly, we are no deprecating [RFC2385] for use with LDP. 6. Conclusions Given the above analysis, the IESG is persuaded that waiving the prerequisite requirement is the appropriate thing to do. [RFC2385] is clearly not suitable for Draft Standard. Other existing mechanisms, such as IPsec, would do its job better. But the marginal benefit of such schemes in this situation is low, and not worth the transition effort. We would prefer to wait for a security mechanism tailored towards the major threat environment for BGP. 7. References [Dobbertin] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. [Joncheray] Joncheray, L. "A Simple Active Attack Against TCP." Proceedings of the Fifth Usenix Unix Security Symposium, 1995. [Kent] Kent, S., C. Lynn, and K. Seo. "Secure Border Gateway Protocol (Secure-BGP)." IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, April, 2000, pp. 582-592. [Leech] Leech, M. "Security Requirements for Keys used with the TCP MD5 Signature Option." draft-ietf-idr-md5-keys, work Bellovin [Page 4] Internet Draft draft-bellovin-tcpmd5app-00.txt April 2003 in progress, 2002. [PV1] B. Preneel and P. van Oorschot, "MD-x MAC and building fast MACs from hash functions," Advances in Cryptology --- Crypto 95 Proceedings, Lecture Notes in Computer Science Vol. 963, D. Coppersmith, ed., Springer-Verlag, 1995. [PV2] B. Preneel and P. van Oorschot, "On the security of two MAC algorithms," Advances in Cryptology --- Eurocrypt 96 Proceedings, Lecture Notes in Computer Science, U. Maurer, ed., Springer-Verlag, 1996. [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm." RFC 1321. April, 1992. [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 3." RFC 2026. October 1996. [RFC2104] Krawczyk, H., M. Bellare, and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication." RFC 2104. February 1997. [RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0." RFC 2246. January, 1999. [RFC2385] Heffernan, A. "Protection of BGP Sessions via the TCP MD5 Signature Option." RFC 2385. August, 1998. [RFC2401] Kent, S. and R. Atkinson. "Security Architecture for the Internet Protocol." RFC 2401. November, 1998. [RFC3036] Andersson, L., P. DOolan, N. Feldman, A. Fredette, and B. Thomas. "LDP Specification." RFC 3036, January 2001. [RLH] Rekhter, Y., T. Li, and S. Hares. "A Border Gateway Protocol 4 (BGP-4)." draft-ietf-idr-bgp4, April 2003, work in progress. Bellovin [Page 5] Internet Draft draft-bellovin-tcpmd5app-00.txt April 2003 8. Author Information Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 Phone: +1 973-360-8656 email: bellovin@acm.org Bellovin [Page 6]