Internet Draft draft-bhatia-manral-crypto-req-isis-00.txt July 2006 Network Working Group Manav Bhatia Internet Draft Lucent Technologies Expires: January 2007 Vishwas Manral IP Infusion Cryptographic Algorithm Implementation Requirements for IS-IS draft-bhatia-manral-crypto-req-isis-00.txt Status of this Memo 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. The IETF takes no position regarding the validity or scope of any 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. 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: Bhatia and Manral [Page 1]
Internet Draft draft-bhatia-manral-crypto-req-isis-00.txt July 2006 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html This memo is a contribution to the IETF and is intended for future standards-track publication to update RFC-2082 and RFC-2453. This memo is not the product of any IETF working group. Distribution of this memo is unlimited. Abstract IS-IS currently defines two different kinds of authentication schemes: Clear Text password and HMAC-MD5. There has been recently a new draft submitted that adds support for a generic cryptographic authentication scheme, which can make use of different cryptographic algorithms in order to authenticate the IS-IS PDUs. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms to ensure 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 for IS-IS 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 [KEYWORDS] 1. Introduction IS-IS [ISO] [RFC1195] specification allows for authentication of its 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 3567 [RFC3567] augments this to provide the capability to use HMAC-MD5 authentication for its PDUs. In the clear text 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 IS-IS domain. Bhatia and Manral [Page 2]
Internet Draft draft-bhatia-manral-crypto-req-isis-00.txt July 2006 The HMAC-MD5 scheme is also not good enough as there have recently been reports about attacks on the collision resistance properties of MD5 [MD5-attack]. MD5CRK, was a distributed computing project to break the MD5 hash algorithm in a short period of time. The project closed down with the publication of the paper [MD5-attack]. It was discovered that collisions can be found in MD5 algorithm in less than 24 hours, making MD5 very insecure. Further research has verified this result and shown other ways to find collisions in MD5 hashes. We thus need to move away from MD5 towards more complex and difficult to break hash algorithms. The [ISIS-HMAC] document recently submitted in the IETF addresses this. It is imperative that we move away from using MD5 to something thats cryptographically more stronger (like HMAC-SHA-1). 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 IS-IS specification. 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]. We define some additional terms here: SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD- will be deprecated to a MAY or worse in a future version of this document. MUST- This term means the same as MUST. However, we expect that at some point in the future this algorithm will no Bhatia and Manral [Page 3]
Internet Draft draft-bhatia-manral-crypto-req-isis-00.txt July 2006 longer be a MUST. 3. 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. Old Old New Req. RFC Requirement Authentication Scheme --- ------ ----------- ------------------------ MUST ISO-10589/ SHOULD NOT Clear Text Password (1) 1195 MUST 3567 MUST- HMAC-MD5 - - SHOULD+ Cryptographic Auth [ISIS-HMAC] The above is only true in case security is required, if there is no requirement of security from an implementation, the above requirements need not be followed Notes: (1)This is used when all the routers can trust one another but the operator does not want an accidental introduction of a router in the domain. This scheme of authentication is useful, but not when the operator wants to cryptographically authenticate the OSPF packets. 4. 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. Old Old New Req. RFC Requirement Authentication Algorithm --- ------ ----------- ------------------------ MUST 3567 MUST- HMAC-MD5 - - SHOULD+ HMAC-SHA-1 [ISIS-HMAC] - - MAY+ HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 5. Security Considerations Bhatia and Manral [Page 4]
Internet Draft draft-bhatia-manral-crypto-req-isis-00.txt July 2006 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 IS-IS, 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. 6. Acknowledgements Much of the wording herein was adapted from RFC 4307, "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2", by Jeffrey I. Schiller. 7. IANA Considerations This document places no requests to IANA. 8. References 8.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119 [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. Bhatia and Manral [Page 5]
Internet Draft draft-bhatia-manral-crypto-req-isis-00.txt July 2006 [RFC3567] Li, T. and R. Atkinson, Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003 [ISIS-HMAC] Bhatia, M., Manral, V. and White, R.,"ISIS HMAC Cryptographic Authentication, Work in Progress 8.2 Informative References [MD5-attack] Wang, X. et al., "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 2004, http://eprint.iacr.org/2004/199 9. Author's Addresses Manav Bhatia Lucent Technologies Bangalore, India Email: manav@lucent.com Vishwas Manral IP Infusion Bangalore, India Email: vishwas@ipinfusion.com 10. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it as made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Bhatia and Manral [Page 6]
Internet Draft draft-bhatia-manral-crypto-req-isis-00.txt July 2006 11. Full Copyright Notice Copyright (C) The Internet Society (2006). 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 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. Bhatia and Manral [Page 7]