idnits 2.17.1 draft-ietf-bfd-generic-crypto-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 5, 2012) is 4402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5880' is mentioned on line 482, but not defined == Missing Reference: 'Dobb96a' is mentioned on line 457, but not defined == Missing Reference: 'Dobb96b' is mentioned on line 459, but not defined == Missing Reference: 'SHA-1-attack1' is mentioned on line 485, but not defined == Missing Reference: 'SHA-1-attack2' is mentioned on line 489, but not defined == Missing Reference: 'RFC4086' is mentioned on line 475, but not defined == Missing Reference: 'I-D.ietf-karp-crypto-key-table' is mentioned on line 462, but not defined == Missing Reference: 'RFC4222' is mentioned on line 478, but not defined == Missing Reference: 'MD5-attack' is mentioned on line 467, but not defined == Missing Reference: 'RFC1321' is mentioned on line 472, but not defined Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track V. Manral 5 Expires: October 8, 2012 Hewlett-Packard Co. 6 D. Zhang 7 Huawei 8 April 5, 2012 10 BFD Generic Cryptographic Authentication 11 draft-ietf-bfd-generic-crypto-auth-01 13 Abstract 15 This document proposes an extension to Bidirectional Forwarding 16 Detection (BFD) to allow the use of any cryptographic authentication 17 algorithm in addition to the already-documented authentication 18 schemes described in the base specification. This document adds the 19 basic infrastructure thats required for supporting algorithm and key 20 agility for BFD. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 8, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. BFD Security Association . . . . . . . . . . . . . . . . . . . 4 64 3. Authentication Procedures . . . . . . . . . . . . . . . . . . 5 65 3.1. Authentication Types . . . . . . . . . . . . . . . . . . . 5 66 3.2. Authentication Section Format . . . . . . . . . . . . . . 6 67 3.3. Procedures at the Sending Side . . . . . . . . . . . . . . 6 68 3.4. Procedure at the Receiving Side . . . . . . . . . . . . . 7 69 3.5. Key Selection for BFD Packet Transmission . . . . . . . . 8 70 3.6. Replay Protection using Extended Sequence Numbers . . . . 9 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The base specification of bidirectional Forwarding Detection (BFD) 82 [RFC5880] defines five authentication schemes: Simple Password, Keyed 83 MD5 , Meticulous Keyed MD5, Keyed SHA-1 and Meticulous SHA-1. In 84 Simple Password, passwords are transferred in plaintext. An attacker 85 with physical access to the network can easily eavesdrop on the 86 password and compromise the security of the BFD packet exchanges. In 87 Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both sides 88 of a BFD session share a secret key which is used to generate a keyed 89 MD5 digest for each packet, and a monotonically increasing sequence 90 number scheme is used to prevent replay attacks. Keyed SHA-1 and 91 Meticulous SHA-1 modes are similar to MD5, and it uses SHA-1 instead 92 of an MD5 digest for each packet. 94 A concern with existing authentication schemes of BFD is that the 95 security strength of the cryptographic algorithms adopted in the 96 schemes is relatively weak. Both the MD5 algorithm and the SHA-1 97 algorithm are known to be vulnerable to collision attacks. In [MD5- 98 attack] and [Dobb96a, Dobb96b], several methods of generating hash 99 collisions for some applications of MD5 are proposed. Similar 100 security vulnerabilities of SHA-1 are introduced in [SHA-1-attack1] 101 and [SHA-1-attack2]. It is therefore desired that BFD must support 102 newer algorithms that have not yet been broken. Additionally, the 103 transition mechanism from one algorithm to the other must be 104 seamless. 106 The other issue with the existing authentication schemes is that 107 those are subject to replay attacks. In non-meticulous 108 authentication schemes, sequence numbers are only increased 109 occasionally. This behavior can be taken advantage of by an attacker 110 to perform intra-session replay attacks. In meticulous 111 authentication schemes, sequence numbers are required to 112 monotonically increase with each successive packet, which eliminates 113 the possibility of intra-session replay attacks. 115 BFD session timers are often defined with the granularity of 116 microseconds. Although in practice BFD devices send packets at 117 millisecond intervals, they can potentially, send packets at a much 118 higher rate. Since the cryptographic sequence number space is only 119 32 bits, when using Meticulous Authentication, a sequence number used 120 in a BFD session can reach its maximum value and roll over within a 121 short period. For instance, if the value of a sequence number is 122 increased by one every millisecond, then it will reach its maximum in 123 less than 8 weeks. This can potentially be exploited to launch 124 inter-session replay attacks. 126 In order to address the issues mentioned above, this document 127 proposes two new authentication types that can be used to secure the 128 BFD packets. The two authentication types are - Cryptographic 129 Authentication (CRYPTO_AUTH) and Meticulous Cryptographic 130 Authentication (MET_ CRYPTO_AUTH). Unlike earlier authentication 131 types that were defined in BFD, the proposed authentication types are 132 not tied to any particular authentication algorithm or a construct. 133 These can use different authentication algorithms and constructs like 134 MD5, SHA-1, SHA-2, HMAC-SHA1, HMAC-SHA2, etc. to provide 135 authentication and data integrity protection for BFD control packets. 137 The packet replay mechanism has also been modified to improve its 138 capability in handling inter and intra-session replay attacks. 140 It should be noted that this document attempts to fix the manual key 141 management procedure that currently exists within BFD, as part of the 142 Phase One described in KARP-design-guide [add a reference here]. We 143 therefore only consider pre-shared keys being used. However, the 144 solution described in this document is generic and does not preclude 145 the possibility of supporting keys derived from an automated key 146 management protocol. 148 2. BFD Security Association 150 The BFD protocol does not include an in-band mechanism to create or 151 manage BFD Security Associations (BFD SA). A BFD SA contains a set 152 of shared parameters between any two legitimate BFD devices. 154 Parameters associated with a BFD SA: 156 o Authentication Algorithm : This indicates the authentication 157 algorithm to be used with the BFD SA. This information SHOULD never 158 be sent in plaintext over the wire. 160 o Authentication Key : This indicates the cryptographic key 161 associated with this BFD SA. The length of this key is variable and 162 depends upon the authentication algorithm specified by the BFD SA. 163 Operators MUST ensure that this is never sent over the network in 164 clear-text via any protocol. Care should also be taken to ensure 165 that the selected key is unpredictable, avoiding any keys known to be 166 weak for the algorithm in use. [RFC4086] contains helpful 167 information on both key generation techniques and cryptographic 168 randomness. 170 o Authentication Key Identifier (Key ID) : This is a two octet 171 unsigned integer used to uniquely identify the BFD SA, as manually 172 configured by the network operator (or, in the future, possibly by 173 some key management protocol specified by the IETF). The receiver 174 determines the active SA by looking at this field in the incoming 175 packet. The sender puts this Key ID in the BFD packet based on the 176 active configuration. Using Key IDs makes changing keys while 177 maintaining protocol operation convenient. Normally, an 178 implementation would allow the network operator to configure a set of 179 keys in a key chain, with each key in the chain having fixed 180 lifetime. The actual operation of these mechanisms is outside the 181 scope of this document. 183 A key ID indicates a tuple of an authentication key and an associated 184 authentication algorithm. If a key is expected to be applied with 185 different algorithms, different Key IDs must be used to identify the 186 associations of the key with its authentication algorithms 187 respectively. However, the application of a key for different 188 purposes must be very careful, since it may make an adversary easier 189 to collect more material to compromise the key. 191 o Not Before Time : The time point before which the key should not be 192 used. 194 o Not After Time : The time point after which the key should not be 195 used. 197 3. Authentication Procedures 199 In the proposed authentication extension, an optional authentication 200 section (Generic Authentication Section) and two authentication types 201 (Generic Cryptographic Authentication and Generic Meticulous 202 Cryptographic Authentication) are specified. 204 3.1. Authentication Types 206 The Authentication section is only present in a BFD packet if the 207 Authentication Present (A) bit is set in the packet header. The Auth 208 Type in the Authentication section is set to 6 when Generic 209 Cryptographic Authentication is in use, while it is set to 7 when 210 Generic Meticulous Cryptographic Authentication is in use. 212 Both the authentication types use a monotonically increasing sequence 213 number to protect the BFD session against reply attacks. The only 214 difference between the two types is that the sequence number is 215 occasionally incremented in the Cryptographic Authentication mode, as 216 against the Meticulous Cryptographic Authentication mode, where it is 217 incremented on every packet. 219 As a result of this, in the Cryptographic Authentication scheme, a 220 replay attack is possible till the next sequence number is sent out. 222 3.2. Authentication Section Format 224 A new authentication type, 6 or 7, indicating the generic 225 cryptographic authentication mechanism in use, is inserted in the 226 first octet of Authentication Section of the BFD control packet. 228 For a BFD packet, if the Authentication Present (A) bit is set in the 229 header, and the Authentication Type field if 6 (Generic Cryptographic 230 Authentication) or 7 (Generic Meticulous Cryptographic 231 Authentication), the Authentication Section has the following format: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Auth Type | Auth Len | Auth Key ID | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Sequence Number (High Order 32 Bits) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Sequence Number (Low Order 32 Bits) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 | Authentication Data (Variable) | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 o Auth Type: The Authentication Type, which in this case is 6 247 (Cryptographic Authentication) or 7 (Meticulous Cryptographic 248 Authentication). 250 o Auth Len: Length of the Authentication Section. 252 o Auth Key ID: The Key ID of the authentication key used for this 253 packet, enabling multiple keys to be active simultaneously. 255 o Sequence Number: A 64-bit sequence number that is used to prevent 256 replay attacks. For Cryptographic Authentication this value is 257 incremented occasionally. For Meticulous Cryptographic 258 Authentication, this value is incremented for each successive 259 packet transmitted for a session. 261 o Authentication Data: This field carries the digest computed by 262 whatever Cryptographic Authentication algorithm is being used to 263 authenticate the BFD control packet. 265 3.3. Procedures at the Sending Side 267 Before a BFD device sends a BFD packet out, the device needs to 268 select an appropriate BFD SA from its local key table if a keyed 269 digest for the packet is required. If no appropriate SA is 270 available, the BFD packet MUST be discarded. 272 If an appropriate SA is available, the device then derives the key 273 and the associated authentication algorithm from the SA. 275 The device sets the Authentication Present (A) bit in the packet 276 header. 278 The device MUST fill the Auth Type and the Auth length before the 279 authentication data is computed. The Sequence Number field MUST be 280 set to bfd.XmitAuthSeq. 282 The Auth length in the Authentication section is set as per the 283 authentication algorithm that is being used. 285 The Key ID is filled. 287 The computation of the digest is performed. The computing process 288 can be various when different algorithms are adopted and is out of 289 the scope of this document. 291 The generated digest is placed in the Authentication data, following 292 the Key ID. 294 3.4. Procedure at the Receiving Side 296 When a BFD Control packet is received, the following procedure MUST 297 be followed, in the order specified. 299 If the Authentication Present (A) bit is set in the packet header and 300 the receiver will try to find a appropriate BFD SA in its local key 301 table to process the packet. The BFD SA is identified by the Key ID 302 in the Authentication Section of the incoming BFD packet. 304 If the Auth Key ID field does not match the ID of any configured 305 authentication key or the associated key is not in its valid period, 306 the received packet MUST be discarded. 308 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 309 Cryptographic Authentication, if the Sequence Number lies outside of 310 the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) 311 inclusive (when treated as an unsigned 32 bit circular number space), 312 the received packet MUST be discarded. For Meticulous Cryptographic 313 Authentication, if the Sequence Number lies outside of the range of 314 bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 315 treated as an unsigned 32 bit circular number space, the received 316 packet MUST be discarded. 318 The device then prepares for generating a digest of the packet. 319 First of all, the authentication data in the Authentication Value 320 field needs to be saved somewhere else. Then the Authentication 321 Value field is set with a certain value (which may be various in 322 different security algorithms) according the authentication algorithm 323 indicated in the SA. After this, the device starts performing the 324 digest generating operations. The work of defining actual digest 325 generating operations is out of the scope of this document. 327 The calculated data is compared with the received authentication data 328 in the packet and the packet MUST be discarded if the two do not 329 match. In such a case, an error event SHOULD be logged. 331 An implementation MAY have a transition mode where it includes 332 CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but 333 does not verify this information. This is provided as a transition 334 aid for networks in the process of migrating to the new CRYPTO_AUTH 335 and MET_CRYPTO_AUTH based authentication schemes. 337 3.5. Key Selection for BFD Packet Transmission 339 This section describes how the proposed security solution selects 340 long-lived keys from key tables [I-D.ietf-karp-crypto-key-table]. 341 Generally, a key used for BFD packet authentication should satisfy 342 the following requirements: 344 o The key time period as defined by Not Before Time and Not After 345 Time must include the current time. 347 o The key can be used for the desired security algorithm. 349 In the remainder of this section, additional requirements for keys 350 are enumerated. Assume that a device R1 tries to send a unicast BFD 351 packet from its interface I1 to the interface R2 of a remote device 352 R2 at time T. Because the key should be shared by the by both R1 and 353 R2 to protect the communication between I1 and I2, the key should 354 satisfy the following requirements: 356 o The Peer field includes the device ID of R2. 358 o The PeerKeyID field is not "unknown". 360 o The Interfaces field includes I1. 362 o The Direction field is either "out" or "both". 364 3.6. Replay Protection using Extended Sequence Numbers 366 As described in Section 1, if the BFD packets in a session are 367 transferred with a high frequency, a 32-bit sequence number may reach 368 its maximum and have to roll back before the session finishes. A 369 attacker thus can replay the packets intercepted before the sequence 370 number wrapped without being detected. To address this problem, the 371 length of the sequence number in the proposed authentication section 372 has been extended to 64 bits. After the extension, the sequence 373 number space of a device will not be exhausted within half of a 374 million years even if the device sends out a BFD packet in every 375 micro-second. Therefore, the replay attack risks caused by the 376 limited sequence number space can be largely addressed. However, in 377 Generic Cryptographic Authentication, the sequence number is only 378 required to increase occasionally. Therefore, a replayed packet may 379 be regarded as a legal one until the packet with a larger sequence 380 number is received. This type of intra-session replay attack cannot 381 be addressed only by extending the length of sequence numbers. 383 An anti-replay solution for BFD also needs to consider the scenarios 384 where a BFD device loses its prior sequence number state (e.g., 385 system crash, loss of power). In such cases, a BFD device has to re- 386 initialize its sequence number. Taking this opportunity, an attacker 387 may be able to replay the antique packets intercepted in previous 388 sessions without being detected. 390 To address this problem, in the proposed solution, the most 391 significant 32-bit value of the sequence number is used to contain a 392 boot count, and the remainder 32-bit value is used as an ordinary 32- 393 bit monotonically increasing sequence number. In Generic 394 Cryptographic Authentication, the remainder 32-bit value is required 395 to increase occasionally, while in Generic Meticulous Cryptographic 396 Authentication, the lower order 32-bit sequence number MUST be 397 incremented for every BFD packet sent by a BFD device. The BFD 398 implementations are required to retain the boot count in non-volatile 399 storage for the deployment life the BFD device. The boot count 400 increases each time when the BFD device loses its prior sequence 401 number state. The SNMPv3 snmpEngineBoots variable [RFC4222] MAY be 402 used for this purpose. However, maintaining a separate boot count 403 solely for BFD sequence numbers has the advantage of decoupling SNMP 404 re-initialization and BFD re-initialization. Also, in the rare event 405 that the lower order 32- bit sequence number wraps, the boot count 406 can be incremented to preserve the strictly increasing property of 407 the aggregate sequence number. Hence, a separate BFD boot count is 408 RECOMMENDED. 410 4. IANA Considerations 412 This document currently defines a value of 6 to be used to denote 413 Cryptographic Authentication mechanism for authenticating BFD control 414 packets and 7 for Meticulous Cryptographic Authentication. 416 5. Security Considerations 418 The proposed sequence number extension offers most of the benefits of 419 of more complicated mechanisms involving challenges. There are, 420 however, a couple drawbacks to this approach. First, it requires the 421 BFD implementation to be able to save its boot count in non-volatile 422 storage. If the non-volatile storage is ever repaired or upgraded 423 such that the contents are lost or the BFD device is replaced with a 424 model, the keys MUST be changed to prevent replay attacks. Second, 425 if a device is taken out of service completely (either intentionally 426 or due to a persistent failure), the potential exists for 427 reestablishment of a BFD adjacency by replaying the entire BFD 428 session establishment. This scenario is however, extremely unlikely 429 and can be easily avoided. For instance, after recovering from a 430 system failure, a BFD device has to re-establish BFD sessions. At 431 this stage, if the device randomly selects its discriminators to 432 identify new BFD sessions, the possibility of reestablishing a BFD 433 session by replaying the entire BFD session establishment will be 434 eliminated. For the implementations in which discriminators are not 435 randomly selected, this issue can be addressed by integrating the 436 boot count of the remote BFD router in the generation of the 437 authentication data for outgoing BFD packets. Of course, this attack 438 could also be thwarted by changing the relevant manual keys. 440 There is a transition mode suggested where devices can ignore the 441 CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the 442 packets. The operator must ensure that this mode is only used when 443 migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication 444 scheme as this leaves the device vulnerable to an attack. 446 6. Acknowledgements 448 7. References 450 7.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 7.2. References 457 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 459 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 460 CryptoBytes", 1996. 462 [I-D.ietf-karp-crypto-key-table] 463 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 464 Cryptographic Keys", draft-ietf-karp-crypto-key-table-01 465 (work in progress), May 2011. 467 [MD5-attack] 468 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 469 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", 470 August 2004. 472 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 473 April 1992. 475 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 476 Requirements for Security", BCP 106, RFC 4086, June 2005. 478 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 479 Version 2 Packets and Congestion Avoidance", BCP 112, 480 RFC 4222, October 2005. 482 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 483 (BFD)", RFC 5880, June 2010. 485 [SHA-1-attack1] 486 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 487 Full SHA-1", 2005. 489 [SHA-1-attack2] 490 Wang, X., Yao, A., and F. Yao, "New Collision Search for 491 SHA-1", 2005. 493 Authors' Addresses 495 Manav Bhatia 496 Alcatel-Lucent 497 Bangalore 498 India 500 Email: manav.bhatia@alcatel-lucent.com 501 Vishwas Manral 502 Hewlett-Packard Co. 503 19111 Pruneridge Ave. 504 Cupertino, CA 95014 505 USA 507 Email: vishwas.manral@hp.com 509 Dacheng Zhang 510 Huawei 511 Beijing, 512 China 514 Email: zhangdacheng@huawei.com