--- 1/draft-ietf-bfd-generic-crypto-auth-03.txt 2013-05-02 09:19:59.983597995 +0100 +++ 2/draft-ietf-bfd-generic-crypto-auth-04.txt 2013-05-02 09:20:00.627613978 +0100 @@ -1,109 +1,110 @@ Network Working Group M. Bhatia Internet-Draft Alcatel-Lucent Intended status: Standards Track V. Manral -Expires: April 22, 2013 Hewlett-Packard Co. +Expires: October 20, 2013 Hewlett-Packard Co. D. Zhang Huawei - October 19, 2012 + April 18, 2013 BFD Generic Cryptographic Authentication - draft-ietf-bfd-generic-crypto-auth-03 + draft-ietf-bfd-generic-crypto-auth-04 Abstract This document proposes an extension to 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. This document adds the - basic infrastructure that is required for supporting algorithm and - key agility for BFD. + Detection (BFD) to allow the use of arbitary cryptographic + authentication algorithms in addition to the already-documented + authentication schemes described in the base specification. This + document adds the basic infrastructure that is required for + supporting algorithm and key agility for BFD. Requirements Language 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]. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 22, 2013. + This Internet-Draft will expire on October 20, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. BFD Security Association . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. BFD Security Association . . . . . . . . . . . . . . . . . . 4 3. Authentication Procedures . . . . . . . . . . . . . . . . . . 5 - 3.1. Authentication Types . . . . . . . . . . . . . . . . . . . 5 - 3.2. Authentication Section Format . . . . . . . . . . . . . . 6 - 3.3. Procedures at the Sending Side . . . . . . . . . . . . . . 6 + 3.1. Authentication Types . . . . . . . . . . . . . . . . . . 5 + 3.2. Authentication Section Format . . . . . . . . . . . . . . 5 + 3.3. Procedures at the Sending Side . . . . . . . . . . . . . 6 3.4. Procedure at the Receiving Side . . . . . . . . . . . . . 7 3.5. Key Selection for BFD Packet Transmission . . . . . . . . 8 3.6. Replay Protection using Extended Sequence Numbers . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The base specification of bidirectional Forwarding Detection (BFD) [RFC5880] defines five authentication schemes: Simple Password, Keyed MD5 , Meticulous Keyed MD5, Keyed SHA-1, and Meticulous SHA-1. In Simple Password, passwords are transferred in plaintext. An attacker with physical access to the network can easily eavesdrop on the password and compromise the security of the BFD packet exchanges. In Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both sides of a BFD session 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. Keyed SHA-1 and Meticulous SHA-1 modes are similar to MD5, and it uses SHA-1 instead of MD5 to generate a digest for each packet. A concern with existing authentication schemes of BFD is that the security strength of the cryptographic algorithms adopted in the schemes is relatively weak. Both the MD5 algorithm and the SHA-1 - algorithm are known to be vulnerable to collision attacks. In [MD5- - attack] and [Dobb96a, Dobb96b], several methods of generating hash - collisions for some applications of MD5 are proposed. Similar + algorithm are known to be vulnerable to collision attacks. In + + [MD5-attack] and [Dobb96a, Dobb96b], several methods of generating + hash collisions for some applications of MD5 are proposed. Similar security vulnerabilities of SHA-1 are introduced in [SHA-1-attack1] and [SHA-1-attack2]. It is therefore desired that BFD must support newer algorithms that have not yet been broken. Additionally, the transition mechanism from one algorithm to the other must be seamless. The other issue with the existing authentication schemes is the vulnerability to replay attacks. In non-meticulous authentication schemes, sequence numbers are only increased occasionally. This behavior can be taken advantage of by an attacker to perform intra- @@ -127,29 +128,29 @@ proposes two new authentication types that can be used to secure the BFD packets. The two authentication types are - Cryptographic Authentication (CRYPTO_AUTH) and Meticulous Cryptographic Authentication (MET_ CRYPTO_AUTH). Unlike earlier authentication types that were defined in BFD, the proposed authentication types are not tied to any particular authentication algorithm or construct. These can use different authentication algorithms and constructs like MD5, SHA-1, SHA-2, HMAC-SHA1, HMAC-SHA2, etc. to provide authentication and data integrity protection for BFD control packets. - The packet replay mechanism has also been modified to improve its + The packet replay mechanism has also been enhanced to improve its capability in handling inter and intra-session replay attacks. - It should be noted that this document attempts to fix the manual key - management procedure that currently exists within BFD, as part of the - Phase One described in KARP-design-guide - [I-D.ietf-karp-design-guide]. Therefore, only the pre-shared keys is - considered in this document. However, the solution described in this - document is generic and does not preclude the possibility of + It should be noted that this document attempts to fix the security + issues raised by the manual key management procedure that currently + exists within BFD, as part of the Phase One described in KARP-design- + guide [I-D.ietf-karp-design-guide]. Therefore, only the pre-shared + keys is considered in this document. However, the solution described + in this document is generic and does not preclude the possibility of supporting keys derived from an automated key management protocol. 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 devices. The parameters associated with a BFD SA are listed as follows: @@ -406,22 +406,22 @@ An anti-replay solution for BFD also needs to consider the scenarios where a BFD device loses its prior sequence number state (e.g., system crash, loss of power). In such cases, a BFD device has to re- initialize its sequence number. Taking this opportunity, an attacker may be able to replay the antique packets intercepted in previous sessions without being detected. To address this problem, in the proposed solution, the most significant 32-bit value of the sequence number is used to contain a - boot count, and the remainder 32-bit value is used as an ordinary 32- - bit monotonically increasing sequence number. In Generic + boot count, and the remainder 32-bit value is used as an ordinary + 32-bit monotonically increasing sequence number. In Generic Cryptographic Authentication, the remainder 32-bit value is required to increase occasionally, while in Generic Meticulous Cryptographic Authentication, the lower order 32-bit sequence number MUST be incremented for every BFD packet sent by a BFD device. The BFD implementations are required to retain the boot count in non-volatile storage for the deployment life the BFD device. The boot count increases each time when the BFD device loses its prior sequence number state. The SNMPv3 snmpEngineBoots variable [RFC4222] MAY be used for this purpose. However, maintaining a separate boot count solely for BFD sequence numbers has the advantage of decoupling SNMP @@ -479,43 +479,42 @@ 7.2. Informative References [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes", 1996. [I-D.ietf-karp-crypto-key-table] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", - draft-ietf-karp-crypto-key-table-03 (work in progress), - June 2012. + draft-ietf-karp-crypto-key-table-07 (work in progress), + March 2013. [I-D.ietf-karp-design-guide] Lebovitz, G. and M. Bhatia, "Keying and Authentication for - Routing Protocols (KARP) Design Guidelines", - draft-ietf-karp-design-guide-10 (work in progress), - December 2011. + Routing Protocols (KARP) Design Guidelines", draft-ietf- + karp-design-guide-10 (work in progress), December 2011. [MD5-attack] Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for - Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", - August 2004. + Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August + 2004. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF - Version 2 Packets and Congestion Avoidance", BCP 112, - RFC 4222, October 2005. + Version 2 Packets and Congestion Avoidance", BCP 112, RFC + 4222, October 2005. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [SHA-1-attack1] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the Full SHA-1", 2005. [SHA-1-attack2] Wang, X., Yao, A., and F. Yao, "New Collision Search for @@ -533,14 +532,14 @@ Vishwas Manral Hewlett-Packard Co. 19111 Pruneridge Ave. Cupertino, CA 95014 USA Email: vishwas.manral@hp.com Dacheng Zhang Huawei - Beijing, + Beijing China Email: zhangdacheng@huawei.com