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 2010 IP Infusion BFD Generic Cryptographic Authentication draft-bhatia-bfd-crypto-auth-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Bhatia and Manral Expires April 2009 [Page 1] Internet Draft BFD Generic Cryptographic Authentication November 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms (SHS) 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. 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. [RFC2119] Contents 1. Introduction...................................................2 2. BFD Security Association.......................................4 3. Authentication Procedures......................................5 3.1 Cryptographic Authentication and Meticulous Cryptographic Authentication.................................................5 3.2 Packet Encoding............................................5 3.3 Cryptographic Aspects......................................6 3.4 Procedures at the Sending Side.............................8 3.5 Procedure at the Receiving Side............................8 4. Security Considerations........................................9 5. Acknowledgements..............................................10 6. IANA Considerations...........................................10 7. References....................................................10 7.1 Normative References......................................10 7.2 Informative References....................................11 8. Author's Addresses............................................11 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, Bhatia and Manral Expires April 2009 [Page 2] Internet Draft BFD Generic Cryptographic Authentication November 2009 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]. 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. It should be noted that if SHA-1 is used in the Hashed Message Authentication Code (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. Bhatia and Manral Expires April 2009 [Page 3] Internet Draft BFD Generic Cryptographic Authentication November 2009 By definition, HMAC requires a cryptographic hash function. We propose to use any one of Secure Hash Algorithms (SHA) defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3]. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The HMAC authentication mode defined in NIST FIPS 198 is used [FIPS-198]. It is believed that [RFC2104] is mathematically identical to [FIPS-198] and it is also believed that algorithms in [RFC4634] are mathematically identical to [FIPS-180-3]. Of the above, implementations of this specification MUST include support for at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or HMAC-SHA-512. An implementation of this specification MUST allow network operators to configure ANY authentication algorithm supported by that implementation for use with ANY given KeyID value that is configured into that BFD router. 2. BFD Security Association The BFD protocol does not include an in-band mechanism to create or manage BFD Security Associations (BFD SA). A BFD SA contains a set of shared parameters between any two legitimate BFD routers. Parameters associated with a BFD SA: O Authentication Key Identifier (Key ID) : This is a two octet unsigned integer used to uniquely identify the BFD SA, as manually configured by the network operator (or, in the future, possibly by some key management protocol specified by the IETF). The receiver determines the active SA by looking at this field in the incoming packet. The sender puts this Key ID in the BFD packet 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. Bhatia and Manral Expires April 2009 [Page 4] Internet Draft BFD Generic Cryptographic Authentication November 2009 o Authentication Algorithm : This indicates the authentication algorithm to be used with the BFD SA. This information SHOULD never be sent in cleartext over the wire. At present, the following values are possible: Keyed MD5, Keyed SHA-1, HMAC-SHA-1, HMAC-SHA-256, HMAC- SHA-384 and HMAC-SHA-512. o Authentication Key : This indicates the cryptographic key associated with this 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. This is noted as "K" in section 3.3 below. 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. 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: Bhatia and Manral Expires April 2009 [Page 5] Internet Draft BFD Generic Cryptographic Authentication November 2009 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 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. Bhatia and Manral Expires April 2009 [Page 6] Internet Draft BFD Generic Cryptographic Authentication November 2009 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 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 Bhatia and Manral Expires April 2009 [Page 7] Internet Draft BFD Generic Cryptographic Authentication November 2009 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-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, 40 for HMAC-SHA-256, 56 for HMAC-SHA-384 and 72 for HMAC- SHA-512. The Key ID is filled. 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 Bhatia and Manral Expires April 2009 [Page 8] Internet Draft BFD Generic Cryptographic Authentication November 2009 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 This document enhances the security of the BFD protocol by adding, to the existing BFD cryptographic authentication methods, support for the algorithms defined in the NIST Secure Hash Standard (SHS) using the Hashed Message Authentication Code (HMAC) mode, and by adding support for the Hashed Message Authentication Code (HMAC) mode. It does not provide confidentiality as BFD contains information that does not need to be kept secret. Because all of the currently specified algorithms use symmetric cryptography, one cannot authenticate precisely which BFD router sent a given packet. However, one can authenticate that the sender knew the BFD Security Association (including the BFD SA's parameters) currently in use. 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 Bhatia and Manral Expires April 2009 [Page 9] Internet Draft BFD Generic Cryptographic Authentication November 2009 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. The quality of the security provided by the Cryptographic Authentication option depends completely on the strength of the cryptographic algorithm and cryptographic mode in use, the strength of the key being used, and the correct implementation of the security mechanism in all communicating BFD implementations. Accordingly, the use of high assurance development methods is recommended. It also requires that all parties maintain the secrecy of the shared secret key. [RFC4086] provides guidance on methods for generating cryptographically random bits. The value Apad is used here primarily for consistency with IETF specifications for HMAC-SHA authentication of RIPv2 SHA [RFC4822], IS-IS SHA [RFC5310] and OSPF SHA [RFC5709]. 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] Katz, D. and Ward, D., "Bidirectional Forwarding Detection", Work in Progress, February 2009 [RFC2119] 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 [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 Bhatia and Manral Expires April 2009 [Page 10] Internet Draft BFD Generic Cryptographic Authentication November 2009 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) [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007. [RFC5310] Bhatia, M., et. al., "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. [RFC5709] Bhatia, M., et. al., "IS-IS Generic Cryptographic Authentication", RFC 5709, October 2009. 8. Author's Addresses Manav Bhatia Alcatel-Lucent, Bangalore, India Email: manav.bhatia@alcatel-lucent.com Vishwas Manral IP Infusion Almora, Uttarakhand, India Email: vishwas@ipinfusion.com Bhatia and Manral Expires April 2009 [Page 11] Internet Draft BFD Generic Cryptographic Authentication November 2009 Bhatia and Manral Expires April 2009 [Page 12]