--- 1/draft-ietf-bfd-generic-crypto-auth-02.txt 2012-10-19 08:14:18.873426859 +0200 +++ 2/draft-ietf-bfd-generic-crypto-auth-03.txt 2012-10-19 08:14:18.901427029 +0200 @@ -1,21 +1,21 @@ Network Working Group M. Bhatia Internet-Draft Alcatel-Lucent Intended status: Standards Track V. Manral -Expires: December 9, 2012 Hewlett-Packard Co. +Expires: April 22, 2013 Hewlett-Packard Co. D. Zhang Huawei - June 7, 2012 + October 19, 2012 BFD Generic Cryptographic Authentication - draft-ietf-bfd-generic-crypto-auth-02 + draft-ietf-bfd-generic-crypto-auth-03 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. @@ -33,21 +33,21 @@ 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 December 9, 2012. + This Internet-Draft will expire on April 22, 2013. Copyright Notice 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 @@ -63,25 +63,25 @@ 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.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 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 @@ -107,36 +107,36 @@ 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 + 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 inter-session replay attacks. In order to address the issues mentioned above, this document 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 a construct. + 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 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 @@ -144,21 +144,21 @@ 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: + The parameters associated with a BFD SA are listed as follows: o Authentication Algorithm : This indicates the authentication algorithm to be used with the BFD SA. This information SHOULD never be sent in plaintext over the wire. 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 @@ -219,94 +219,93 @@ As a result of this, in the Cryptographic Authentication scheme, a replay attack is possible till the next sequence number is sent out. 3.2. Authentication Section Format A new authentication type, 6 or 7, indicating the generic cryptographic authentication mechanism in use, is inserted in the first octet of Authentication Section of the BFD control packet. For a BFD packet, if the Authentication Present (A) bit is set in the - header, and the Authentication Type field if 6 (Generic Cryptographic + header and the Authentication Type field is 6 (Generic Cryptographic Authentication) or 7 (Generic 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 (High Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Low Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Auth Type: The Authentication Type, which in this case is 6 (Cryptographic Authentication) or 7 (Meticulous Cryptographic Authentication). - o Auth Len: Length of the Authentication Section. + o Auth Len: The length of the Authentication Section. o Auth Key ID: The Key ID of the authentication key used for this packet, enabling multiple keys to be active simultaneously. o Sequence Number: A 64-bit sequence number that is used to prevent replay attacks. For Cryptographic Authentication this value is incremented occasionally. For Meticulous Cryptographic Authentication, this value is incremented for each successive packet transmitted for a session. o Authentication Data: This field carries the digest computed by whatever Cryptographic Authentication algorithm is being used to authenticate the BFD control packet. 3.3. Procedures at the Sending Side Before a BFD device sends a BFD packet out, the device needs to - select an appropriate BFD SA from its local key table if a keyed + select an appropriate BFD SA from its local key database if a keyed digest for the packet is required. If no appropriate SA is available, the BFD packet MUST be discarded. If an appropriate SA is available, the device then derives the key and the associated authentication algorithm from the SA. The device sets the Authentication Present (A) bit in the packet header. - The device MUST fill the Auth Type and the Auth length before the + The device MUST fill the Auth Type and the Auth Len fields 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 + The Auth Len field in the Authentication section is set as per the authentication algorithm that is being used. - The Key ID is filled. + The Key ID field is filled. The computation of the digest is performed. The computing process can be various when different algorithms are adopted and is out of the scope of this document. - The generated digest is placed in the Authentication data, following - the Key ID. + The generated digest is placed in the Authentication Data field. 3.4. Procedure at the Receiving Side When a BFD Control packet is received, the following procedure MUST be followed, in the order specified. If the Authentication Present (A) bit is set in the packet header and the receiver will try to find a appropriate BFD SA in its local key table to process the packet. The BFD SA is identified by the Key ID - in the Authentication Section of the incoming BFD packet. + field in the Authentication Section of the incoming BFD packet. If the Auth Key ID field does not match the ID of any configured authentication key or the associated key is not in its valid period, 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 @@ -309,65 +308,90 @@ 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. The device then prepares for generating a digest of the packet. + First of all, the authentication data in the Authentication Value field needs to be saved somewhere else. Then the Authentication - Value field is set with a certain value (which may be various in - different security algorithms) according the authentication algorithm - indicated in the SA. After this, the device starts performing the - digest generating operations. The work of defining actual digest - generating operations is out of the scope of this document. + Value field is set with a pre-specified value (which may be various + in different security algorithms) according the authentication + algorithm indicated in the SA. After this, the device starts + performing the digest generating operations. The work of defining + actual digest generating operations is out of the scope of this + document. The calculated data is compared with the received authentication data in the packet and the packet MUST be 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. 3.5. Key Selection for BFD Packet Transmission - This section describes how the proposed security solution selects - long-lived keys from key tables [I-D.ietf-karp-crypto-key-table]. - Generally, a key used for BFD packet authentication should satisfy - the following requirements: + In [I-D.ietf-karp-crypto-key-table], a conceptual key database called + "key table" is introduce. A key table is located in the middle of + key management protocols and security protocols so that a security + protocol can derive long-term keys from the key table but does not + have to know the details of key management. This section describes + how the proposed security solution selects long-lived keys from key + tables [I-D.ietf-karp-crypto-key-table]. - o The key time period as defined by Not Before Time and Not After - Time must include the current time. + Assume that a device R1 tries to send a unicast BFD packet from its + interface I1 to the interface R2 of a remote device R2 at time T. + Because the key should be shared by the by both R1 and R2 to protect + the communication between I1 and I2, R1 needs to provide a protocol + ("BFD"), an interface identifier (I1) and a peer identifier (R2) into + the key selection function. Any key that satisfies the following + conditions may be selected: - o The key can be used for the desired security algorithm. + o The Peer field includes the device ID of R2. - In the remainder of this section, additional requirements for keys - are enumerated. Assume that a device R1 tries to send a unicast BFD - packet from its interface I1 to the interface R2 of a remote device - R2 at time T. Because the key should be shared by the by both R1 and - R2 to protect the communication between I1 and I2, the key should - satisfy the following requirements: + o the Protocol field matches "BFD" - o The Peer field includes the device ID of R2. + o The PeerKeyName field is not "unknown". - o The PeerKeyID field is not "unknown". + o The Interface field includes I1 or "all". - o The Interfaces field includes I1. + o The Direction field is either "out" or "both". + + o SendNotBefore <= current time <= SendNotAfter. + + After a set of keys are provided, a BFD implementation should support + selection of keys based on algorithm preference. + + Upon R2 receives the BFD packet from R1, R2 provides the protocol + ("BFD"), the peer identifier (R1), the key identifier derived from + the incoming packet (L), and the interface (I2) to the key table. + Any key that satisfies the following conditions may be selected: + + o The Peer field includes the device ID of R1. + + o the Protocol field matches "BFD" + + o the LocalKeyName is L + + o The Interface field includes I2 or "all". o The Direction field is either "out" or "both". + o SendNotBefore <= current time <= SendNotAfter. + 3.6. Replay Protection using Extended Sequence Numbers As described in Section 1, if the BFD packets in a session are transferred with a high frequency, a 32-bit sequence number may reach its maximum and have to roll back before the session finishes. A attacker thus can replay the packets intercepted before the sequence number wrapped without being detected. To address this problem, the length of the sequence number in the proposed authentication section has been extended to 64 bits. After the extension, the sequence number space of a device will not be exhausted within half of a @@ -416,31 +440,31 @@ 5. Security Considerations The proposed sequence number extension offers most of the benefits of of more complicated mechanisms involving challenges. There are, however, a couple drawbacks to this approach. First, it requires the BFD implementation to be able to save its boot count in non-volatile storage. If the non-volatile storage is ever repaired or upgraded such that the contents are lost or the BFD device is replaced with a model, the keys MUST be changed to prevent replay attacks. Second, if a device is taken out of service completely (either intentionally - or due to a persistent failure), the potential exists for - reestablishment of a BFD adjacency by replaying the entire BFD - session establishment. This scenario is however, extremely unlikely - and can be easily avoided. For instance, after recovering from a - system failure, a BFD device has to re-establish BFD sessions. At - this stage, if the device randomly selects its discriminators to - identify new BFD sessions, the possibility of reestablishing a BFD - session by replaying the entire BFD session establishment will be - eliminated. For the implementations in which discriminators are not - randomly selected, this issue can be addressed by integrating the - boot count of the remote BFD router in the generation of the + or due to a persistent failure), the potential exists for re- + establishment of a BFD adjacency by replaying the entire BFD session + establishment. This scenario is however, extremely unlikely and can + be easily avoided. For instance, after recovering from a system + failure, a BFD device has to re-establish BFD sessions. At this + stage, if the device randomly selects its discriminators to identify + new BFD sessions, the possibility of reestablishing a BFD session by + replaying the entire BFD session establishment will be eliminated. + For the implementations in which discriminators are not randomly + selected, this issue can be largely mitigated by integrating the boot + count of the remote BFD router in the generation of the authentication data for outgoing BFD packets. Of course, this attack could also be thwarted by changing the relevant manual keys. There is a transition mode suggested where devices 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 device vulnerable to an attack. 6. Acknowledgements @@ -453,23 +477,24 @@ Requirement Levels", BCP 14, RFC 2119, March 1997. 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-02 - (work in progress), October 2011. + 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. [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",