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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/