Network Working Group M. Bhatia Request for Comments: 5310 Alcatel-Lucent Category: Standards Track V. Manral IP Infusion T. Li Redback Networks Inc. R. Atkinson Extreme Networks R. White Cisco Systems M. Fanto Aegis Data Security February 2009 IS-IS Generic Cryptographic Authentication Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
AbstractThis document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.
Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. 1. Introduction ....................................................2 1.1. Conventions Used in This Document ..........................3 2. IS-IS Security Association ......................................3 3. Authentication Procedures .......................................4 3.1. Authentication TLV .........................................4 3.2. Authentication Process .....................................5 3.3. Cryptographic Aspects ......................................5 3.4. Procedures at the Sending Side .............................7 3.5. Procedure at the Receiving Side ............................8 4. Security Considerations .........................................8 5. Acknowledgments .................................................9 6. IANA Considerations ............................................10 7. References .....................................................10 7.1. Normative References ......................................10 7.2. Informative References ....................................11 ISO], [RFC1195]) allows for authentication of its Protocol Data Units (PDUs) via the authentication TLV 10 that is carried as a part of the PDU. The base specification has provision for only cleartext passwords and RFC 5304 [RFC5304] augments this to provide the capability to use Hashed Message Authentication Code - Message Digest 5 (HMAC-MD5) authentication for its PDUs. The first octet of the 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. This document proposes a new authentication type to be carried in TLV 10, called the generic cryptographic authentication (CRYPTO_AUTH). This can be used to specify any authentication algorithm for authenticating and verifying IS-IS PDUs.
This document also explains how HMAC-SHA authentication can be used in IS-IS. By definition, HMAC ([RFC2104], [FIPS-198]) requires a cryptographic hash function. We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 [FIPS-180-3] to authenticate the IS-IS PDUs. We propose to do away with the per-interface keys and instead have Key IDs that map to unique IS-IS Security Associations (SAs). While at the time of this writing 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. The mechanism described in this document does not provide confidentiality, since PDUs are sent in the clear. However, the objective of a routing protocol is to advertise the routing topology, and confidentiality is not normally required for routing protocols. RFC2119].
Using Key IDs makes changing keys while maintaining protocol operation convenient. Each Key ID specifies two independent parts: the authentication protocol and the authentication key, explained below. Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document. Note that each Key ID can indicate a key with a different authentication protocol. This allows multiple authentication mechanisms to be used at various times without disrupting an IS-IS peering, including the introduction of new authentication mechanisms. o Authentication Algorithm: This signifies the authentication algorithm to be used with the IS-IS SA. This information is never sent in cleartext over the wire. Because this information is not sent on the wire, the implementer chooses an implementation- specific representation for this information. At present, the following values are possible: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. o Authentication Key: This value denotes the cryptographic authentication 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.
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+ | Type 10 | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+ | Auth Type 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | + + | Authentication Data (Variable)| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 FIPS-198] is used: H is the specific hashing algorithm (e.g., SHA-256). K is the password for the PDU type as per the International Standard ISO/IEC 10589 [ISO]. Ko is the cryptographic key used with the hash algorithm.
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 the 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 0x3. Then, a first hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (IS-IS PDU)) (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 resulting second hash becomes the authentication data that is sent in the Authentication Data field of the IS-IS PDU. 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 PDU as transmitted on the wire.
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 Complete Sequence Number PDUs (CSNPs) and Partial Sequence Number PDUs (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. 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 re-computation of the authentication data. This can be exploited by an attacker. There is a transition mode suggested where routers can ignore the CRYPTO_AUTH information carried in the PDUs. The operator must ensure that this mode is only used when migrating to the new CRYPTO_AUTH-based authentication scheme, as this leaves the router vulnerable to an attack. To ensure greater security, the keys used should be changed periodically, and implementations MUST be able to store and use more than one key at the same time. Operators should ensure that the authentication key is never sent over the network in cleartext via any protocol. Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness. 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. If a stronger authentication were believed to be required, then the use of a full digital signature [RFC2154] 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.
We would also 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 [RFC4822]. We would also like to mention Alfred Hoenes for his careful and detailed review during the last call. Lastly, we would like to acknowledge Brian and Stephen Eisenberg for their continued support. RFC5304]. The value 3 denotes the CRYPTO_AUTH mechanism for authenticating IS-IS PDUs. +--------------------------------------------+-------+-------------+ | Authentication Type Code | Value | Reference | +--------------------------------------------+-------+-------------+ | Cryptographic Authentication (CRYPTO_AUTH) | 3 | [RFC5310] | +--------------------------------------------+-------+-------------+ [FIPS-180-3] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008. [FIPS-198] US National Institute of Standards & Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002. [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. [RFC2104] Krawczk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, February 2001. [RFC5304] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008. [CRYPTO] Vishwas, M., White, R., and M. Bhatia, "Issues with existing Cryptographic Protection Methods for Routing Protocols", Work in Progress, February 2008. [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, May 1996. [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", Cryptobytes, Volume 2, No 2, Summer 1996. [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005. [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
Tony Li Redback Networks Inc. 300 Holger Way San Jose, CA 95134 USA EMail: email@example.com Randall J. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA EMail: firstname.lastname@example.org Russ White Cisco Systems RTP North Carolina USA EMail: email@example.com Matthew J. Fanto Aegis Data Security Dearborn, MI USA EMail: firstname.lastname@example.org