idnits 2.17.1 draft-ietf-opsec-igp-crypto-requirements-04.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 == Line 433 has weird spacing: '...outeing infor...' -- The document date (October 12, 2010) is 4944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) -- Obsolete informational reference (is this intentional?): RFC 1388 (Obsoleted by RFC 1723) -- Obsolete informational reference (is this intentional?): RFC 1723 (Obsoleted by RFC 2453) -- Obsolete informational reference (is this intentional?): RFC 2082 (Obsoleted by RFC 4822) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational V. Manral 5 Expires: April 15, 2011 IP Infusion 6 October 12, 2010 8 Summary of Cryptographic Authentication Algorithm Implementation 9 Requirements for Routing Protocols 10 draft-ietf-opsec-igp-crypto-requirements-04 12 Abstract 14 The routing protocols Open Shortest Path First version 2 (OSPFv2), 15 Intermediate System to Intermediate System (IS-IS) and Routing 16 Information Protocol (RIP) currently define cleartext and MD5 17 (Message Digest 5) methods for authenticating protocol packets. 18 Recently effort has been made to add support for the SHA (Secure Hash 19 Algorithm) family of hash functions for the purpose of authenticating 20 routing protocol packets for RIP, IS-IS and OSPF. 22 To encourage interoperability between disparate implementations, it 23 is imperative that we specify the expected minimal set of algorithms 24 thereby ensuring that there is at least one algorithm that all 25 implementations will have in common. 27 Similarly RIPng and OSPFv3 support IPSec algorithms for 28 authenticating their protocol packets. 30 This document examines the current set of available algorithms with 31 interoperability and effective cryptographic authentication 32 protection being the principle considerations. Cryptographic 33 authentication of these routing protocols requires the availability 34 of the same algorithms in disparate implementations. It is desirable 35 that newly specified algorithms should be implemented and available 36 in routing protocol implementations because they may be promoted to 37 requirements at some future time. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 15, 2011. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Intermediate System to Intermediate System (IS-IS) . . . . . . 6 76 2.1. Authentication Scheme Selection . . . . . . . . . . . . . 6 77 2.2. Authentication Algorithm Selection . . . . . . . . . . . . 6 79 3. Open Shortest Path First Version 2(OSPFv2) . . . . . . . . . . 8 80 3.1. Authentication Scheme Selection . . . . . . . . . . . . . 8 81 3.2. Authentication Algorithm Selection . . . . . . . . . . . . 8 83 4. Open Shortest Path First Version 3 (OSPFv3) . . . . . . . . . 10 85 5. Routing Information Protocol Version 2 (RIPv2) . . . . . . . . 11 86 5.1. Authentication Scheme Selection . . . . . . . . . . . . . 11 87 5.2. Authentication Algorithm Selection . . . . . . . . . . . . 11 89 6. Routing Information Protocol for IPv6 (RIPng) . . . . . . . . 13 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Introduction 105 Most routing protocols include three different types of 106 authentication schemes: Null authentication, cleartext Password and a 107 Cryptographic Authentication scheme. Null authentication is 108 equivalent to having no authentication scheme at all. 110 In a cleartext scheme, also known as, simple password scheme, the 111 password is exchanged completely unprotected and anyone with physical 112 access to the network can learn the password and compromise the 113 integrity of the routing domain. The simple password scheme protects 114 from accidental establishment of routing sessions in a given domain, 115 but beyond that it offers no additional protection. 117 In a cryptographic authentication scheme, routers share a secret key 118 which is used to generate a message authentication code for each of 119 the protocol packets. Today, routing protocols that implement 120 message authentication codes often use a keyed MD5 [RFC1321] digest. 121 The recent escalating series of attacks on MD5 raise concerns about 122 its remaining useful lifetime. 124 These attacks may not necessarily result in direct vulnerabilities 125 for keyed MD5 digests as message authentication codes because the 126 colliding message may not correspond to a syntactically correct 127 protocol packet. The known collision, pre-image, and second pre- 128 image attacks [RFC4270] on MD5 may not increase the effectiveness of 129 the key recovery attacks on HMAC-MD5. Regardless, there is a need 130 felt to deprecated MD5 [RFC1321] as the basis for the HMAC algorithm 131 in favor of stronger digest algorithms. 133 In light of these considerations, there are proposals to replace 134 HMAC-MD5 with keyed HMAC-SHA [SHS] digests where HMAC-MD5 is 135 currently mandated in RIPv2 [RFC2453] and IS-IS [ISO] [RFC1195] and 136 keyed-MD5 in OSPFv2 [RFC2328]. 138 OSPFv3 [RFC5340] and RIPng [RFC2080] rely on the IPv6 Authentication 139 Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) 140 [RFC4303] in order to provide integrity, authentication, and/or 141 confidentiality. 143 However, the nature of cryptography is that algorithmic improvement 144 is an ongoing process and as is the exploration and refinement of 145 attack vectors. An algorithm believed to be strong today may be 146 demonstrated to be weak tomorrow. Given this, the choice of 147 preferred algorithm should favor the minimization of the likelihood 148 of it being compromised quickly. 150 It should be recognized that preferred algorithm(s) will change over 151 time to adapt to the evolving threats. At any particular time, the 152 mandatory to implement algorithm(s) might not be specified in the 153 base protocol specification. As protocols are extended the 154 preference for presently stronger algorithms presents a problem both 155 on the question of interoperability of existing and future 156 implementations with respect to standards and operational preference 157 for the configuration as deployed. 159 It is expected an implementation should support changing of security 160 (authentication) keys. Changing the symmetric key used in any HMAC 161 algorithm on a periodic basis is good security practice. Operators 162 need to plan for this. 164 Implementations can support in-service key change so that no control 165 packets are lost. During an in-service/in-band key change more than 166 one key can be active for receiving packets for a session. Some 167 protocols support a key identifier which allows the two peers of a 168 session to have multiple keys simultaneously for a session. 170 However, these protocols currently manage keys manually (i.e., 171 operator intervention) or dynamically based on some timer or security 172 protocol. 174 2. Intermediate System to Intermediate System (IS-IS) 176 The IS-IS specification allows for authentication of its Protocol 177 Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. 178 The base specification [ISO] had provisions only for cleartext 179 passwords. [RFC5304] extends the authentication capabilities by 180 providing cryptographic authentication for IS-IS PDUs. It mandates 181 support for HMAC-MD5. 183 [RFC5310] adds support for the use of any cryptographic hash function 184 for authenticating IS-IS PDUs. It in addition to this, also details 185 how IS-IS can use HMAC construct along with the Secure Hash Algorithm 186 (SHA) family of cryptographic hash functions to secure IS-IS PDUs. 188 2.1. Authentication Scheme Selection 190 In order for IS-IS implementations to securely interoperate, they 191 must support one or more authentication schemes in common. This 192 section specifies the preference for standards conformant IS-IS 193 implementations, which desire to utilize the security feature. 195 The earliest interoperability requirement for authentication as 196 stated by [ISO] [RFC1195] required all implementations to support 197 cleartext Password. This authentication scheme's utility is limited 198 to precluding the accidental introduction of a new IS into a 199 broadcast domain. Operators should not use this scheme as it 200 provides no protection against an attacker with access to the 201 broadcast domain as anyone can determine the secret password through 202 inspection of the PDU. This mechanism does not provide any 203 significant level of security and should be avoided. 205 [RFC5304] defined the cryptographic authentication scheme for IS-IS. 206 HMAC-MD5 was the only algorithm specified, hence it is mandated. 207 [RFC5310] defined a generic cryptographic scheme and added support 208 for additional algorithms. Implementations should support [RFC5310] 209 as it defines the generic cryptographic authentication scheme. 211 2.2. Authentication Algorithm Selection 213 For IS-IS implementations to securely interoperate, they must have 214 support for one or more authentication algorithms in common. 216 This section details the authentication algorithm requirements for 217 standards conformant IS-IS implementations. 219 The following are the available options for authentication 220 algorithms: 222 o [RFC5304] mandates the use of HMAC-MD5. 224 o [RFC5310] does not require a particular algorithm but instead 225 supports any digest algorithm (i.e., cryptographic hash function). 227 As noted earlier, there is a desire to deprecate the use of MD5. 228 IS-IS implementations will likely migrate to an authentication scheme 229 supported by [RFC5310] because it is algorithm agnostic. Possible 230 digest algorithms included: SHA-1, SHA-256, SHA-384, and SHA-512. 231 Picking at least one mandatory-to-implement algorithms is imperative 232 to ensuring interoperability. 234 3. Open Shortest Path First Version 2(OSPFv2) 236 [RFC2328] includes three different types of authentication schemes: 237 Null authentication, cleartext password (defined as simple password 238 in [RFC2328]) and cryptographic authentication. Null authentication 239 is semantically equivalent to no authentication. 241 In the cryptographic authentication scheme, the OSPFv2 routers on a 242 common network/subnet are configured with a shared secret which is 243 used to generate a keyed MD5 digest for each packet. A monotonically 244 increasing sequence number scheme is used to protect against replay 245 attacks. 247 [RFC5709] adds support for the use of the SHA family of hash 248 algorithms for authentication of OSPFv2 packets. 250 3.1. Authentication Scheme Selection 252 For OSPF implementations to securely interoperate, they must have one 253 or more authentication schemes in common. 255 While all implementations will have NULL auth since it's mandated by 256 [RFC2328], its use is not appropriate in any context where the 257 operator wishes to authenticate OSPFv2 packets in their network. 259 While all implementations will also have Cleartext Password since 260 it's mandated by [RFC2328], its use is only appropriate for use when 261 the operator wants to preclude the accidental introduction of a 262 router into the domain. This scheme is patently not useful when an 263 operator wants to authenticate the OSPFv2 packets. 265 Cryptographic Authentication is a mandatory scheme defined in 266 [RFC2328] and all conformant implementations must support this. 268 3.2. Authentication Algorithm Selection 270 For OSPFv2 implementations to securely interoperate, they must 271 support one or more cryptographic authentication algorithms in 272 common. 274 The following are the available options for authentication 275 algorithms: 277 o [RFC2328] specifies the use of HMAC-MD5. 279 o [RFC5709] specifies the use of HMAC-SHA1, HMAC-SHA224, HMAC- 280 SHA256, HMAC-SHA384, and HAMC-512 and mandates support for HMAC- 281 SHA256 (HMAC-SHA1 is optional). 283 As noted earlier, there is a desired to deprecate the use MD5. Some 284 alternatives for MD5 are listed in [RFC5709]. 286 Possible digest algorithms included: SHA-1, SHA-224, SHA-256, SHA- 287 384, and SHA-512. Picking one mandatory-to-implement algorithms is 288 imperative to ensuring interoperability. 290 4. Open Shortest Path First Version 3 (OSPFv3) 292 OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH) 293 [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in 294 order to provide integrity, authentication, and/or confidentiality. 296 [RFC4522] mandates the use of ESP for authenticating OSPFv3 packets. 297 The implementations could also provide support for using AH to 298 protect these packets. 300 The algorithm requirements for AH and ESP are described in [RFC4835] 301 as follows: 303 o [RFC2404] mandates HMAC-SHA1-96. 305 o [RFC3566] indicates AES-XCBC-MAC-96 as a should, but its likely 306 that this will be mandated at some future time. 308 5. Routing Information Protocol Version 2 (RIPv2) 310 RIPv2, originally specified in [RFC1388], then [RFC1723], has been 311 updated and published as STD56 [RFC2453]. If the Address Family 312 Identifier of the first (and only the first) entry in the RIPv2 313 message is 0xFFFF, then the remainder of the entry contains the 314 authentication information. The [RFC2453] version of the protocol 315 provides for authenticating packets using a cleartext password 316 (defined as "simple password" in [RFC2453]) not more than 16 octets 317 in length. 319 [RFC2082] added support for Keyed MD5 authentication, where a digest 320 is appended to the end of the RIP packet. [RFC4822] obsoleted 321 [RFC2082] and added the SHA family of hash algorithms to the list of 322 cryptographic authentications that can be used to protect RIPv2, 323 whereas [RFC2082] previously specified only the use of Keyed MD5. 325 5.1. Authentication Scheme Selection 327 For RIPv2 implementations to securely interoperate they must support 328 one or more authentication schemes in common. 330 While all implementations will support cleartext password since it's 331 mandated by [RFC2453], its use is only appropriate for use when the 332 operator wants to preclude the accidental introduction of a router 333 into the domain. This scheme is patently not useful when an operator 334 wants to authenticate the RIPv2 packets. 336 [RFC2082] mandates the use of an authentication scheme that uses 337 Keyed MD5. However, [RFC2082] has been obsoleted by [RFC4822] 338 Cryptographic Authentication. Compliant implementations must provide 339 support for an authentication scheme that uses Keyed MD5 but should 340 recognize that this is superseded by Cryptographic Authentication as 341 defined in [RFC4822]. 343 Implementations should provide support for [RFC4822] as it specifies 344 the RIPv2 Cryptographic Authentication schemes. 346 5.2. Authentication Algorithm Selection 348 For RIPv2 implementations to securely interoperate they must support 349 one or more authentication algorithms in common. 351 The following are the available options for authentication 352 algorithms: 354 o [RFC2082] specifies the use of keyed MD5. 356 o [RFC4822] specifies the use of HMAC-MD5, HMAC-SHA1, HMAC-SHA224, 357 HMAC- SHA256, HMAC-SHA384 and HMAC-SHA512. 359 As noted earlier, there is a desire to deprecate the use MD5. Some 360 alternatives for MD5 are listed in [RFC4822]. Possible digest 361 algorithms included: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 362 Picking one mandatory-to-implement algorithms is imperative to 363 ensuring interoperability. 365 6. Routing Information Protocol for IPv6 (RIPng) 367 RIPng [RFC2080] relies on the IPv6 Authentication Header (AH) 368 [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in 369 order to provide integrity, authentication, and/or confidentiality. 371 The algorithm requirements for AH and ESP are described in [RFC4835] 372 as follows: 374 o [RFC2404] mandates HMAC-SHA1-96. 376 o [RFC3566] indicates AES-XCBC-MAC-96 as a should, but its likely 377 that this will be mandated at some future time. 379 7. Security Considerations 381 The cryptographic mechanisms referenced in this document provide only 382 authentication algorithms. These algorithms do not provide 383 confidentiality. Encrypting the content of the packet and thereby 384 providing confidentiality is not considered in the definition of the 385 routing protocols. 387 The cryptographic strength of the HMAC depends upon the cryptographic 388 strength of the underlying hash function and on the size and quality 389 of the key. The feasibility of attacking the integrity of routing 390 protocol messages protected by keyed digests may be significantly 391 more limited than that of other data, however preference for one 392 family of algorithms over another may also change independently of 393 the perceived risk to a particular protocol. 395 To ensure greater security, the keys used should be changed 396 periodically and implementations must be able to store and use more 397 than one key at the same time. Operational experience suggests that 398 the lack of periodic rekeying is a source of significant exposure and 399 that the lifespan of shared keys in the network is frequently 400 measured in years. 402 While simple password schemes are well represented in the document 403 series and in conformant implementations of the protocols, the 404 inability to offer either integrity or identity protection are 405 sufficient reason to strongly discourage their use. 407 This document concerns itself with the selection of cryptographic 408 algorithms for use in the authentication of routing protocol packets 409 being exchanged between adjacent routing processes. The 410 cryptographic algorithms identified in this document are not known to 411 be broken at the current time, and ongoing cryptographic research so 412 far leads us to believe that they will likely remain secure in the 413 foreseeable future. We expect that new revisions of this document 414 will be issued in the future to reflect current thinking on the 415 algorithms various routing protocols should employ to ensure 416 interoperability between disparate implementations. 418 8. IANA Considerations 420 This document has no actions for IANA. 422 9. Acknowledgements 424 We would like to thank Joel Jaeggli, Sean Turner and Adrian Farrel 425 for their comments and feedback on this draft that resulted in 426 significant improvement of the same. 428 10. References 430 10.1. Normative References 432 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate 433 system routeing information exchange protocol for use in 434 conjunction with the Protocol for providing the 435 Connectionless-mode Network Service (ISO 8473)". 437 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 438 dual environments", RFC 1195, December 1990. 440 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 441 January 1997. 443 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 445 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 446 November 1998. 448 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 449 Authentication", RFC 4822, February 2007. 451 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 452 Requirements for Encapsulating Security Payload (ESP) and 453 Authentication Header (AH)", RFC 4835, April 2007. 455 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 456 Authentication", RFC 5304, October 2008. 458 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 459 and M. Fanto, "IS-IS Generic Cryptographic 460 Authentication", RFC 5310, February 2009. 462 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 463 for IPv6", RFC 5340, July 2008. 465 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 466 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 467 Authentication", RFC 5709, October 2009. 469 10.2. Informative References 471 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 472 April 1992. 474 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 475 Information", RFC 1388, January 1993. 477 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 478 Information", STD 56, RFC 1723, November 1994. 480 [RFC2082] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 481 Authentication", RFC 2082, January 1997. 483 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 484 ESP and AH", RFC 2404, November 1998. 486 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 487 and Its Use With IPsec", RFC 3566, September 2003. 489 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 490 Hashes in Internet Protocols", RFC 4270, November 2005. 492 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 493 December 2005. 495 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 496 RFC 4303, December 2005. 498 [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP): 499 The Binary Encoding Option", RFC 4522, June 2006. 501 [SHS] "National Institute of Standards and Technology (NIST), 502 FIPS Publication 180-3: Secure Hash Standard", 503 October 2008. 505 Authors' Addresses 507 Manav Bhatia 508 Alcatel-Lucent 509 Bangalore, 510 India 512 Phone: 513 Email: manav.bhatia@alcatel-lucent.com 515 Vishwas 516 IP Infusion 517 USA 519 Phone: 520 Email: vishwas@ipinfusion.com