idnits 2.17.1 draft-ietf-isis-rfc3567bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. 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 draft header indicates that this document updates RFC1195, but the abstract doesn't seem to directly say this. It does mention RFC1195 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC1195, updated by this document, for RFC5378 checks: 1990-12-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5727 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10589' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Obsolete informational reference (is this intentional?): RFC 3567 (Obsoleted by RFC 5304) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets T. Li 3 Internet-Draft Redback Networks, Inc. 4 Obsoletes: 3567 (if approved) R. Atkinson 5 Updates: 1195 (if approved) Extreme Networks, Inc. 6 Intended status: Standards Track July 14, 2008 7 Expires: January 15, 2009 9 Intermediate System to Intermediate System (IS-IS) Cryptographic 10 Authentication 11 draft-ietf-isis-rfc3567bis-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 15, 2009. 38 Abstract 40 This document describes the authentication of Intermediate System to 41 Intermediate System (IS-IS) Protocol Data Units (PDUs) using the 42 Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) 43 algorithm as found in RFC 2104. IS-IS is specified in International 44 Standards Organization (ISO) 10589, with extensions to support 45 Internet Protocol version 4 (IPv4) described in RFC 1195. The base 46 specification includes an authentication mechanism that allows for 47 multiple authentication algorithms. The base specification only 48 specifies the algorithm for cleartext passwords. This document 49 replaces RFC 3567. 51 This document proposes an extension to that specification that allows 52 the use of the HMAC-MD5 authentication algorithm to be used in 53 conjunction with the existing authentication mechanisms. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Authentication Procedures . . . . . . . . . . . . . . . . . . 3 59 2.1. Implementation Considerations . . . . . . . . . . . . . . 4 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 3.1. Security Limitations . . . . . . . . . . . . . . . . . . . 5 62 3.2. Assurance . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Key Configuration . . . . . . . . . . . . . . . . . . . . 6 64 3.4. Other Considerations . . . . . . . . . . . . . . . . . . . 6 65 3.5. Future Directions . . . . . . . . . . . . . . . . . . . . 7 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . . . 11 74 1. Introduction 76 The IS-IS protocol, as specified in [ISO-10589], provides for the 77 authentication of Link State PDUs (LSPs) through the inclusion of 78 authentication information as part of the LSP. This authentication 79 information is encoded as a Type-Length-Value (TLV) tuple. The use 80 of IS-IS for IPv4 networks is described in [RFC1195]. 82 The type of the TLV is specified as 10. The length of the TLV is 83 variable. The value of the TLV depends on the authentication 84 algorithm and related secrets being used. The first octet of the 85 value is used to specify the authentication type. Type 0 is 86 reserved, type 1 indicates a cleartext password, and type 255 is used 87 for routing domain private authentication methods. The remainder of 88 the TLV value is known as the Authentication Value. 90 This document extends the above situation by allocating a new 91 authentication type for HMAC-MD5 and specifying the algorithms for 92 the computation of the Authentication Value. This document also 93 describes modifications to the base protocol to ensure that the 94 authentication mechanisms described in this document are effective. 96 This document is a publication of the IS-IS Working Group within the 97 IETF. This document replaces [RFC3567], which was an Informational 98 RFC. This document is on the standards track. This document has 99 revised Section 3, with the significant addition of a discussion of 100 recent attacks on MD5 in Section 3.2. This document has also added a 101 substantive 'IANA Considerations' section to create a missing code 102 point registry. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Authentication Procedures 110 The authentication type used for HMAC-MD5 is 54 (0x36). The length 111 of the Authentication Value for HMAC-MD5 is 16, and the length field 112 in the TLV is 17. 114 The HMAC-MD5 algorithm requires a key K and text T as input 115 [RFC2104]. The key K is the password for the PDU type, as specified 116 in ISO 10589. The text T is the IS-IS PDU to be authenticated with 117 the Authentication Value field inside of the Authentication 118 Information TLV set to zero. Note that the Authentication Type is 119 set to 54 and the length of the TLV is set to 17 before 120 authentication is computed. When LSPs are authenticated, the 121 Checksum and Remaining Lifetime fields are set to zero (0) before 122 authentication is computed. The result of the algorithm is placed in 123 the Authentication Value field. 125 When calculating the HMAC-MD5 result for Sequence Number PDUs, Level 126 1 Sequence Number PDUs SHALL use the Area Authentication string as in 127 Level 1 Link State PDUs. Level 2 Sequence Number PDUs SHALL use the 128 domain authentication string as in Level 2 Link State PDUs. IS-IS 129 HELLO PDUs SHALL use the Link Level Authentication String, which MAY 130 be different from that of Link State PDUs. The HMAC-MD5 result for 131 the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded 132 to the MTU size, if padding is not disabled. Implementations that 133 support the optional checksum for the Sequence Number PDUs and IS-IS 134 HELLO PDUs MUST NOT include the Checksum TLV. 136 To authenticate an incoming PDU, a system should save the values of 137 the Authentication Value field, the Checksum and the Remaining 138 Lifetime field, set these fields to zero, compute authentication, and 139 then restore the values of these fields. 141 An implementation that implements HMAC-MD5 authentication and 142 receives HMAC-MD5 Authentication Information MUST discard the PDU if 143 the Authentication Value is incorrect. 145 An implementation MAY have a transition mode where it includes HMAC- 146 MD5 Authentication Information in PDUs but does not verify the HMAC- 147 MD5 authentication information. This is a transition aid for 148 networks in the process of deploying authentication. 150 An implementation MAY check a set of passwords when verifying the 151 Authentication Value. This provides a mechanism for incrementally 152 changing passwords in a network. 154 An implementation that does not implement HMAC-MD5 authentication MAY 155 accept a PDU that contains the HMAC-MD5 Authentication Type. ISes 156 (routers) that implement HMAC-MD5 authentication and initiate LSP 157 purges MUST remove the body of the LSP and add the authentication 158 TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept 159 unauthenticated purges. ISes MUST NOT accept purges that contain 160 TLVs other than the authentication TLV. These restrictions are 161 necessary to prevent a hostile system from receiving an LSP, setting 162 the Remaining Lifetime field to zero, and flooding it, thereby 163 initiating a purge without knowing the authentication password. 165 2.1. Implementation Considerations 167 There is an implementation issue just after password rollover on an 168 IS-IS router that might benefit from additional commentary. 170 Immediately after password rollover on the router, the router or IS- 171 IS process may restart. If this happens, this causes the LSP 172 Sequence Number to restart from the value 1 using the new password. 173 However, neighbors will reject those new LSPs because the Sequence 174 Number is smaller. The router can not increase its own LSP Sequence 175 Number because it fails to authenticate its own old LSP that 176 neighbors keep sending to it. So the router can not update its LSP 177 Sequence Number to its neighbors until all the neighbors time out all 178 of the original LSPs. One possible solution to this problem is for 179 the IS-IS process to detect if any inbound LSP with an authentication 180 failure has the local System ID and also has a higher Sequence Number 181 than the IS-IS process has. In this event, the IS-IS process SHOULD 182 increase its own LSP Sequence Number accordingly and re-flood the 183 LSPs. However, as this scenario could also be triggered by an active 184 attack by an adversary, it is recommended that a counter also be kept 185 on this case to mitigate the risk from such an active attack. 187 3. Security Considerations 189 This document enhances the security of the IS-IS routing protocol. 190 Because a routing protocol contains information that need not be kept 191 secret, privacy is not a requirement. However, authentication of the 192 messages within the protocol is of interest, to reduce the risk of an 193 adversary compromising the routing system by deliberately injecting 194 false information into the routing system. 196 3.1. Security Limitations 198 The technology in this document provides an authentication mechanism 199 for IS-IS. The mechanism described here is not perfect and does not 200 need to be perfect. Instead, this mechanism represents a significant 201 increase in the work function of an adversary attacking the IS-IS 202 protocol, while not causing undue implementation, deployment, or 203 operational complexity. It provides improved security against 204 passive attacks, as defined in [RFC1704], when compared to cleartext 205 password authentication. 207 This mechanism does not prevent replay attacks; however, in most 208 cases, such attacks would trigger existing mechanisms in the IS-IS 209 protocol that would effectively reject old information. Denial of 210 service attacks are not generally preventable in a useful networking 211 protocol [DoS]. 213 The mechanisms in this document do not provide protection against 214 compromised, malfunctioning, or misconfigured routers. Such routers 215 can, either accidentally or deliberately, cause malfunctions 216 affecting the whole routing domain. The reader is encouraged to 217 consult [RFC4593] for a more comprehensive description of threats to 218 routing protocols. 220 3.2. Assurance 222 Users need to understand that the quality of the security provided by 223 this mechanism depends completely on the strength of the implemented 224 authentication algorithms, the strength of the key being used, and 225 the correct implementation of the security mechanism in all 226 communicating IS-IS implementations. This mechanism also depends on 227 the IS-IS Authentication Key being kept confidential by all parties. 228 If any of these are incorrect or insufficiently secure, then no real 229 security will be provided to the users of this mechanism. 231 Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were 232 first published a dozen years ago, there have been growing concerns 233 about the effectiveness of the compression function within MD5. More 234 recent work by Wang and Yu [WY05] accentuates these concerns. 235 However, despite these research results, there are no published 236 attacks at present on either Keyed-MD5 or HMAC-MD5. A recent paper 237 by Bellare [Bell06a] [Bell06b] provides new proofs for the security 238 of HMAC that require fewer assumptions than previous published proofs 239 for HMAC. Those proofs indicate that the published issues with MD5 240 (and separately with SHA-1) do not create an attack on HMAC-MD5 (or 241 HMAC SHA-1). Most recently, Fouque and others [FLN07] have published 242 new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5. However, their 243 attacks are non-trivial computationally and they have not found an 244 equivalent attack on HMAC-MD5. So, despite the published issues with 245 the MD5 algorithm, there is no currently published attack that 246 applies to HMAC-MD5 as used in this IS-IS specification. As with any 247 cryptographic technique, there is the possibility of the discovery of 248 future attacks against this mechanism. 250 3.3. Key Configuration 252 It should be noted that the key configuration mechanism of routers 253 may restrict the possible keys that may be used between peers. It is 254 strongly recommended that an implementation be able to support at 255 minimum a key composed of a string of printable ASCII of 80 bytes or 256 less, as this is current practice. 258 3.4. Other Considerations 260 Changes to the authentication mechanism described here (primarily: to 261 add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at 262 some length, but ultimately were rejected. The mechanism here was 263 already widely implemented in 1999. As of this writing, this 264 mechanism is fairly widely deployed within the users interested in 265 cryptographic authentication of IS-IS. The improvement provided by 266 the proposed revised mechanism was not large tnough to justify the 267 change, given the installed base and lack of operator interest in 268 deploying a revised mechanism. 270 If and when a key management protocol appears that is both widely 271 implemented and easily deployed to secure routing protocols such as 272 IS-IS, a different authentication mechanism that is designed for use 273 with that key management schema could be added if desired. 275 3.5. Future Directions 277 If a stronger authentication were believed to be required, then the 278 use of a full digital signature [RFC2154] would be an approach that 279 should be seriously considered. It was rejected for this purpose at 280 this time because the computational burden of full digital signatures 281 is believed to be much higher than is reasonable given the current 282 threat environment in operational commercial networks. 284 If and when additional authentication mechanisms are defined, for 285 example to provide a cryptographically stronger hash function, it 286 will also be necessary to define mechanisms to allow graceful 287 transition from the existing mechanisms (as defined in this document) 288 to any future mechanism. 290 4. Acknowledgements 292 The authors would like to thank (in alphabetical order) Stephen 293 Farrell, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, and 294 Henk Smit for their comments and suggestions on this document. 296 5. IANA Considerations 298 This document requests that IANA create a new code point registry to 299 administer the Authentication Type code points for TLV 10. This 300 registry would be part of the existing IS-IS code points registry as 301 established by [RFC3563] and [RFC3359]. This registry should be 302 managed using the Designated Expert policy as described in [RFC5226] 303 and will be called IS-IS Authentication Type Codes. 305 The values in the IS-IS Authentication Type Codes registry should be 306 recorded in decimal and should only be approved after a designated 307 expert, appointed by the IESG area director, has been consulted. The 308 intention is that any allocation will be accompanied by a published 309 RFC. However, the Designated Expert can approve allocations once it 310 seems clear that an RFC will be published, allowing for the 311 allocation of values prior to the document being approved for 312 publication as an RFC. New items should be documented in a publicly 313 and freely available specification. We should also have the 314 provision of allowing external specifications to allocate and use the 315 IS-IS Authentication Type Codes maintained by this registry. 317 Initial values for the IS-IS Authentication Type Codes registry are 318 given below; future assignments are to be made through Expert Review. 319 Assignments consist of an authentication type name and its associated 320 value. 322 +---------------------------------------------+-------+-------------+ 323 | Authentication Type Code | Value | Reference | 324 +---------------------------------------------+-------+-------------+ 325 | Reserved | 0 | [ISO-10589] | 326 | Cleartext Password | 1 | [ISO-10589] | 327 | ISO 10589 Reserved | 2 | [ISO-10589] | 328 | HMAC-MD5 Authentication | 54 | | 329 | Routeing Domain private authentication | 255 | [ISO-10589] | 330 | method | | | 331 +---------------------------------------------+-------+-------------+ 333 6. References 335 6.1. Normative References 337 [ISO-10589] 338 ISO, "Intermediate System to Intermediate System Intra- 339 Domain Routeing Exchange Protocol for use in Conjunction 340 with the Protocol for Providing the Connectionless-mode 341 Network Service (ISO 8473)", International Standard 10589: 342 2002, Second Edition, 2002. 344 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 345 Hashing for Message Authentication", RFC 2104, 346 February 1997. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 6.2. Informative References 353 [Bell06a] Bellare, M., "New Proofs for NMAC and HMAC: Security 354 without Collision-Resistance", Preliminary Version, in 355 Proceedings of Crypto 2006, Lecture Notes in Computer 356 Science Vol. 4117, August 2006. 358 [Bell06b] Bellare, M., "New Proofs for NMAC and HMAC: Security 359 without Collision-Resistance", August 2006, 360 . 363 [DoS] Voydock, V. and S. Kent, "Security Mechanisms in High- 364 level Networks", ACM Computing Surveys Vol. 15, No. 2, 365 June 1983. 367 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", EuroCrypt 368 Rump Session 1996, May 1996. 370 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 371 CryptoBytes Vol. 2, No. 2, 1996. 373 [Dobb98] Dobbertin, H., "Cryptanalysis of MD4", Journal of 374 Cryptology Vol. 11, No. 4, 1998. 376 [FLN07] Fouque, P., Leurent, G., and P. Nguyen, "Full Key-Recovery 377 Attacks on HMAC/NMAC-MD5 and NMAC-MD5", Proceedings of 378 Crypto 2007, August 2007. 380 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 381 dual environments", RFC 1195, December 1990. 383 [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", 384 RFC 1704, October 1994. 386 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 387 Digital Signatures", RFC 2154, June 1997. 389 [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 390 Codepoints in Intermediate System to Intermediate System", 391 RFC 3359, August 2002. 393 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 394 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 395 (JTC1/SC6) on IS-IS Routing Protocol Development", 396 RFC 3563, July 2003. 398 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 399 Intermediate System (IS-IS) Cryptographic Authentication", 400 RFC 3567, July 2003. 402 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 403 Routing Protocols", RFC 4593, October 2006. 405 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 406 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 407 May 2008. 409 [WY05] Wang, X. and H. Yu, "How to Break MD5 and Other Hash 410 Functions", Proceedings of EuroCrypt 2005, Lecture Notes 411 in Computer Science Vol. 3494, 2005. 413 Authors' Addresses 415 Tony Li 416 Redback Networks, Inc. 417 300 Holger Way 418 San Jose, CA 95134 419 USA 421 Phone: +1 408 750 5160 422 Email: tony.li@tony.li 424 Ran J. Atkinson 425 Extreme Networks, Inc. 426 3585 Monroe St. 427 Santa Clara, CA 95051 428 USA 430 Phone: +1 408 579 2800 431 Email: rja@extremenetworks.com 433 Full Copyright Statement 435 Copyright (C) The IETF Trust (2008). 437 This document is subject to the rights, licenses and restrictions 438 contained in BCP 78, and except as set forth therein, the authors 439 retain all their rights. 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 444 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 445 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 446 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Intellectual Property 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at 471 ietf-ipr@ietf.org.