draft-ietf-bfd-generic-crypto-auth-01.txt   draft-ietf-bfd-generic-crypto-auth-02.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: October 8, 2012 Hewlett-Packard Co. Expires: December 9, 2012 Hewlett-Packard Co.
D. Zhang D. Zhang
Huawei Huawei
April 5, 2012 June 7, 2012
BFD Generic Cryptographic Authentication BFD Generic Cryptographic Authentication
draft-ietf-bfd-generic-crypto-auth-01 draft-ietf-bfd-generic-crypto-auth-02
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 any cryptographic authentication
algorithm in addition to the already-documented authentication algorithm in addition to the already-documented authentication
schemes described in the base specification. This document adds the schemes described in the base specification. This document adds the
basic infrastructure thats required for supporting algorithm and key basic infrastructure that is required for supporting algorithm and
agility for BFD. 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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 October 8, 2012. This Internet-Draft will expire on December 9, 2012.
Copyright Notice 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. 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.2. Authentication Section Format . . . . . . . . . . . . . . 6 3.2. Authentication Section Format . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 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 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 [MD5-
attack] and [Dobb96a, Dobb96b], several methods of generating hash attack] and [Dobb96a, Dobb96b], several methods of generating hash
collisions for some applications of MD5 are proposed. Similar 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 that The other issue with the existing authentication schemes is the
those are subject to replay attacks. In non-meticulous vulnerability to replay attacks. In non-meticulous authentication
authentication schemes, sequence numbers are only increased schemes, sequence numbers are only increased occasionally. This
occasionally. This behavior can be taken advantage of by an attacker behavior can be taken advantage of by an attacker to perform intra-
to perform intra-session replay attacks. In meticulous session replay attacks. In meticulous authentication schemes,
authentication schemes, sequence numbers are required to sequence numbers are required to monotonically increase with each
monotonically increase with each successive packet, which eliminates successive packet, which eliminates the possibility of intra-session
the possibility of intra-session replay attacks. replay attacks.
BFD session timers are often defined with the granularity of BFD session timers are often defined with the granularity of
microseconds. Although in practice BFD devices send packets at 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 higher rate. Since the cryptographic sequence number space is only
32 bits, when using Meticulous Authentication, a sequence number used 32 bits, when using Meticulous Authentication, a sequence number used
in a BFD session can reach its maximum value and roll over within a 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 short period. For instance, if the value of a sequence number is
increased by one every millisecond, then it will reach its maximum in increased by one every millisecond, then it will reach its maximum in
less than 8 weeks. This can potentially be exploited to launch less than 8 weeks. This can potentially be exploited to launch
skipping to change at page 4, line 19 skipping to change at page 4, line 19
not tied to any particular authentication algorithm or a construct. not tied to any particular authentication algorithm or a 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 modified 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 manual key
management procedure that currently exists within BFD, as part of the management procedure that currently exists within BFD, as part of the
Phase One described in KARP-design-guide [add a reference here]. We Phase One described in KARP-design-guide
therefore only consider pre-shared keys being used. However, the [I-D.ietf-karp-design-guide]. Therefore, only the pre-shared keys is
solution described in this document is generic and does not preclude considered in this document. However, the solution described in this
the possibility of supporting keys derived from an automated key document is generic and does not preclude the possibility of
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.
Parameters associated with a BFD SA: Parameters associated with a BFD SA:
o Authentication Algorithm : This indicates the authentication o Authentication Algorithm : This indicates the authentication
skipping to change at page 4, line 48 skipping to change at page 4, line 48
associated with this BFD SA. The length of this key is variable and associated with this BFD SA. The length of this key is variable and
depends upon the authentication algorithm specified by the BFD SA. depends upon the authentication algorithm specified by the BFD SA.
Operators MUST ensure that this is never sent over the network in Operators MUST ensure that this is never sent over the network in
clear-text via any protocol. Care should also be taken to ensure clear-text via any protocol. Care should also be taken to ensure
that the selected key is unpredictable, avoiding any keys known to be that the selected key is unpredictable, avoiding any keys known to be
weak for the algorithm in use. [RFC4086] contains helpful weak for the algorithm in use. [RFC4086] contains helpful
information on both key generation techniques and cryptographic information on both key generation techniques and cryptographic
randomness. randomness.
o Authentication Key Identifier (Key ID) : This is a two octet o Authentication Key Identifier (Key ID) : This is a two octet
unsigned integer used to uniquely identify the BFD SA, as manually unsigned integer used to uniquely identify the BFD SA. This ID could
configured by the network operator (or, in the future, possibly by be manually configured by the network operator (or, in the future,
some key management protocol specified by the IETF). The receiver possibly by some key management protocol specified by the IETF). The
determines the active SA by looking at this field in the incoming receiver determines the active SA by looking at this field in the
packet. The sender puts this Key ID in the BFD packet based on the incoming packet. The sender puts this Key ID in the BFD packet based
active configuration. Using Key IDs makes changing keys while on the active configuration. Using Key IDs makes changing keys while
maintaining protocol operation convenient. Normally, an maintaining protocol operation convenient. Normally, an
implementation would allow the network operator to configure a set of implementation would allow the network operator to configure a set of
keys in a key chain, with each key in the chain having fixed keys in a key chain, with each key in the chain having fixed
lifetime. The actual operation of these mechanisms is outside the lifetime. The actual operation of these mechanisms is outside the
scope of this document. scope of this document.
A key ID indicates a tuple of an authentication key and an associated A key ID indicates a tuple of an authentication key and an associated
authentication algorithm. If a key is expected to be applied with authentication algorithm. If a key is expected to be applied with
different algorithms, different Key IDs must be used to identify the different algorithms, different Key IDs must be used to identify the
associations of the key with its authentication algorithms associations of the key with its authentication algorithms
skipping to change at page 11, line 5 skipping to change at page 11, line 5
6. Acknowledgements 6. Acknowledgements
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. 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. and T. Polk, "Database of Long-Lived Symmetric Housley, R. and T. Polk, "Database of Long-Lived Symmetric
Cryptographic Keys", draft-ietf-karp-crypto-key-table-01 Cryptographic Keys", draft-ietf-karp-crypto-key-table-02
(work in progress), May 2011. (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] [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 2004. August 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
 End of changes. 14 change blocks. 
32 lines changed or deleted 38 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/