--- 1/draft-ietf-bfd-generic-crypto-auth-01.txt 2012-06-07 15:14:11.009425850 +0200 +++ 2/draft-ietf-bfd-generic-crypto-auth-02.txt 2012-06-07 15:14:11.037425076 +0200 @@ -1,30 +1,30 @@ Network Working Group M. Bhatia Internet-Draft Alcatel-Lucent Intended status: Standards Track V. Manral -Expires: October 8, 2012 Hewlett-Packard Co. +Expires: December 9, 2012 Hewlett-Packard Co. D. Zhang Huawei - April 5, 2012 + June 7, 2012 BFD Generic Cryptographic Authentication - draft-ietf-bfd-generic-crypto-auth-01 + draft-ietf-bfd-generic-crypto-auth-02 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 thats required for supporting algorithm and key - agility for BFD. + 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 This Internet-Draft is submitted in full conformance with the @@ -33,25 +33,25 @@ 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 October 8, 2012. + This Internet-Draft will expire on December 9, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 @@ -66,58 +66,58 @@ 3.2. Authentication Section Format . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 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 + 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 an MD5 digest for each packet. + 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 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 that - those are subject 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-session replay attacks. In meticulous - authentication schemes, sequence numbers are required to - monotonically increase with each successive packet, which eliminates - the possibility of intra-session replay attacks. + 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- + session replay attacks. In meticulous authentication schemes, + sequence numbers are required to monotonically increase with each + successive packet, which eliminates the possibility of intra-session + replay attacks. BFD session timers are often defined with the granularity of microseconds. Although in practice BFD devices send packets at millisecond intervals, they can potentially, send packets at a much higher rate. Since the cryptographic sequence number space is only 32 bits, when using Meticulous Authentication, a sequence number used in a BFD session can reach its maximum value and roll over within a short period. For instance, if the value of a sequence number is increased by one every millisecond, then it will reach its maximum in less than 8 weeks. This can potentially be exploited to launch @@ -132,25 +132,25 @@ not tied to any particular authentication algorithm or a 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 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 [add a reference here]. We - therefore only consider pre-shared keys being used. 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. + 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. Parameters associated with a BFD SA: o Authentication Algorithm : This indicates the authentication @@ -161,26 +161,26 @@ 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. 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 + unsigned integer used to uniquely identify the BFD SA. This ID could + be 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. 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. A key ID indicates a tuple of an authentication key and an associated authentication algorithm. If a key is expected to be applied with different algorithms, different Key IDs must be used to identify the associations of the key with its authentication algorithms @@ -445,31 +445,37 @@ 6. Acknowledgements 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. -7.2. References +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. and T. Polk, "Database of Long-Lived Symmetric - Cryptographic Keys", draft-ietf-karp-crypto-key-table-01 - (work in progress), May 2011. + Cryptographic Keys", draft-ietf-karp-crypto-key-table-02 + (work in progress), October 2011. + + [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. [MD5-attack] Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 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