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/ |