idnits 2.17.1 draft-bhatia-bfd-crypto-auth-03.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 (January 10, 2011) is 4855 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Manav Bhatia 2 Internet Draft Alcatel-Lucent 3 Intended Status: Proposed Standard Vishwas Manral 4 Expires: August 2011 IP Infusion 5 January 10, 2011 7 BFD Generic Cryptographic Authentication 9 draft-bhatia-bfd-crypto-auth-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 10, 2011. 28 Copyright Notice 30 Copyright (c) 2011 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document proposes an extension for Bidirectional Forwarding 46 Detection (BFD) to allow the use of any cryptographic authentication 47 algorithm in addition to the already documented authentication 48 schemes, described in the base specification. 50 Although this document has been written specifically to introduce two 51 new Authentication types it describes how BFD can use National 52 Institute of Standards and Technology (NIST) Secure Hash Standard 53 family of algorithms (SHS) to authenticate the control packets, the 54 method described in this document is generic and can be used to 55 extend BFD to support any cryptographic hash function in the future. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119. [RFC2119] 63 Contents 65 1. Introduction...................................................2 66 2. BFD Security Association.......................................4 67 3. Authentication Procedures......................................5 68 3.1 Cryptographic Authentication and Meticulous Cryptographic 69 Authentication.................................................5 70 3.2 Packet Encoding............................................5 71 3.3 Cryptographic Aspects......................................6 72 3.4 Procedures at the Sending Side.............................7 73 3.5 Procedure at the Receiving Side............................8 74 4. Security Considerations........................................9 75 5. IANA Considerations...........................................10 76 6. References....................................................10 77 6.1 Normative References......................................10 78 6.2 Informative References....................................10 79 7. Author's Addresses............................................11 81 1. Introduction 83 Bidirectional Forwarding Detection (BFD) [RFC5880] specification 84 includes five different types of authentication schemes: Simple 85 Password, Keyed MD5 [RFC1321], Meticulous Keyed MD5, Keyed SHA-1 and 86 Meticulous SHA-1. In the simple password scheme of authentication, 87 the passwords are exchanged in the clear text on the network and 88 anyone with physical access to the network can learn the password and 89 compromise the security of the BFD domain. 91 In Keyed MD5 and Meticulous Keyed MD5, the BFD routers share a secret 92 key which is used to generate a keyed MD5 digest for each packet and 93 a monotonically increasing sequence number scheme is used to prevent 94 replay attacks. 96 This isnt good enough as there have been recent reports about attacks 97 on MD5 which raises concerns about the remaining useful lifetime of 98 this scheme. Specifically, the researchers have been able to develop 99 algorithms that can compute hash collisions for some applications of 100 MD5 [MD5-attack] [Dobb96a, Dobb96b]. 102 It should however be noted that these attacks may not necessarily 103 result in direct vulnerabilities in Keyed-MD5 as used in BFD 104 authentication purposes, because the colliding message may not 105 necessarily be a syntactically correct protocol packet. However, 106 there is a need felt to move away from MD5 towards more complex and 107 difficult to break hash algorithms. 109 In Keyed SHA-1 and Meticulous SHA-1, the BFD routers share a secret 110 key which is used to generate a keyed SHA-1 digest for each packet 111 and a monotonically increasing sequence number scheme is used to 112 prevent replay attacks. 114 Like MD5 there have been reports of attacks on SHA-1 [SHA-1-attack1] 115 [SHA-1-attack2]. Such attacks do not mean that all the protocols 116 using SHA-1 for authentication are at risk. However, it does mean 117 that SHA-1 should be replaced as soon as possible and should not be 118 used for new applications. 120 It should be noted that if SHA-1 is used in the Hashed Message 121 Authentication Code (HMAC) [RFC2104] construction then collision 122 attacks currently known against SHA-1 do not apply. The new attacks 123 on SHA-1 have no impact on the security of HMAC-SHA-1. 125 HMAC can be used, without modifying any hash function, for 126 calculating and verifying the message authentication values. It 127 verifies both the data integrity and the authenticity of a message. 129 This document proposes two new authentication types - the 130 cryptographic authentication (CRYPTO_AUTH) and the meticulous 131 cryptographic authentication (MET_ CRYPTO_AUTH). These can be used to 132 specify any authentication algorithm for authenticating and verifying 133 the BFD packets. 135 By definition, HMAC requires a cryptographic hash function. We 136 propose to use any one of Secure Hash Algorithms (SHA) defined in US 137 NIST Secure Hash Standard (SHS) [FIPS-180-3]. [FIPS-180-3] includes 138 SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The HMAC 139 authentication mode defined in NIST FIPS 198 is used [FIPS-198]. 141 It is believed that [RFC2104] is mathematically identical to 142 [FIPS-198] and it is also believed that algorithms in [RFC4634] are 143 mathematically identical to [FIPS-180-3]. 145 Of the above, implementations of this specification MUST include 146 support for at least HMAC-SHA-256 and SHOULD include support for 147 HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or 148 HMAC-SHA-512. 150 An implementation of this specification MUST allow network operators 151 to configure ANY authentication algorithm supported by that 152 implementation for use with ANY given KeyID value that is configured 153 into that BFD router. 155 2. BFD Security Association 157 The BFD protocol does not include an in-band mechanism to create or 158 manage BFD Security Associations (BFD SA). A BFD SA contains a set of 159 shared parameters between any two legitimate BFD routers. 161 Parameters associated with a BFD SA: 163 O Authentication Key Identifier (Key ID) : This is a two octet 164 unsigned integer used to uniquely identify the BFD SA, as manually 165 configured by the network operator (or, in the future, possibly by 166 some key management protocol specified by the IETF). The receiver 167 determines the active SA by looking at this field in the incoming 168 packet. The sender puts this Key ID in the BFD packet based on the 169 active configuration. 171 Using Key IDs makes changing keys while maintaining protocol 172 operation convenient. Each key ID specifies two independent parts, 173 the authentication protocol and the authentication key, as explained 174 below. Normally, an implementation would allow the network operator 175 to configure a set of keys in a key chain, with each key in the chain 176 having fixed lifetime. The actual operation of these mechanisms is 177 outside the scope of this document. 179 Note that each Key ID can indicate a key with a different 180 authentication protocol. This allows multiple authentication 181 mechanisms to be used at various times without disrupting BFD 182 sessions, including the introduction of new authentication 183 mechanisms. 185 o Authentication Algorithm : This indicates the authentication 186 algorithm to be used with the BFD SA. This information SHOULD never 187 be sent in cleartext over the wire. At present, the following values 188 are possible: Keyed MD5, Keyed SHA-1, HMAC-SHA-1, HMAC-SHA-256, HMAC- 189 SHA-384 and HMAC-SHA-512. 191 o Authentication Key : This indicates the cryptographic key 192 associated with this BFD SA. The length of this key is variable and 193 depends upon the authentication algorithm specified by the BFD SA. 194 Operators MUST ensure that this is never sent over the network in 195 clear-text via any protocol. Care should also be taken to ensure that 196 the selected key is unpredictable, avoiding any keys known to be weak 197 for the algorithm in use. [RFC4086] contains helpful information on 198 both key generation techniques and cryptographic randomness. This is 199 noted as "K" in section 3.3 below. 201 3. Authentication Procedures 203 3.1 Cryptographic Authentication and Meticulous Cryptographic 204 Authentication 206 The Authentication section is only present in the BFD packet if the 207 Authentication Present (A) bit is set in the header. The Auth Type in 208 the Authentication section is set to 6 to indicate the Cryptographic 209 Authentication is in use, and is set to 7, to indicate that the 210 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 a replay attack is possible till the next 220 sequence number is sent in the Cryptographic Authentication scheme. 222 3.2 Packet Encoding 224 A new authentication type, 6 or 7, indicating the cryptographic 225 authentication mechanism in use, is inserted in the first octet of 226 Authentication Section of the BFD control packet. 228 If the Authentication Present (A) bit is set in the header, and the 229 Authentication Type field contains 6 (Cryptographic Authentication) 230 or 7 (Meticulous Cryptographic Authentication), the Authentication 231 Section has the following format: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Auth Type | Auth Len | Auth Key ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Sequence Number | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 | Authentication Data (Variable) | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Auth Type 247 The Authentication Type, which in this case is 6 (Cryptographic 248 Authentication) or 7 (Meticulous Cryptographic Authentication). 250 Auth Len 252 Length of the Authentication Section. 254 Auth Key ID 256 The Authentication Key ID in use for this packet. This allows 257 multiple keys to be active simultaneously. 259 Sequence Number 261 The Sequence Number for this packet. For Cryptographic Authentication 262 this value is incremented occasionally. For Meticulous Cryptographic 263 Authentication, this value is incremented for each successive packet 264 transmitted for a session. 266 Authentication Data 268 This field carries the digest computed by whatever Cryptographic 269 Authentication algorithm is being used to authenticate the BFD 270 control packet. 272 3.3 Cryptographic Aspects 274 In the algorithm description below, the following nomenclature, which 275 is consistent with [FIPS-198], is used: 277 H is the specific hashing algorithm (e.g. SHA-256). 278 K is the password for the BFD packet. 279 Ko is the cryptographic key used with the hash algorithm. 281 B is the block size of H, measured in octets rather than bits. 283 Note that B is the internal block size, not the hash size. 284 For SHA-1 and SHA-256: B == 64 285 For SHA-384 and SHA-512: B == 128 286 L is the length of the hash, measured in octets rather than bits. 288 XOR is the exclusive-or operation. 289 Opad is the hexadecimal value 0x5c repeated B times. 290 Ipad is the hexadecimal value 0x36 repeated B times. 291 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 293 (1)Preparation of the Key 295 In this application, Ko is always L octets long. 297 If the Authentication Key (K) is L octets long, then Ko is equal 298 to K. If the Authentication Key (K) is more than L octets long, 299 then Ko is set to H(K). If the Authentication Key (K) is less 300 than L octets long, then Ko is set to the Authentication Key (K) 301 with zeros appended to the end of the Authentication Key (K) such 302 that Ko is L octets long. 304 (2)First Hash 306 First, the Authentication Data field in the BFD Auth Section is 307 filled with the value Apad and the Authentication Type field is 308 set to 6 or 7 depending upon which Authentication Type is being 309 used. The Sequence Number field MUST be set to bfd.XmitAuthSeq. 311 Then, a first hash, also known as the inner hash, is computed 312 as follows: 314 First-Hash = H(Ko XOR Ipad || (BFD Packet)) 316 (3)Second Hash 318 Then a second hash, also known as the outer hash, is computed 319 as follows: 321 Second-Hash = H(Ko XOR Opad || First-Hash) 323 (4)Result 325 The resultant Second-Hash becomes the Authentication Data that is 326 sent in the Authentication Data field of the BFD Authentication 327 Section. The length of the Authentication Data field is always 328 identical to the message digest size of the specific hash function 329 H that is being used. 331 This also means that the use of hash functions with larger output 332 sizes will also increase the size of BFD Packet as transmitted 333 on the wire. 335 3.4 Procedures at the Sending Side 337 An appropriate BFD SA is selected for use with an outgoing BFD 338 packet. This is done based on the active key at that instant. If BFD 339 is unable to find an active key, the BFD packet is discarded. 341 If BFD is able to find the active key, then the key gives the 342 authentication algorithm (HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 or 343 HMAC-SHA-512) that needs to be applied on the packet. 345 An implementation MUST fill the Auth Type and the Auth length before 346 the authentication data is computed. The Sequence Number field MUST 347 be set to bfd.XmitAuthSeq. 349 The Auth length in the Authentication section is set as per the 350 authentication algorithm that is being used. It is set to 28 for 351 HMAC-SHA-1, 40 for HMAC-SHA-256, 56 for HMAC-SHA-384 and 72 for HMAC- 352 SHA-512. 354 The Key ID is filled. 356 The authentication data is computed as explained in the previous 357 section. 359 The result of the authentication algorithm is placed in the 360 Authentication data, following the Key ID. 362 3.5 Procedure at the Receiving Side 364 The appropriate BFD SA is identified by looking at the Key ID from 365 the Authentication Section from the incoming BFD packet. 367 If the Auth Key ID field does not match the ID of a configured 368 authentication key, the received packet MUST be discarded. 370 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 371 Cryptographic Authentication, if the Sequence Number lies outside of 372 the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) 373 inclusive (when treated as an unsigned 32 bit circular number space), 374 the received packet MUST be discarded. For Meticulous Cryptographic 375 Authentication, if the Sequence Number lies outside of the range of 376 bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 377 treated as an unsigned 32 bit circular number space, the received 378 packet MUST be discarded. 380 Authentication Algorithm dependent processing, needs to be performed, 381 using the algorithm specified by the appropriate BFD SA for the 382 received packet. 384 Before an implementation performs any processing it needs to save the 385 values of the Authentication Value field. 387 It should then set the Authentication Value field with Apad before 388 the authentication data is computed. The calculated data is compared 389 with the received authentication data in the packet and the packet is 390 discarded if the two do not match. In such a case, an error event 391 SHOULD be logged. 393 An implementation MAY have a transition mode where it includes 394 CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but 395 does not verify this information. This is provided as a transition 396 aid for networks in the process of migrating to the new CRYPTO_AUTH 397 and MET_CRYPTO_AUTH based authentication schemes. 399 4. Security Considerations 401 This document enhances the security of the BFD protocol by adding, to 402 the existing BFD cryptographic authentication methods, support for 403 the algorithms defined in the NIST Secure Hash Standard (SHS) using 404 the Hashed Message Authentication Code (HMAC) mode, and by adding 405 support for the Hashed Message Authentication Code (HMAC) mode. It 406 does not provide confidentiality as BFD contains information that 407 does not need to be kept secret. 409 Because all of the currently specified algorithms use symmetric 410 cryptography, one cannot authenticate precisely which BFD router 411 sent a given packet. However, one can authenticate that the sender 412 knew the BFD Security Association (including the BFD SA's parameters) 413 currently in use. 415 The technology in this document provides an authentication mechanism 416 for BFD. The mechanism described here is not perfect and does not 417 need to be perfect. Instead, this mechanism represents a significant 418 increase in the work function of an adversary attacking the BFD 419 protocol, while not causing undue implementation, deployment, or 420 operational complexity. 422 There is a transition mode suggested where routers can ignore the 423 CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the 424 packets. The operator must ensure that this mode is only used when 425 migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication 426 scheme as this leaves the router vulnerable to an attack. 428 To ensure greater security, the keys used should be changed 429 periodically and implementations MUST be able to store and use more 430 than one key at the same time. The quality of the security provided 431 by the Cryptographic Authentication option depends completely on the 432 strength of the cryptographic algorithm and cryptographic mode in 433 use, the strength of the key being used, and the correct 434 implementation of the security mechanism in all communicating BFD 435 implementations. Accordingly, the use of high assurance development 436 methods is recommended. It also requires that all parties maintain 437 the secrecy of the shared secret key. [RFC4086] provides guidance on 438 methods for generating cryptographically random bits. 440 The value Apad is used here primarily for consistency with IETF 441 specifications for HMAC-SHA authentication of RIPv2 SHA [RFC4822], 442 IS-IS SHA [RFC5310] and OSPF SHA [RFC5709]. 444 5. IANA Considerations 446 This document currently defines a value of 6 to be used to denote 447 Cryptographic Authentication mechanism for authenticating BFD control 448 packets and 7 for Meticulous Cryptographic Authentication. 450 6. References 452 6.1 Normative References 454 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 455 April 1992 457 [RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message 458 Authentication", RFC 2104, February 1997 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997 463 [RFC5880] Katz, D. and Ward, D., "Bidirectional Forwarding 464 Detection", RFC 5880, June 2010 466 [FIPS-180-3] National Institute of Standards and Technology, "Secure 467 Hash Standard (SHS)", FIPS PUB 180-3, October 2008 469 [FIPS-198] US National Institute of Standards & Technology, "The 470 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 471 198, March 2002. 473 6.2 Informative References 475 [MD5-attack] Wang, X. et al., "Collisions for Hash Functions MD4, 476 MD5, HAVAL-128 and RIPEMD", August 2004, 477 http://eprint.iacr.org/2004/199 479 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical 480 Report, 2 May 1996. (Presented at the Rump Session of 481 EuroCrypt 1996.) 483 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", 484 CryptoBytes, Vol. 2, No. 2, Summer 1996. 486 [SHA-1-attack1] Wang, X. et. al., "Finding Collisions in the Full 487 SHA-1", Advances in Cryptology CRYPTO 05, pp. 17-36 489 [SHA-1-attack2] Wang, X. et. al., "New Collision Search for SHA-1", 490 Technical Report, August 2005 (Presented in the Rump 491 Session of CRYPTO 05) 493 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 494 (SHA and HMAC-SHA)", RFC 4634, July 2006. 496 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 497 "Randomness Requirements for Security", BCP 106, RFC 498 4086, June 2005. 500 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 501 Authentication", RFC 4822, February 2007. 503 [RFC5310] Bhatia, M., et. al., "IS-IS Generic Cryptographic 504 Authentication", RFC 5310, February 2009. 506 [RFC5709] Bhatia, M., et. al., "IS-IS Generic Cryptographic 507 Authentication", RFC 5709, October 2009. 509 7. Author's Addresses 511 Manav Bhatia 512 Alcatel-Lucent, 513 Bangalore, India 514 Email: manav.bhatia@alcatel-lucent.com 516 Vishwas Manral 517 IP Infusion 518 Almora, Uttarakhand, India 519 Email: vishwas@ipinfusion.com