Internet Draft December 2008 Network Working Group Manav Bhatia Internet Draft Alcatel-Lucent Expires: May 2009 Vishwas Manral Intended Status: Informational IP Infusion Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols draft-bhatia-manral-igp-crypto-requirements-03.txt Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The interior gateway routing protocols Open Shortest Path First version 2 (OSPFv2) [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and Message Digest 5 (MD5) [RFC1321] algorithms for authenticating their protocol packets. There have recently been documents adding support of the Secure Hash Algorithm (SHA) family of hash functions for authenticating routing protocol packets for RIP [RFC4822], IS-IS [ISIS-HMAC] and OSPF [OSPF- HMAC]. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms Bhatia and Manral [Page 1] Internet Draft December 2008 thereby ensuring that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication of these routing protocols as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119] Table of Contents 1. Introduction...................................................2 2. Requirements Terminology.......................................3 3. Intermediate System to Intermediate System (IS-IS).............4 3.1 Authentication Scheme Selection............................4 3.2 Authentication Algorithm Selection.........................4 4. Open Shortest Path First Version 2(OSPFv2).....................5 4.1 Authentication Scheme Selection............................5 4.2 Authentication Algorithm Selection.........................6 5. Open Shortest Path First Version 3 (OSPFv3)....................6 6. Routing Information Protocol Version 2 (RIPv2).................6 6.1 Authentication Scheme Selection............................7 6.2 Authentication Algorithm Selection.........................7 7. Routing Information Protocol for IPv6 (RIPng)..................8 8. Security Considerations........................................8 9. Acknowledgements...............................................8 10. IANA Considerations...........................................8 11. References....................................................9 11.1 Normative References......................................9 11.2 Informative References....................................9 12. Author's Addresses...........................................10 1. Introduction Most routing protocols include three different types of authentication schemes: Null authentication, Clear Text Password and a Cryptographic Authentication scheme. NULL authentication is akin to having no authentication at all. In the clear text scheme, also sometimes known as, simple password scheme, of authentication, the passwords are exchanged in the clear text on the network and anyone with physical access to the network can learn the password and compromise the security of the routing domain. Bhatia and Manral [Page 2] Internet Draft December 2008 In the cryptographic authentication scheme, the routers share a secret key which is used to generate a keyed MD5 digest which is used for authenticating the protocol packets. This is not good enough as there have been recent reports about attacks on MD5 which raises concerns about the remaining useful lifetime of this scheme. Specifically, the researchers have been able to develop algorithms that can compute hash collisions for some applications of MD5 [MD5-attack]. It was discovered that collisions can be found in MD5 algorithm in less than 24 hours, making MD5 insecure. Further research has verified this result and shown other ways to find collisions in MD5 hashes. It should however be noted that these attacks may not necessarily result in direct vulnerabilities in Keyed-MD5 as used in the routing protocols for authentication purposes, because the colliding message may not necessarily be a syntactically correct protocol packet. However, there is a need felt to move away from MD5 towards more complex and difficult to break hash algorithms. In light of this there have been proposals for adding support of the SHA family of hash algorithms for authenticating routing protocol packets for RIP, IS-IS and OSPF. However, the nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the likelihood of it being compromised quickly. Also, we need to recognize that the mandatory-to-implement algorithm(s) may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms should not be included in the base protocol specifications. This way it is only this document that needs to get updated, whenever there is a need to update the status of mandatory- to-implement authentication algorithms. 2. Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. Bhatia and Manral [Page 3] Internet Draft December 2008 3. Intermediate System to Intermediate System (IS-IS) IS-IS specification allows for authentication of its Protocol Data Units (PDUs) via the authentication TLV 10 that is carried as the part of the PDU. The base spec has provision for only clear text passwords and RFC 5304 [RFC5304] augments this to provide the capability to use HMAC-MD5 authentication for its PDUs. The [ISIS-HMAC] document recently submitted in the IETF adds support for SHA family of hash algorithms for authenticating IS-IS PDUs. 3.1 Authentication Scheme Selection For IS-IS implementations to interoperate, they must support one or more authentication schemes in common. This section specifies the requirements for standards conformant IS-IS implementations, which desire to utilize the security feature. The earlier requirement posited by [ISO] [RFC1195] required all implementations to support Clear Text Password. It should be noted that this scheme of authentication must only be used when all the Intermediate Systems (IS) can "trust" one another and the operator does not want an accidental introduction of a new IS in the domain. We think that the operator must not use this scheme as it only provides a false sense of security as anyone can determine the secret password by inspecting the PDU. It MUST be implemented but its use is deprecated if the operator desires to secure IS-IS PDUs. [RFC5304] defines HMAC-MD5 as a MUST for cryptographically authenticating the IS-IS PDUs. It is a MUST currently with the understanding that it can be superseded by the generic cryptographic authentication scheme defined in [ISIS-HMAC]. HMAC-MD5 thus MUST be implemented, but its use may be deprecated in future. IS-IS implementations SHOULD provide support for the generic cryptographic authentication scheme and it is our understanding that this will change to a MUST as all operators start migrating to this scheme of authentication. 3.2 Authentication Algorithm Selection For IS-IS implementations to interoperate, they must support one or more authentication algorithms in common that can be used in the cryptographic scheme of authentication. This section details the authentication algorithm requirements for standards conformant IS-IS implementations. Bhatia and Manral [Page 4] Internet Draft December 2008 HMAC-MD5 is a MUST as defined in [RFC5304]. It is our understanding that this will get superseded by HMAC-SHA-1 as defined in [ISIS- HMAC]. HMAC-MD5 thus MUST be implemented, but its use may get deprecated in future. Operators should thus start migrating towards HMAC-SHA-1 if they want to use cryptographic authentication for authenticating IS-IS PDUs. Implementations may start providing support for HMAC-SHA-256/HMAC- SHA-384/HMAC-SHA-512 as these algorithms may get upgraded to a SHOULD in the future. 4. Open Shortest Path First Version 2(OSPFv2) OSPFv2 as defined in [RFC2328] includes three different types of authentication schemes: Null authentication, simple password and cryptographic authentication. NULL authentication is akin to having no authentication at all. In the simple password scheme of authentication, the passwords are exchanged in the cleartext on the network and anyone with physical access to the network can learn the password and compromise the security of the OSPFv2 domain. In the cryptographic authentication scheme, the OSPFv2 routers on a common network/subnet share a secret key which is used to generate a keyed MD5 digest for each packet and a monotonically increasing sequence number scheme is used to prevent replay attacks. The [OSPF-HMAC] document submitted in the IETF adds support for SHA family of hash algorithms for authenticating OSPFv2 packets. 4.1 Authentication Scheme Selection For OSPF implementations to interoperate, they must support one or more authentication schemes in common. This section specifies the requirements for standards conformant OSPFv2 implementations, which desire to utilize the security feature. Null Authentication is a MUST as defined in [RFC2328], however its use is deprecated if the operator wants to secure the OSPFv2 packets in their network. Simple Password defined as a MUST in [RFC2328] must only be used when all the routers can "trust" one another and the operator does not want an accidental introduction of a router in the domain. This scheme is useful, but not when the operator wants to "cryptographically" authenticate the OSPFv2 packets Cryptographic Authentication is a MUST as defined in [RFC2328] and all operators MUST use this. Bhatia and Manral [Page 5] Internet Draft December 2008 4.2 Authentication Algorithm Selection For OSPFv2 implementations to interoperate, they must support one or more authentication algorithms in common that can be used in the cryptographic scheme of authentication. This section details the authentication algorithm requirements for standards conformant OSPF implementations. Keyed MD5 is a MUST as defined in [RFC2328]. It is our understanding that this will get superseded by HMAC-SHA-1 as defined in [OSPF- HMAC]. Keyed MD5 thus MUST be implemented, but its use may get deprecated in future. Implementations should start providing support for HMAC-SHA-1 as this will get promoted to a MUST in the future. Operators should meanwhile start migrating towards HMAC-SHA-1 if they want to use stronger cryptographic algorithms for authenticating their OSPFv2 packets. Implementations may start providing support for HMAC-SHA-256/HMAC- SHA-384/HMAC-SHA-512 as these algorithms may get upgraded to a SHOULD in the future. 5. Open Shortest Path First Version 3 (OSPFv3) OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] to provide integrity, authentication, and/or confidentiality. The algorithm requirements for AH and ESP are described in [RFC4835] and are hence not discussed here. 6. Routing Information Protocol Version 2 (RIPv2) RIPv2, originally specified in [RFC1388], then [RFC1723], has been finalized in STD56 [RFC2453]. If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. This version of the protocol provides for authenticating packets by using a simple password in which the password is sent in clear. "RIP-2 MD5 Authentication" [RFC2082] adds support for Keyed-MD5 where a digest is added to the end of the RIP packet. "RIPv2 Cryptographic Authentication" [RFC4822] obsoletes [RFC2082] and adds details of how the SHA family of hash algorithms can be used to protect RIPv2, whereas [RFC2082] only specified the use of Keyed MD5. Bhatia and Manral [Page 6] Internet Draft December 2008 6.1 Authentication Scheme Selection For RIPv2 implementations to interoperate, they must support one or more authentication schemes in common. This section specifies the requirements for standards conformant RIPv2 implementations, which desire to utilize the security feature. Simple Password defined as a MUST in [RFC2453] must only be used when all the routers can "trust" one another and the operator does not want an accidental introduction of a RIP router in the domain. This scheme of authentication is useful, but not when the operator wants to protect RIPv2 messages in a hostile environment. Implementations MUST provide support for Simple Password, but its use is deprecated. Keyed-MD5 is a MUST as defined in [RFC2082]. This has been obsoleted by Cryptographic Authentication [RFC4822]. Compliant implementations MUST provide support for Keyed-MD5 as described in [RFC2082] but should recognize that this will get superseded by Cryptographic Authentication as defined in [RFC4822]. Implementations should start providing support for Cryptographic Authentication as this will get promoted to a MUST in the future. 6.2 Authentication Algorithm Selection For RIPv2 implementations to interoperate, they must support one or more authentication algorithms in common that can be used in the cryptographic scheme of authentication. This section details the authentication algorithm requirements for standards conformant OSPF implementations. Keyed MD5 algorithm is a MUST in [RFC2082] and [RFC4822], and must thus be implemented. It is our understanding that this will get superseded by HMAC-SHA-1 as defined in [RFC4822]. Keyed MD5 thus MUST be implemented, but its use may get deprecated in future. Implementations should start providing support for HMAC-SHA-1 as this will get promoted to a MUST in the future. Operators should start migrating towards HMAC-SHA-1 if they want to use stronger cryptographic algorithms for authenticating their RIPv2 packets. Bhatia and Manral [Page 7] Internet Draft December 2008 Implementations may start providing support for HMAC-SHA-256/HMAC- SHA-384/HMAC-SHA-512 as these algorithms may get upgraded to a SHOULD in the future. 7. Routing Information Protocol for IPv6 (RIPng) RIPng [RFC2080] relies on the IPv6 AH and IPv6 ESP to provide integrity, authentication, and/or confidentiality. The algorithm requirements for AH and ESP are described in [RFC4835] and are hence not discussed here. 8. Security Considerations The cryptographic mechanisms defined in this document define only authentication algorithms, and do not provide any confidentiality. However encrypting the content of the packet (providing confidentiality) is not of as great a value to routing protocols as authenticating the source of the packet. It should be noted that the cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function and on the size and quality of the key. To ensure greater security, the keys used must be changed periodically and implementations MUST be able to store and use more than one key at the same time. This document concerns itself with the selection of cryptographic algorithms for the use of routing protocols, specifically with the selection of "mandatory-to-implement" algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. However, this isn't necessarily forever. We would therefore expect that new revisions of this document will be issued from time to time that reflect the current best practice in this area. 9. Acknowledgements TBD 10. IANA Considerations This document places no requests to IANA. Bhatia and Manral [Page 8] Internet Draft December 2008 11. References 11.1 Normative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998 [ISO] "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473) ", ISO/IEC 10589:1992 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998 [RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119 [RFC5304] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008 [RFC5340] Coltun, R., et. al, "OSPF for IPv6", RFC 5340, July 2008. [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007 [RFC2080] Malkin, G. and Minnear, R., "RIPng for IPv6", RFC 2080, January 1997 [ISIS-HMAC] Bhatia, M., et. al., "IS-IS Generic Cryptographic Authentication", Work in Progress [OSPF-HMAC] Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA Cryptographic Authentication", Work in Progress 11.2 Informative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. Bhatia and Manral [Page 9] Internet Draft December 2008 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional Information", RFC 1388, January 1993. [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", STD 56, RFC 1723, November 1994. [RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC 2082, January 1997 [MD5-attack] Wang, X. et al., "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 2004, http://eprint.iacr.org/2004/199 12. Author's Addresses Manav Bhatia Alcatel-Lucent Bangalore, India Email: manav@alcatel-lucent.com Vishwas Manral IP Infusion Almora, Uttarakhand India Email: vishwas@ipinfusion.com Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Bhatia and Manral [Page 10] Internet Draft December 2008 Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Bhatia and Manral [Page 11]