Internet Draft OSPF HMAC Cryptographic Authentication February 2007 Network Working Group Manav Bhatia Internet Draft Alcatel-Lucent Expires: August 2007 Vishwas Manral IP Infusion Russ White Michael Barnes Cisco Systems OSPF HMAC Cryptographic Authentication draft-bhatia-manral-white-ospf-hmac-sha-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 This document describes a mechanism for authenticating OSPF packets by making use of the HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. Because of the way the hash functions are used in HMAC construction, the collision attacks currently known against SHA-1 do not apply. This will be done in addition to the already documented authentication schemes described in the base specification. Conventions used in this document Bhatia, Manral and White [Page 1] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 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] Table of Contents 1. Introduction...................................................2 2. Standard OSPF Authentication...................................3 3. OSPF Security Association......................................4 4. Using New Algorithms for OSPF Authentication...................5 5. Authentication Procedures......................................5 5.1 Message Generation at the Sending Side.....................5 5.2 Message Verification at the Receiving Side.................6 6. Algorithm Dependent Processing.................................7 7. Security Considerations........................................7 8. Backwards Compatibility Considerations.........................8 9. IANA Considerations............................................8 10. Acknowledgements..............................................8 11. References....................................................8 11.1 Normative References......................................8 11.2 Informative References....................................8 12. Author's Addresses............................................9 1. Introduction OSPF 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 clear text on the network and anyone with physical access to the network can learn the password and compromise the security of the OSPF domain. In the cryptographic authentication scheme, the OSPF 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. This isn't good enough as there have recently been reports about attacks on the collision resistance properties of MD5 [MD5-attack] and SHA-1 [RFC3174][SHA-1-attack] hash functions. 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 Bhatia, Manral and White [Page 2] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 hashes. We thus need to move away from MD5 towards more complex and difficult to break hash algorithms. This document therefore adds support for HMAC [RFC2104] construction to be used for authenticating OSPF packets. HMAC can be used, without modifying any hash function, for calculating and verifying the message authentication values. It verifies both the data integrity and the authenticity of a message. Because of the way the hash functions are used in HMAC construction, the collision attacks currently known against MD5 and SHA-1 do not apply. By definition, HMAC 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 OSPF packets. This document explains how HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 shall work with OSPF. 2. Standard OSPF Authentication Figure 1 shows the standard 24 byte OSPF header as specified in [RFC2328]. The header includes an authentication type field (AuType) that identifies the authentication procedure to be used for the packet. Authentication is a 64 bit field of data to be used by the appropriate authentication scheme (determined by the type field). Authentication types 0, 1 and 2 are defined by [RFC2328] to be used for Null Authentication, Simple Password and Cryptographic authentication. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Bhatia, Manral and White [Page 3] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Key ID | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Figure 2 shows the way the authentication data MUST be filled in the OSPF header if the AuType is set to 2. The first 16 bits are set reserved to zero. Cryptographic authentication as specified in [RFC2328] allows for algorithms other than MD5 to be used without altering the protocol packets. Note the original definition of the Key ID field: This field identifies the algorithm and secret key used to create the message digest appended to the OSPF packet. Key Identifiers are unique per-interface (or equivalently, per-subnet). Also note step (6) in section D.4.3 "The authentication algorithm to be used in calculating the digest is indicated by the key itself." It is clear that the fields defined in section D.3 of [RFC2328] are adequate for the use of cryptographic algorithms other than MD5. The only actual difference in the OSPF protocol packets is that the HMAC is appended to the original OSPF packet instead of the MD5 digest. 3. OSPF Security Association This document defines an OSPF Security Association (SA) as a set of shared parameters between any two legitimate OSPF speakers. Parameters associated with an OSPF SA: Key ID – This is an 8 bit unsigned value which is used to uniquely identify an OSPF SA and would be configured by the administrator. The receiver determines the active SA by looking at this field in the incoming packet. 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. Bhatia, Manral and White [Page 4] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 When doing a key rollover the sender 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 OSPF SA. Valid values are MD5, 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 OSPF SA. The length of this key is variable and depends upon the authentication algorithm specified by the OSPF SA. 4. Using New Algorithms for OSPF Authentication The use of the cryptographic authentication fields as specified in [RFC2328] is essentially unchanged, but the definitions are updated in this document. The Key ID uniquely identifies an OSPF SA which gives the algorithm and the secret key used to create the HMAC appended to the OSPF packet. Auth Data Len is the length in octets of the HMAC appended to the OSPF packet. It is set to 20 for HMAC-SHA-1, 28 for HMAC-SHA-224, 32 for HMAC-SHA-256, 48 for HMAC-SHA-384 and 64 for HMAC-SHA-512. The HMAC is not considered a part of the OSPF message, and is not accounted for in the Packet Length field of the OSPF header. But as a part of the overall IP packet payload, it is accounted for in the Total Length field of the IP packet header Cryptographic sequence number is an unsigned 32 bit non-decreasing sequence number, which is used to protect against replay attacks. 5. Authentication Procedures This section details the procedures to be followed by the OSPF sending and the receiving sides. 5.1 Message Generation at the Sending Side When using HMAC cryptographic authentication the sender chooses the secret key by looking at the active SA and modifies the OSPF packet as follows: Bhatia, Manral and White [Page 5] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 [1] The AuType field in the OSPF header is set to 2. [2] The checksum field in the standard OSPF header is set to 0. [3] The Key ID is set to the current active key. [4] The Auth Data Len is set to the length in bytes of the HMAC that will be appended to the OSPF packet. This value depends upon the authentication algorithm that is being used. Refer to Section 3 for these values. [5] The non decreasing Cryptographic sequence number is filled. [6] The HMAC is then calculated and appended to the OSPF packet. The authentication algorithm is given by the active SA. Input to the authentication algorithm consists of the OSPF packet and the secret key. Refer to section 5 for algorithm dependent processing. 5.2 Message Verification at the Receiving Side All OSPF packets received on an interface must be authenticated. The following steps are followed: [1] The receiver determines the active SA by looking at the Key ID field from the standard OSPF packet header. Authentication algorithm dependent processing needs to be performed, using the algorithm specified by the appropriate OSPF SA for the received packet. [2] The packet is rejected if the cryptographic sequence number is less than the cryptographic sequence number stored in the sending neighbor's data structure. [3] Before performing any processing an implementation MUST save the value of the received HMAC. [4] The HMAC is calculated based on the authentication algorithm and the secret key that was derived from the active SA (derived from the incoming key). Refer to section 5 for algorithm dependent processing. [5] The calculated and the received HMACs are compared. The packet is only accepted if the two match. If there is a mismatch then the packet is discarded and a security even SHOULD be logged. Bhatia, Manral and White [Page 6] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 An implementation MAY have a transition mode where it includes HMAC- SHA authentication information in the OSPF packets but does not verify the HMAC-SHA 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 packets that contain HMAC-SHA authentication data. 6. Algorithm Dependent Processing HMAC is a mechanism for message authentication using cryptographic hash functions and has been explained in depth in [RFC2104]. The reader is suggested to go through it to clearly understand how it works. The HMAC algorithm takes key K and text T as the input. The block size B is 64 octets for SHA-1, SHA-224 and SHA-256 and is 128 octets for SHA-384 and SHA-512 The Key K is the secret key that has been chosen and text T is the OSPF packet that needs to be authenticated. [HMAC-SHA] provides open source code to perform these hash functions for the internet community. The sample code supports input strings of arbitrary bit length, as opposed to [RFC2104] which assumes the text T to be a multiple of 8 octets. Similarly, the SHA-1 sample code from [RFC3174] has been updated to handle input strings of arbitrary bit lengths. 7. Security Considerations The document proposes extensions to OSPF 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 packets which is of interest to us. The cryptographic sequence numbers used to prevent replay attacks can be exploited. These are initialized to zero when forming an adjacency with a newly discovered neighbor, or when a router comes up. A malicious router can store the OSPF packets from the previous session and can replay them. This can lead to loops and blackholes [CRYPTO]. 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. Bhatia, Manral and White [Page 7] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 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. 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 checksum field with some predefined non-zero random number. 8. Backwards Compatibility Considerations No changes are made to the operation of the OSPF protocol to implement cryptographic authentication algorithms as described in this document. Additionally, cryptographic authentication using MD5 is unchanged. So no backward compatibility issues are introduced by this document. 9. IANA Considerations This document includes no request to IANA. 10. Acknowledgements We would like to thank Acee Lindem for his comments on the draft. 11. References 11.1 Normative References [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119 [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 [HMAC-SHA] Eastlake 3rd, D., Hansen, T., “US Secure Hash Algorithms (SHA and HMAC-SHA)”, Work in Progress 11.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 Bhatia, Manral and White [Page 8] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 [RFC3174] Eastlake 3rd, D.,Jones, P., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [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 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 Russ White Cisco Systems RTP North Carolina USA Email: riw@cisco.com Michael Barnes Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: mjbarnes@cisco.com 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 Bhatia, Manral and White [Page 9] Internet Draft OSPF HMAC Cryptographic Authentication February 2007 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 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, Manral and White [Page 10]