idnits 2.17.1 draft-bhatia-manral-igp-crypto-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2453], [RFC1321], [RFC2328], [RFC1195], [RFC4822], [RFC5709], [ISO], [RFC5310]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2009) is 5276 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft November 2009 3 Network Working Group Manav Bhatia 4 Internet Draft Alcatel-Lucent 5 Expires: May 11, 2010 Vishwas Manral 6 Intended Status: Informational IP Infusion 7 November 11, 2009 9 Cryptographic Authentication Algorithm Implementation 10 Best Practices for Routing Protocols 12 draft-bhatia-manral-igp-crypto-requirements-04.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The routing protocols Open Shortest Path First version 2 (OSPFv2) 58 [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] 59 [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently 60 define Clear Text and MD5 (Message Digest 5) [RFC1321] methods for 61 authenticating protocol packets. Recently effort has been made to add 62 support for the SHA (Secure Hash Algorithm) family of hash functions 63 for the purpose of authenticating routing protocol packets for RIP 64 [RFC4822], IS-IS [RFC5310] and OSPF [RFC5709]. 66 To encourage interoperability between disparate implementations, it 67 is imperative that we specify the expected minimal set of algorithms 68 thereby ensuring that there is at least one algorithm that all 69 implementations will have in common. 71 This document examines the current set of available algorithms with 72 interoperability and effective cryptographic authentication 73 protection being the principle considerations. Cryptographic 74 authentication of these routing protocols requires the availability 75 of the same algorithms in disparate implementations. It is desirable 76 that newly specified algorithms should be implemented and available 77 in routing protocol implementations because they may be promoted to 78 requirements at some future time. 80 Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119. [RFC2119] 86 Table of Contents 88 1. Introduction...................................................3 89 2. Requirements Terminology.......................................4 90 3. Intermediate System to Intermediate System (IS-IS).............4 91 3.1 Authentication Scheme Selection............................4 92 3.2 Authentication Algorithm Selection.........................5 93 4. Open Shortest Path First Version 2(OSPFv2).....................5 94 4.1 Authentication Scheme Selection............................5 95 4.2 Authentication Algorithm Selection.........................6 96 5. Open Shortest Path First Version 3 (OSPFv3)....................6 97 6. Routing Information Protocol Version 2 (RIPv2).................6 98 6.1 Authentication Scheme Selection............................7 99 6.2 Authentication Algorithm Selection.........................7 100 7. Routing Information Protocol for IPv6 (RIPng)..................8 101 8. Security Considerations........................................8 102 9. Acknowledgements...............................................9 103 10. IANA Considerations...........................................9 104 11. References....................................................9 105 11.1 Normative References......................................9 106 11.2 Informative References...................................10 107 Author's Addresses...............................................10 109 1. 110 Introduction 112 Most routing protocols include three different types of 113 authentication schemes: Null authentication, Clear Text Password and 114 a Cryptographic Authentication scheme. NULL authentication is 115 equivalent to having no authentication scheme at all. 117 In a clear text scheme, also known as, simple password scheme, the 118 password is exchanged in the clear on the network and anyone with 119 physical access to the network can learn the password and compromise 120 the integrity of the routing domain. While the Password scheme 121 protects from accidental establishment of routing session in a given 122 domain, it offers little additional protection. 124 In a cryptographic authentication scheme, routers share a secret key 125 which is used to generate a keyed MD5 (or other) digest which is used 126 for authenticating the protocol packets. 128 There have been an escalating series of attacks on MD5 which raises 129 concerns about the remaining useful lifetime of this hash algorithm. 131 It should be noted that these attacks may not necessarily result in 132 direct vulnerabilities in Keyed-MD5 as used in the routing protocols 133 for authentication purposes, because the colliding message may not 134 necessarily be a syntactically correct protocol packet. There is a 135 however a need felt to deprecate MD5 in favor of stronger hash 136 algorithms. 138 In light of these considerations there have been proposals for adding 139 support of the SHA family of hash algorithms for authenticating 140 routing protocol packets in RIP, IS-IS and OSPF. 142 However, the nature of cryptography is that algorithmic 143 improvement is an ongoing process and as is the exploration and 144 refinement of attack vectors. An algorithm believed to be strong 145 today may be demonstrated to be weak tomorrow. Given this, the choice 146 of preferred algorithm should favor the minimization of the 147 likelihood of it being compromised quickly. 149 It should be recognized that preferred algorithm(s) will change over 150 time in to adapt to the evolving threats. The selection of preferred 151 algorithms may well not be reflected in the base protocol 152 specification. As protocols are extended the preference for presently 153 stronger algorithms presents a problem both on the question of 154 interoperability of existing and future implementations with respect 155 to standards and operational preference for the configuration as 156 deployed. This document intends to provide guidance to implementors 157 in anticipation of operational preference. 159 2. 160 Requirements Terminology 162 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 163 "MAY" that appear in this document are to be interpreted as described 164 in RFC2119. [RFC2119] 166 3. 167 Intermediate System to Intermediate System (IS-IS) 169 The IS-IS specification allows for authentication of its Protocol 170 Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. The 171 base specification had provisions only for clear text passwords. RFC 172 5304 [RFC5304] extends the authentication capabilities by providing 173 HMAC-MD5 authentication for IS-IS PDUs. 175 RFC 5310 [RFC5310] adds support for the use of SHA family of hash 176 algorithms for authenticating IS-IS PDUs. 178 3.1 179 Authentication Scheme Selection 181 In order for IS-IS implementations to interoperate, they must support 182 one or more authentication schemes in common. This section specifies 183 the preference for standards conformant IS-IS implementations, which 184 desire to utilize the security feature. 186 The earliest interoperability requirement for authentication as 187 stated by [ISO] [RFC1195] required all implementations to support 188 Clear Text Password. This authentication scheme's utility is limited 189 to precluding the accidental introduction of a new IS into a 190 broadcast domain. We believe that operators should not use this 191 scheme as provides no protection against an attacker with access to 192 the broadcast domain as anyone can determine the secret password 193 through inspection of the PDU. It MUST presently be implemented but 194 its use should be deprecated. 196 [RFC5304] defines HMAC-MD5 implementation as a MUST for 197 cryptographically authenticating the IS-IS PDUs. HMAC-MD5 is 198 currently the preferred algorithm for IS-IS deployments and it may 199 be superseded by the generic cryptographic authentication scheme 200 defined in [RFC5310]. HMAC-MD5 MUST be implemented, but its use may 201 be deprecated in future. 203 IS-IS implementations SHOULD provide support for the generic 204 cryptographic authentication scheme [RFC5310] and it is our 205 understanding that interoperability considerations will require 206 change to a MUST as operators migrate to this authentication scheme. 208 3.2 209 Authentication Algorithm Selection 211 For IS-IS implementations to interoperate, they must have support for 212 one or more authentication algorithms in common. 214 This section details the authentication algorithm requirements for 215 standards conformant IS-IS implementations. 217 HMAC-MD5 is a MUST as defined in [RFC5304]. It is our belief that 218 this will be superseded by HMAC-SHA-1 as defined in [RFC5310]. HMAC- 219 MD5 MUST be implemented, but its use may be deprecated in future. 220 Operators should consider migration to HMAC-SHA-1. 222 Implementations may start providing support for HMAC-SHA-256/HMAC- 223 SHA-384/HMAC-SHA-512 as these algorithms may be necessary in the 224 future. 226 4. Open Shortest Path First Version 2 (OSPFv2) 228 OSPFv2 as defined in [RFC2328] includes three different types of 229 authentication schemes: Null authentication, simple password and 230 cryptographic authentication. NULL authentication is semantically 231 equivalent to no authentication. In the simple password scheme of 232 authentication, the passwords are exchanged in the clear on the 233 network. Anyone with physical access to the network can learn the 234 password and compromise the security of the OSPFv2 domain. 236 In the cryptographic authentication scheme, the OSPFv2 routers on a 237 common network/subnet are configured with a shared secret which is 238 used to generate a keyed MD5 digest for each packet. A monotonically 239 increasing sequence number scheme is used to protect against replay 240 attacks. 242 RFC 5709 [RFC5709] adds support for the use of SHA family of hash 243 algorithms for authentication of OSPFv2 packets. 245 4.1 246 Authentication Scheme Selection 248 For OSPF implementations to interoperate, they must have one or more 249 authentication schemes in common. This section specifies the 250 requirements for standards conformant OSPFv2 implementations, which 251 desire to utilize the authentication feature. 253 Null Authentication is a MUST as defined in [RFC2328], its use is 254 deprecated in any context where the operator wishes to authenticate 255 the OSPFv2 packets in their network. 257 Simple Password defined as a MUST in [RFC2328] should only be used 258 when the operator is seeking only to preclude the accidental 259 introduction of a router into the domain. This scheme is not useful 260 when the operator wants to authenticate the OSPFv2 packets. 262 Cryptographic Authentication is a MUST as defined in [RFC2328] and 263 all conformant implentations MUST support this. 265 4.2 Authentication Algorithm Selection 267 For OSPFv2 implementations to interoperate, they must support one or 268 more cryptographic authentication algorithms in common. 270 Keyed MD5 as defined in [RFC2328] is a MUST. It is our belief that 271 HMAC-SHA-1 and HMAC-SHA-256 as defined in [RFC5709] will likely be 272 preferred in the future. Keyed MD5 MUST be implemented, but its use 273 may be deprecated in future. Implementations must provide support for 274 HMAC-SHA-256 as this will become the algorithm of choice. 276 Operators should consider migration to HMAC-SHA-256 if they desire a 277 stronger cryptographic algorithm for authentication of OSPFv2 278 packets. 280 Implementations may start providing support for HMAC-SHA-1/HMAC-SHA- 281 384/HMAC-SHA-512 as these algorithms may be preferred in the future. 283 5. 284 Open Shortest Path First Version 3 (OSPFv3) 286 OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH) 287 [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in 288 order to provide integrity, authentication, and/or confidentiality. 290 The algorithm requirements for AH and ESP are described in [RFC4835] 291 and are not discussed here. 293 6. 294 Routing Information Protocol Version 2 (RIPv2) 296 RIPv2, originally specified in [RFC1388], then [RFC1723], has been 297 finalized in STD56 [RFC2453]. If the Address Family Identifier of the 298 first (and only the first) entry in the message is 0xFFFF, then the 299 remainder of the entry contains the authentication. The [RFC2453] 300 version of the protocol provides for authenticating packets using a 301 simple password of not more than 16 octets, in which the password is 302 sent in clear. 304 "RIP-2 MD5 Authentication" [RFC2082] added support for Keyed-MD5 305 authentication, where a digest is appended to the end of the RIP 306 packet. "RIPv2 Cryptographic Authentication" [RFC4822] obsoleted 307 [RFC2082] and added the SHA family of hash algorithms to the list of 308 cryptographic authentications that can be used to protect RIPv2, 309 whereas [RFC2082] previously specified only the use of Keyed MD5. 311 6.1 312 Authentication Scheme Selection 314 For RIPv2 implementations to interoperate, one or more authentication 315 schemes must be supported in common. This section specifies the 316 requirements for standards conformant RIPv2 implementations, which 317 utilize the authentication feature. 319 Simple Password defined as a MUST in [RFC2453] should only be used 320 when the operator wishes to preclude the accidental introduction of a 321 RIP router into the domain. This authentication scheme is useful, but 322 not when the operator wants to protect RIPv2 message exchange in a 323 potentially hostile environment. 325 Implementations MUST provide support for Simple Password, but its 326 operational use is deprecated. 328 Keyed-MD5 as defined in [RFC2082] is a MUST. However, [RFC2082] has 329 been obsoleted by [RFC4822] Cryptographic Authentication. Compliant 330 implementations MUST provide support for Keyed-MD5 as described in 331 [RFC2082] but should recognize that this is superseded by 332 Cryptographic Authentication as defined in [RFC4822]. 334 Implementations should provide support for [RFC4822] Cryptographic 335 Authentication as it will likely be the preferred authentication 336 method in the future. 338 6.2 Authentication Algorithm Selection 340 For RIPv2 implementations to interoperate, one or more authentication 341 algorithms must be supported in common that can be used for 342 authentication. 343 The keyed MD5 algorithm in [RFC2082] and [RFC4822] must be 344 implemented. It is our belief that it will be superseded by HMAC-SHA- 345 1 also available in [RFC4822]. Keyed MD5 MUST be implemented for 346 interoperability purposes, but its use may be deprecated in future. 348 Implementations should provide support for HMAC-SHA-1 used in 349 preference to keyed MD5 the future. 351 Operators should consider migration to HMAC-SHA-1 if they want to use 352 stronger cryptographic algorithms for authenticating RIPv2 packets. 354 Implementations should consider providing support for HMAC-SHA- 355 256/HMAC-SHA-384/HMAC-SHA-512 as these algorithms may be preferred in 356 the future. 358 7. Routing Information Protocol for IPv6 (RIPng) 360 RIPng [RFC2080] relies on the IPv6 AH and IPv6 ESP to provide 361 integrity, authentication, and/or confidentiality. 363 The algorithm requirements for AH and ESP are described in [RFC4835] 364 and are not discussed here. 366 8. 367 Security Considerations 369 The cryptographic mechanisms referenced in this document provide only 370 authentication algorithms. These algorithms do not provide 371 confidentiality. Encrypting the content of the packet and thereby 372 providing confidentiality is not considered in the definition of the 373 routing protocols. 375 The cryptographic strength of the HMAC depends upon the cryptographic 376 strength of the underlying hash function and on the size and quality 377 of the key. The feasibility of attacking the integrity of routing 378 protocol messages protected by Digests may be significantly more 379 limited than that of other data, however preference for one family of 380 algorithms over another may also change independently of the 381 perceived risk to a particular protocol. 383 To ensure greater security, the keys used should be changed 384 periodically and implementations MUST be able to store and use more 385 than one key at the same time. Operational experience suggests that 386 the lack of periodic rekeying is a source of significant exposure and 387 that the lifespan of shared keys in the network is frequently 388 measured in years. 390 While simple password schemes are well represented in the document 391 series and in conformant implementations of the protocols, the 392 inability to offer either integrity or identity protection are 393 sufficient reason to strongly discourage their use. 395 This document concerns itself with the selection of cryptographic 396 algorithms for use in the authentication of routing protocol packets 397 being exchanged between adjacent routing processes. The 398 cryptographic algorithms identified in this document are not known to 399 be broken at the current time, and ongoing cryptographic research so 400 far leads us to believe that they will likely remain secure in the 401 foreseeable future. We expect that new revisions of this document 402 will be issued in the future to reflect current thinking on best 403 practice in this area. 405 9. 406 Acknowledgements 408 We would like to thank Joel Jaeggli for this comments and feedback on 409 this draft that resulted in significant improvement of the same. 411 10. IANA Considerations 413 This document places no requests to IANA. 415 11. 416 References 418 11.1 419 Normative References 421 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998 423 [ISO] "Intermediate system to Intermediate system routeing 424 information exchange protocol for use in conjunction with 425 the Protocol for providing the Connectionless-mode 426 Network Service (ISO 8473) ", ISO/IEC 10589:1992 428 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 429 dual environments", RFC 1195, December 1990. 431 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998 433 [RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic 434 Authentication", RFC 4822, February 2007 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119 439 [RFC5304] Li, T. and R. Atkinson, "Intermediate System to 440 Intermediate System (IS-IS) Cryptographic 441 Authentication", RFC 5304, October 2008 443 [RFC5340] Coltun, R., et. al, "OSPF for IPv6", RFC 5340, July 444 2008. 446 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 447 Requirements for Encapsulating Security Payload (ESP) and 448 Authentication Header (AH)", RFC 4835, April 2007 450 [RFC2080] Malkin, G. and Minnear, R., "RIPng for IPv6", RFC 2080, 451 January 1997 453 [RFC5310] Bhatia, M., et. al., "IS-IS Generic 454 Cryptographic Authentication", RFC 5310, February 2009 456 [RFC5709] Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA 457 Cryptographic Authentication", RFC 5709, October 2009 459 11.2 460 Informative References 462 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 463 1321, April 1992 465 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 466 2005. 468 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 469 4303, December 2005. 471 [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional 472 Information", RFC 1388, January 1993. 474 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 475 Information", STD 56, RFC 1723, November 1994. 477 [RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5 478 Authentication", RFC 2082, January 1997 480 Author's Addresses 482 Manav Bhatia 483 Alcatel-Lucent 484 Bangalore, India 485 Email: manav@alcatel-lucent.com 487 Vishwas Manral 488 IP Infusion 489 Almora, Uttarakhand 490 India 491 Email: vishwas@ipinfusion.com