Internet Draft BFD Generic Cryptographic Authentication November 2009 Network Working Group Manav Bhatia Internet Draft Alcatel-Lucent Intended Status: Proposed Standard Vishwas Manral Expires: April 2009 IP Infusion BFD Generic Cryptographic Authentication draft-bhatia-bfd-crypto-auth-00.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 proposes an extension for Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification. Although this document has been written specifically to introduce two new Authentication types it describes how BFD can use Hashed Message Authentication Code (HMAC) construct along with the Secure Hash algorithm (SHA) [FIPS-180-3] family of cryptographic hash functions to authenticate the control packets. The method described in this document is generic and can be used to extend BFD to support any cryptographic hash function in the future. Bhatia and Manral Expires April 2009 [Page 1] Internet Draft BFD Generic Cryptographic Authentication November 2009 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] Contents 1. Introduction...................................................2 2. BFD Security Association.......................................3 3. Authentication Procedures......................................4 3.1 Cryptographic Authentication and Meticulous Cryptographic Authentication.................................................4 3.2 Packet Encoding............................................5 3.3 Cryptographic Aspects......................................6 3.4 Procedures at the Sending Side.............................7 3.5 Procedure at the Receiving Side............................8 4. Security Considerations........................................8 5. Acknowledgements...............................................9 6. IANA Considerations............................................9 7. References.....................................................9 7.1 Normative References.......................................9 7.2 Informative References....................................10 8. Author's Addresses............................................10 1. Introduction Bidirectional Forwarding Detection (BFD) [BFD-BASE] specification includes five different types of authentication schemes: Simple Password, Keyed MD5 [RFC1321], Meticulous Keyed MD5, Keyed SHA-1 and Meticulous SHA-1. 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 BFD domain. In Keyed MD5 and Meticulous Keyed MD5, the BFD routers 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 isnt good enough as there have been recent reports about attacks on MD5 which raises concerns about the remaining useful lifetime of this scheme. Specifically, the researchers have been able to develop algorithms that can compute hash collisions for some applications of MD5 [MD5-attack] [Dobb96a, Dobb96b]. Bhatia and Manral Expires April 2009 [Page 2] Internet Draft BFD Generic Cryptographic Authentication November 2009 It was discovered that collisions can be found in MD5 algorithm in less than 24 hours, making MD5 insecure. Further research has verified this result and shown other ways to find collisions in MD5 hashes. It should however be noted that these attacks may not necessarily result in direct vulnerabilities in Keyed-MD5 as used in BFD authentication purposes, because the colliding message may not necessarily be a syntactically correct protocol packet. However, there is a need felt to move away from MD5 towards more complex and difficult to break hash algorithms. In Keyed SHA-1 and Meticulous SHA-1, the BFD routers share a secret key which is used to generate a keyed SHA-1 digest for each packet and a monotonically increasing sequence number scheme is used to prevent replay attacks. Like MD5 there have been reports of attacks on SHA-1 [SHA-1-attack1] [SHA-1-attack2]. Such attacks do not mean that all the protocols using SHA-1 for authentication are at risk. However, it does mean that SHA-1 should be replaced as soon as possible and should not be used for new applications. However, if SHA-1 is used in the HMAC [RFC2104] construction then collision attacks currently known against SHA-1 do not apply. The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1. 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. This document proposes two new authentication types - the cryptographic authentication (CRYPTO_AUTH) and the meticulous cryptographic authentication (MET_ CRYPTO_AUTH). These can be used to specify any authentication algorithm for authenticating and verifying the BFD packets. In addition to this, this memo also explains how HMAC-SHA authentication can be used for BFD. By definition, HMAC requires a cryptographic hash function. We propose to use any one of SHA-1, SHA-256, SHA-384 and SHA-512 for this purpose to authenticate the BFD packets. 2. BFD Security Association A BFD Security Association (SA) contains a set of shared parameters between any two legitimate BFD routers. Parameters associated with a BFD SA: Bhatia and Manral Expires April 2009 [Page 3] Internet Draft BFD Generic Cryptographic Authentication November 2009 O Authentication Key ID : This is a two octet unsigned integer used to uniquely identify the BFD SA, as manually configured by the network operator. 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 changing keys while maintaining protocol operation convenient. Each key ID specifies two independent parts, the authentication protocol and the authentication key, as 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 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 BFD sessions, 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 key associated with the BFD SA. The length of this key is variable and depends upon the authentication algorithm specified by the BFD SA. Operators MUST ensure that this is never sent over the network in clear-text 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. 3. Authentication Procedures 3.1 Cryptographic Authentication and Meticulous Cryptographic Authentication The Authentication section is only present in the BFD packet if the Authentication Present (A) bit is set in the header. The Auth Type in the Authentication section is set to 6 to indicate the Cryptographic Authentication is in use, and is set to 7, to indicate that the meticulous cryptographic authentication is in use. Bhatia and Manral Expires April 2009 [Page 4] Internet Draft BFD Generic Cryptographic Authentication November 2009 Both the authentication types use a monotonically increasing sequence number to protect the BFD session against reply attacks. The only difference between the two types is that the sequence number is occasionally incremented in the Cryptographic Authentication mode, as against the Meticulous Cryptographic Authentication mode, where it is incremented on every packet. As a result of this a replay attack is possible till the next sequence number is sent in the Cryptographic Authentication scheme. 3.2 Packet Encoding A new authentication type, 6 or 7, indicating the cryptographic authentication mechanism in use, is inserted in the first octet of Authentication Section of the BFD control packet. If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 6 (Cryptographic Authentication) or 7 (Meticulous Cryptographic Authentication), the Authentication Section has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Auth Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Type The Authentication Type, which in this case is 6 (Cryptographic Authentication) or 7 (Meticulous Cryptographic Authentication). Auth Len Length of the Authentication Section. Auth Key ID The Authentication Key ID in use for this packet. This allows multiple keys to be active simultaneously. Sequence Number Bhatia and Manral Expires April 2009 [Page 5] Internet Draft BFD Generic Cryptographic Authentication November 2009 The Sequence Number for this packet. For Cryptographic Authentication this value is incremented occasionally. For Meticulous Cryptographic Authentication, this value is incremented for each successive packet transmitted for a session. Authentication Data This field carries the digest computed by whatever Cryptographic Authentication algorithm is being used to authenticate the BFD control packet. 3.3 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 BFD packet. 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 Authentication Data field in the BFD Auth Section is filled with the value Apad and the Authentication Type field is set to 6 or 7 depending upon which Authentication Type is being Bhatia and Manral Expires April 2009 [Page 6] Internet Draft BFD Generic Cryptographic Authentication November 2009 used. The Sequence Number field MUST be set to bfd.XmitAuthSeq. Then, a first hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (BFD 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 resultant Second-Hash becomes the Authentication Data that is sent in the Authentication Data field of the BFD Authentication Section. 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 BFD Packet as transmitted on the wire. 3.4 Procedures at the Sending Side An appropriate BFD SA is selected for use with an outgoing BFD packet. This is done based on the active key at that instant. If BFD is unable to find an active key, the BFD packet is discarded. If BFD is able to find the active key, then the key gives the authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 or HMAC-SHA-512) that needs to be applied on the packet. An implementation MUST fill the Auth Type and the Auth length before the authentication data is computed. The Sequence Number field MUST be set to bfd.XmitAuthSeq. The Auth length in the Authentication section is set as per the authentication algorithm that is being used. It is set to 28 for HMAC-SHA-1, 36 for HMAC-SHA-224, 40 for HMAC-SHA-256, 56 for HMAC- SHA-384 and 72 for HMAC-SHA-512. The key ID is filled. Bhatia and Manral Expires April 2009 [Page 7] Internet Draft BFD Generic Cryptographic Authentication November 2009 The authentication data is computed as explained in the previous section. The result of the authentication algorithm is placed in the Authentication data, following the key ID. 3.5 Procedure at the Receiving Side The appropriate BFD SA is identified by looking at the Key ID from the Authentication Section from the incoming BFD packet. If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded. If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Cryptographic Authentication, if the Sequence Number lies outside of the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32 bit circular number space), the received packet MUST be discarded. For Meticulous Cryptographic Authentication, if the Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32 bit circular number space, the received packet MUST be discarded. Authentication Algorithm dependent processing, needs to be performed, using the algorithm specified by the appropriate BFD SA for the received packet. Before an implementation performs any processing it needs to save the values of the Authentication Value field. It should then set the Authentication Value field with Apad before the authentication data is computed. The calculated data is compared with the received authentication data in the packet and the packet 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 CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but does not verify this information. This is provided as a transition aid for networks in the process of migrating to the new CRYPTO_AUTH and MET_CRYPTO_AUTH based authentication schemes. 4. Security Considerations The document proposes extensions to BFD which would make it more secure than what it is today. It does not provide confidentiality as BFD contains information that does not need to be kept secret. It Bhatia and Manral Expires April 2009 [Page 8] Internet Draft BFD Generic Cryptographic Authentication November 2009 does however, provide means to authenticate the sender of the packets which is of interest to us. The technology in this document provides an authentication mechanism for BFD. 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 BFD protocol, while not causing undue implementation, deployment, or operational complexity. There is a transition mode suggested where routers can ignore the CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the packets. The operator must ensure that this mode is only used when migrating to the new CRYPTO_AUTH/MET_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. 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. 5. Acknowledgements TBD 6. IANA Considerations This document currently defines a value of 6 to be used to denote Cryptographic Authentication mechanism for authenticating BFD control packets and 7 for Meticulous Cryptographic Authentication. 7. References 7.1 Normative References [BFD-BASE] "Bidirectional Forwarding Detection", Katz, D. and Ward, D., Work in Progress, March 2008 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992 [RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 Bhatia and Manral Expires April 2009 [Page 9] Internet Draft BFD Generic Cryptographic Authentication November 2009 [FIPS-180-3] National Institute of Standards and 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. 7.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 [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. [SHA-1-attack1] Wang, X. et. al., "Finding Collisions in the Full SHA-1", Advances in Cryptology CRYPTO 05, pp. 17-36 [SHA-1-attack2] Wang, X. et. al., "New Collision Search for SHA-1", Technical Report, August 2005 (Presented in the Rump Session of CRYPTO 05) [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 8. 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 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions Bhatia and Manral Expires April 2009 [Page 10] Internet Draft BFD Generic Cryptographic Authentication November 2009 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 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 and Manral Expires April 2009 [Page 11]