Internet Draft R. Atkinson <draft-li-isis-hmac-shs-01.txt> Extreme Networks Category: Informational T. Li Expires 28 Aug 2007 Cisco Systems Updates: RFC-3567 M. Fanto Ford Motor Company 28 February 2007 IS-IS Authentication with HMAC-SHS <draft-li-isis-hmac-shs-01.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 This document describes how the NIST Secure Hash Standard family of algorithms are used for IS-IS authentication. 1. INTRODUCTION This document provides an update to IS-IS Cryptographic Authentication, which is specified in RFC-3567. This document does not deprecate RFC-3567. IS-IS as deployed in the Internet is defined by RFC-1195 and ISO 10589. This document adds support for all algorithms defined in the Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 1]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 US NIST Secure Hash Standard (SHS) as defined in NIST FIPS 180-2. [FIPS-180-2] includes SHA-1, SHA-256, SHA-384, and SHA-512. The HMAC authentication mode as defined in NIST FIPS 198 is used. [FIPS-198] This creation of this addition to IS-IS was driven by operator requests that they be able to use the NIST SHS family of algorithms, in the NIST HMAC mode, instead of being forced to use the Keyed-MD5 algorithm and mode. While there are no openly published attacks on the HMAC-MD5 mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function. 2. AUTHENTICATION PROCEDURES The authentication type used for any of the HMAC-SHS algorithms is XX. The length of the Authentication Value varies with the specific hashing algorithm used. The length field in the TLV is the sum of the length of the Authentication Value field and the number 1. For example, when SHA-256 is in use, the length of the Authentication Value is 32 and the length field in the TLV is 33. 2.1 Authentication Process. When calculating the HMAC-SHS result for Sequence Number PDUs, Level 1 Sequence Number PDUs SHALL use the Area Authentication string as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the domain authentication string as in Level 2 Link State PDUs. IS-IS HELLO PDUs SHALL use the Link Level Authentication String, which MAY be different from that of Link State PDUs. The HMAC-SHS result for the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded to the MTU size, if padding is not disabled. Implementations that support the optional checksum for the Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the Checksum TLV. 2.2 Cryptographic Aspects In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used: H is the specific hashing algorithm (e.g. SHA-256). K is the password for the PDU type as per ISO 10589. Ko is the cryptographic key used with the hash algorithm. Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 2]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 B is the block size of H, measured in octets rather than bits. Note that B is the internal block size, not the hash size. For SHA-1 and SHA-256: B == 64 For SHA-384 and SHA-512: B == 128 L is the length of the hash, measured in octets rather than bits. XOR is the exclusive-or operation. Opad is the hexadecimal value 0x5c repeated B times. Ipad is the hexadecimal value 0x36 repeated B times. Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. (1) PREPARATION OF KEY In this application, Ko is always L octets long. If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K) such that Ko is L octets long. (2) FIRST HASH First, the IS-IS packet's Authentication Data field is filled with the value Apad and the Authentication Type field is set to XX. Then, a first hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (IS-IS Packet)) (3) SECOND HASH Then a second hash, also known as the outer hash, is computed as follows: Second-Hash = H(Ko XOR Opad || First-Hash) (4) RESULT The result Second-Hash becomes the Authentication Data that is sent in the Authentication Data field of the IS-IS packet. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used. This also means that the use of hash functions with larger output sizes will also increase the size of the IS-IS packet as transmitted on the wire. 2.3 Accepting Authenticated IS-IS Packets To authenticate an incoming PDU, a system should save the value Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 3]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 of the Authentication Value field, the Checksum, and the Remaining Lifetime fields. Then set the Authentication Value equal to Apad and zero the Checksum and Remaining Lifetime fields. The Authentication Value is then computed as described above, and finally the values of these three fields is restored. An implementation that implements HMAC-SHS authentication and receives HMAC-SHS Authentication Information MUST discard the PDU if the Authentication Value is incorrect. The implementation SHOULD log such authentication failures in some implementation specific manner. An implementation MAY have a transition mode where it includes HMAC-SHS Authentication Information in PDUs but does not verify the HMAC-SHS authentication information. This is a transition aid for networks in the process of deploying authentication. An implementation MAY check a set of passwords when verifying the Authentication Value. This provides a mechanism for incrementally changing passwords in a network. An implementation that does not implement HMAC-SHS authentication MAY accept a PDU that contains the HMAC-SHS Authentication Type. ISes (routers) that implement HMAC-SHS authentication and initiate LSP purges MUST remove the body of the LSP and add the authentication TLV. ISes implementing HMAC-SHS authentication MUST NOT accept unauthenticated purges. ISes MUST NOT accept purges that contain TLVs other than the authentication TLV. These restrictions are necessary to prevent a hostile system from receiving an LSP, setting the Remaining Lifetime field to zero, and flooding it, thereby initiating a purge without knowing the authentication password. 2.4 Implementation Considerations Conceptually, there is an "IS-IS Security Association", both in this specification and in RFC-3567. This security association consists of a cryptographic key (K), an authentication algorithm (e.g. SHA-256), a cryptographic mode (e.g. HMAC), a start time, and a stop time. Start Time is a local representation of the day and time when the security association first becomes valid. Stop Time is a local representation of the day and time when the security association ceases to be valid. However, this is an architectural concept and does not strictly constrain the implementation to follow precisely that representation internally. For example, one might choose to combine the authentication algorithm with the cryptographic mode as a single integrated datum inside a particular IS-IS implementation. Similarly, one might choose to store the Start Time and a time duration, in lieu of storing Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 4]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 the literal Start Time and Stop Time. In such a case, the Stop Time could be computed by adding the time duration to the Start Time. Note that it is permitted for an IS-IS Security Association to have infinite lifetime, although this is not recommended operational practice. In order to support smooth key rollover, an implementation MUST be able to support at least 2 concurrent IS-IS Security Associations. There is an implementation issue just after password rollover on an IS-IS router that might benefit from additional commentary. Immediately after password rollover on the router, the router or IS-IS process may restart. If this happens, this causes the LSP Sequence Number restarts from the value 1 using the new password. However, neighbors will reject those new LSPs because the Sequence Number is smaller. The router can not increase its own LSP Sequence Number because it fails to authenticate its own old LSP that neighbors keep sending to it. So the router can not update its LSP Sequence Number to its neighbors until all the neighbors time out all of the original LSPs. One possible solution to this problem is for the IS-IS process to detect if any inbound LSP with an authentication failure has the local System ID and also has a higher Sequence Number than the IS-IS process has. In this event, the IS-IS process SHOULD increase its own LSP Sequence Number accordingly and re-flood the LSPs. However, as this scenario could also be triggered by an active attack by an adversary, it is recommended that a counter also be kept on this case to mitigate the risk from such an active attack. 3. SECURITY CONSIDERATIONS This document enhances the security of the IS-IS routing protocol by adding support for additional cryptographic hash functions. Because a routing protocol contains information that need not remain secret, privacy is not a requirement. However, authentication of the messages within the protocol is of interest, to reduce the risk of an adversary compromising the routing system by deliberately injecting false information into the routing system. The technology in this document provides an authentication mechanism for IS-IS. The mechanism described here is not perfect and does not need to be perfect. Instead, this mechanism represents a significant increase in the work function of an adversary attacking the IS-IS protocol, while not causing undue implementation, deployment, or operational complexity. This mechanism does not prevent replay attacks, however, in most cases, such attacks would trigger existing mechanisms in the IS-IS Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 5]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 protocol that would effectively reject old information. Denial of service attacks are not generally preventable in a useful networking protocol [VK83]. Because of implementation considerations, including the need for backwards compatibility, this specification uses the same mechanism as specified in RFC-3567 and limits itself to adding support for additional cryptographic hash functions. Network operators have indicated they strongly prefer to retain the basic mechanism defined in RFC-3567. In particular, network operators have indicated a preference for omitting the Key-ID field used with OSPFv2 or RIPv2 authentication. They do not consider the absence of a Key-ID field in the packet problematic, given the existing successful deployments of "keychains" with IS-IS cryptographic authentication. If a stronger authentication were believed to be required, then the use of a full digital signature [RFC-2154] would be an approach that should be seriously considered. It was rejected for this purpose at this time because the computational burden of full digital signatures is believed to be much higher than is reasonable given the current threat environment in operational commercial networks. 4. IANA CONSIDERATIONS ISO 10589 created an Authentication Information TLV (code 10) for use in IS-IS routing protocol packets (PDUs). The first octet in the TLV is defined as the Authentication Type. ISO 10589 reserves the following IS-IS authentication code points: 0 - Reserved 1 - Cleartext Password 255 - Routeing Domain private authentication method ISO 10589 also reserves code points 2-254. This document requests that IANA create a new code point registry to administer the Authentication Type code points for TLV 10. This registry would be part of the existing IS-IS code points registry as established by RFC 3563 and RFC 3359. This registry should be managed using the Designated Expert policy as described in [RFC-2434]. This document also requests that IANA populate the registry with the code points described above and also reserve code point 54 for HMAC-MD5 authentication, as described by RFC 3567. This document also requests that IANA reserve a code point for HMAC-SHA authentication, as described by this document. The value for this Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 6]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 HMAC-SHA code point should be inserted into this document in Section 2 above, to replace the value XX found therein. [RFC Editor note: This section should be removed prior to RFC publication.] 5. ACKNOWLEDGEMENTS The authors would like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of portions of this document that are directly derived from the closely related work on RIPv2 Cryptographic Authentication [RFC-4822]. 6. REFERENCES 6.1 Normative References [ISO-10589] International Standards Organisation, "Intermediate System to Intermediate System Routing Information Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002. [FIPS-180-2] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002. [FIPS-198] US National Institute of Standards & Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002. [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC-2119, BCP-14, March 1997. [RFC-2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC-2434, October 1998. [RFC-3692] T. Narten, "Assigning Experimental and Testing Numbers Considered Useful. RFC-3692, January 2004. 6.2 Informative References [Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989. Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 7]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at the Rump Session of EuroCrypt 1996.) [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996. [RFC-1195] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990. [RFC-1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [RFC-2154] S. Murphy, M. Badger, and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [RFC-3359] T. Przygienda, "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC-3359, August 2002. [RFC-3563] A. Zinin, "Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development", RFC-3563, July 2003. [RFC-3567] T. Li, R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC-3567, July 2003. [RFC-4086] D. Eastlake III, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005 [RFC-4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007. [VK83] Voydock, V. and S. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. AUTHORS Randall J. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA Phone: +1 (408) 579-2800 Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 8]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 EMail: rja@extremenetworks.com Tony Li Cisco Systems San Jose, CA USA EMail: tli@cisco.com Matt Fanto Ford Motor Company Michigan USA EMail: tbd Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 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 Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 9]
Internet Draft IS-IS HMAC-SHS 28 Feb 2007 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. Atkinson, Li, & FantEoxpires 28 Aug 2007 [Page 10]