Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 Network Working Group Manav Bhatia Internet Draft Riverstone Networks Expires: November 2006 Vishwas Manral IP Infusion Russ White Cisco Systems IS-IS HMAC SHA Cryptographic Authentication draft-bhatia-manral-isis-hmac-sha-01.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 Bhatia and Manral Expires November 2006 [Page 1] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 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 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 This document proposes an extension to IS-IS [ISO] [RFC1195] to allow the use of HMAC SHA authentication algorithm in addition to the already documented authentication schemes described in the base specification and RFC 3567. 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 specification as per ISO 10589 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. The first octet of value field of TLV 10 specifies the type of authentication to be carried out. Type 0 is reserved, Type 1 indicates a cleartext password, Type 54 indicates HMAC MD5 and Type 255 is used for routing domain private authentication methods. The remainder of the value field contains the actual authentication data determined by the value of the authentication type. By definition, HMAC [RFC2104] requires a cryptographic hash function. We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 [NIST] for this purpose to authenticate the IS-IS PDUs. Bhatia and Manral Expires November 2006 [Page 2] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 This document proposes new authentication types for HMAC-SHA-1, HMAC- SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 and specifies algorithms for computing the authentication value. We propose to do away with the per interface keys and instead have key IDs that map to unique IS-IS Security Associations. We use the term HMAC-SHAx in this document to denote HMAC computed by using any one of the SHA family of cryptographic hash functions. 2. IS-IS Security Association An IS-IS Security Association (SA) contains a set of shared parameters between any two legitimate IS-IS speakers. Parameters associated with an IS-IS SA: Key ID – This is an 8 bit unsigned value which is used to uniquely identify an IS-IS SA and would be configured by the administrator. The receiver determines the active SA by looking at this field in the incoming PDU. The sender puts this Key ID based on the active configuration. Using Key IDs makes the key rollover convenient and an implementation can choose to associate an age with each Key ID and can automatically use the next key when the former expires. Discussion of how this should be done is beyond the scope of this document. The sender when doing a key rollover will use a different Key ID (which is shared with the receiver). As the receiver will have the key with the same Key ID it can use that key for calculating the hash. The receiver does not need to compute the hash with multiple keys which are valid at that instant. Thus using the Key ID can safeguard against potential DoS attacks during the key rollover. Authentication Algorithm – This information is never sent over the wire and it signifies the authentication algorithm to be used with the IS-IS SA. Valid values are HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA- 256, HMAC-SHA-384 and HMAC-SHA-512 Authentication Key – This value is never sent on the wire and denotes the key associated with the IS-IS SA. The length of this key is variable and depends upon the authentication algorithm specified by the IS-IS SA. Bhatia and Manral Expires November 2006 [Page 3] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 3. Authentication Procedures 3.1 Authentication TLV We intend to use the existing Authentication TLV (10) for our purpose. The first octet of the value field of this TLV specifies the type of authentication to be applied. IANA needs to supply code numbers for HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 that need to be filled here. +---------------------------------------+ | Type 10 (1 Octet) | +---------------------------------------+ | Length (1 Octet) | +---------------------------------------+ | Authentication Type (1 Octet) | +---------------------------------------+ | Key ID (1 Octet) | +---------------------------------------+ | | + Authentication Data (Variable) + | | +---------------------------------------+ Figure 1 The HMAC algorithm takes key K and text T as the input. The block size B is 64 for SHA-1, SHA-224 and SHA-256 and its 128 for SHA-384 and SHA-512 The Key K is the password that has been chosen and text T is the IS- IS PDU that needs to be authenticated. 3.2 Procedures at the Sending Side An appropriate IS-IS SA is selected for use with an outgoing IS-IS PDU. This is done based on the active Key ID at that instant. This gives the authentication algorithm that needs to be applied on the PDU. An implementation MUST fill the authentication type and the length before the authentication data is computed. The length of the TLV is set as per the authentication algorithm that is being used. It’s set to 22 for HMAC-SHA-1, 30 for HMAC-SHA-224, 34 for HMAC-SHA- 256, 50 for HMAC-SHA-384 and 66 for HMAC-SHA-512. Note that 1 byte Bhatia and Manral Expires November 2006 [Page 4] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 has been added to account for the 8 bit Key ID and 1 byte for the authentication type. The authentication value field is set to Zero. The checksum and remaining life time fields are set to Zero for the LSPs before authentication is calculated. The result of the authentication algorithm is placed in the Authentication data, after the key ID. The authentication data for the IS-IS IIH PDUs is computed after the IIH has been padded to the MTU size, if padding is not explicitly disabled. 3.3 Procedure at the Receiving Side The appropriate IS-IS SA is identified by looking at the Key ID from the Authentication TLV 10 from the IS-IS PDU. Authentication algorithm dependent processing, needs to be performed, using the algorithm specified by the appropriate IS-IS SA for the received packet. Before an implementation performs any processing it needs to save the values of the Authentication value field, the checksum and the remaining life time. These fields are set to Zero and the authentication data is computed. The calculated data is compared with the received authentication data in the PDU and the PDU is discarded if the two do not match. In such a case, an error event SHOULD be logged. An implementation MAY have a transition mode where it includes HMAC- SHAx authentication information in the PDUs but does not verify the HMAC-SHAx information. This is provided as a transition aid for networks in the process of migrating to HMAC-SHA1, HMAC-224, HMAC- 256, HMAC-SHA-384 and HMAC-SHA-512 based authentication schemes. Similarly, implementations not supporting these authentication schemes MAY accept PDUs that contain HMAC-SHA authentication data. 4. Algorithm Dependent Processing HMAC is a mechanism for message authentication using cryptographic hash functions and has been explained in depth in [RFC 2104]. The reader is suggested to go through it to clearly understand how it works. HMAC can be used, without modifying any hash function, for calculating and verifying the message authentication values. It thus verifies both the data integrity and the authenticity of a message. Bhatia and Manral Expires November 2006 [Page 5] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 Because of the way the hash functions are used in HMAC construction, the collision attacks currently known against MD5 [MD5-attack] and SHA-1 [SHA-1-attack] do not apply. 5. Security Considerations The document proposes extensions to IS-IS which would make it more secure than what it is today. It does not provide confidentiality as a routing protocol contains information that does not need to be kept secret. It does however, provide means to authenticate the sender of the PDUs which is of interest to us. The mechanism detailed in this document does not protect IS-IS against replay attacks. An adversary could in theory replay old IIHs and bring down the adjacency [CRYPTO] or replay old CSNPs and PSNPs that would cause a flood of LSPs in the network. Using some sort of crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to solve this problem. Discussing this is beyond the scope of this document and it’s a matter which needs to be followed in the WG. This document states that the remaining lifetime of the LSP MUST be set to zero before computing the authentication, thus this field is not authenticated. This field is excluded so that the LSPs may be aged by the ISes in between without requiring to recompute the authentication data. This can be exploited by an attacker. 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. 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. There are certain hash functions that require all the fields of the message text T to be filled with non zero values. Any extension using such hash functions to calculate the HMAC MUST fill the life time, checksum and the authentication value field of the TLV with some pre- defined non zero random number. 6. Acknowledgements We would like to thank Ran Atkinson and Tony Li for their comments and their earlier work on IS-IS authentication from which this draft has been derived. Thanks to Hugo Krawczyk, Arjen K. Lenstra (Bell Labs), Eric Grosse (Bell Labs) and Matthew J. Fanto (NIST) for educating us on some of the finer points related to Crypto Mathematics. Bhatia and Manral Expires November 2006 [Page 6] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 7. IANA Considerations IANA needs to give values for HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512. 8. References 8.1 Normative References [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. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003 [RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [NIST] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002 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 [SHA-1-attack] Wang, X. et al., "Collision Search Attacks on SHA1", February 2005, http://theory.csail.mit.edu/~yiqun/shanote.pdf [CRYPTO] Manral, V. et al., "Issues with existing Cryptographic Protection Methods for Routing Protocols", Work in Progress, February 2006 Bhatia and Manral Expires November 2006 [Page 7] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 9. Author's Addresses Manav Bhatia Riverstone Networks Bangalore, India Email: manav@riverstonenet.com Vishwas Manral IP Infusion Bangalore, India Email: vishwas@ipinfusion.com Russ White Cisco Systems RTP North Carolina USA Email: riw@cisco.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. 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 Bhatia and Manral Expires November 2006 [Page 8] Internet Draft IS-IS HMAC SHA Cryptographic Authentication April 2006 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 Expires November 2006 [Page 9]