idnits 2.17.1 draft-ietf-isis-rfc3567bis-02.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 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 446. 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 1, 2008) is 5776 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 1, 2008 7 Expires: January 2, 2009 9 Intermediate System to Intermediate System (IS-IS) Cryptographic 10 Authentication 11 draft-ietf-isis-rfc3567bis-02 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 2, 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 . . . . . . . . . . . . . . 5 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 3.1. Security Limitations . . . . . . . . . . . . . . . . . . . 5 62 3.2. Assurance . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 6 64 3.4. Future Directions . . . . . . . . . . . . . . . . . . . . 7 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 11 73 1. Introduction 75 The IS-IS protocol, as specified in [ISO-10589], provides for the 76 authentication of Link State PDUs (LSPs) through the inclusion of 77 authentication information as part of the LSP. This authentication 78 information is encoded as a Type-Length-Value (TLV) tuple. The use 79 of IS-IS for IPv4 networks is described in [RFC1195]. 81 The type of the TLV is specified as 10. The length of the TLV is 82 variable. The value of the TLV depends on the authentication 83 algorithm and related secrets being used. The first octet of the 84 value is used to specify the authentication type. Type 0 is 85 reserved, type 1 indicates a cleartext password, and type 255 is used 86 for routing domain private authentication methods. The remainder of 87 the TLV value is known as the Authentication Value. 89 This document extends the above situation by allocating a new 90 authentication type for HMAC-MD5 and specifying the algorithms for 91 the computation of the Authentication Value. This document also 92 describes modifications to the base protocol to ensure that the 93 authentication mechanisms described in this document are effective. 95 This document is a publication of the IS-IS Working Group within the 96 IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual 97 inclusion with ISO 10589. This document replaces [RFC3567], which 98 was an Informational RFC. This document is on the standards track. 99 This document has revised Section 3, with the significant addition of 100 a discussion of recent attacks on MD5 in Section 3.2. This document 101 has also added a substantive 'IANA Considerations' section to create 102 a missing code 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. 169 Immediately after password rollover on the router, the router or IS- 170 IS process may restart. If this happens, this causes the LSP 171 Sequence Number to restart from the value 1 using the new password. 172 However, neighbors will reject those new LSPs because the Sequence 173 Number is smaller. The router can not increase its own LSP Sequence 174 Number because it fails to authenticate its own old LSP that 175 neighbors keep sending to it. So the router can not update its LSP 176 Sequence Number to its neighbors until all the neighbors time out all 177 of the original LSPs. One possible solution to this problem is for 178 the IS-IS process to detect if any inbound LSP with an authentication 179 failure has the local System ID and also has a higher Sequence Number 180 than the IS-IS process has. In this event, the IS-IS process SHOULD 181 increase its own LSP Sequence Number accordingly and re-flood the 182 LSPs. However, as this scenario could also be triggered by an active 183 attack by an adversary, it is recommended that a counter also be kept 184 on this case to mitigate the risk from such an active attack. 186 3. Security Considerations 188 This document enhances the security of the IS-IS routing protocol. 189 Because a routing protocol contains information that need not be kept 190 secret, privacy is not a requirement. However, authentication of the 191 messages within the protocol is of interest, to reduce the risk of an 192 adversary compromising the routing system by deliberately injecting 193 false information into the routing system. 195 3.1. Security Limitations 197 The technology in this document provides an authentication mechanism 198 for IS-IS. The mechanism described here is not perfect and does not 199 need to be perfect. Instead, this mechanism represents a significant 200 increase in the work function of an adversary attacking the IS-IS 201 protocol, while not causing undue implementation, deployment, or 202 operational complexity. It is believed secure against passive 203 attacks, as defined in [RFC1704], unlike cleartext password 204 authentication. 206 This mechanism does not prevent replay attacks; however, in most 207 cases, such attacks would trigger existing mechanisms in the IS-IS 208 protocol that would effectively reject old information. Denial of 209 service attacks are not generally preventable in a useful networking 210 protocol [DoS]. 212 3.2. Assurance 214 Users need to understand that the quality of the security provided by 215 this mechanism depends completely on the strength of the implemented 216 authentication algorithms, the strength of the key being used, and 217 the correct implementation of the security mechanism in all 218 communicating IS-IS implementations. This mechanism also depends on 219 the IS-IS Authentication Key being kept confidential by all parties. 220 If any of these are incorrect or insufficiently secure, then no real 221 security will be provided to the users of this mechanism. 223 Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were 224 first published a dozen years ago, there have been growing concerns 225 about the effectiveness of the compression function within MD5. More 226 recent work by Wang and Yu [WY05] accentuates these concerns. 227 However, despite these research results, there are no published 228 attacks at present on either Keyed-MD5 or HMAC-MD5. A recent paper 229 by Bellare [Bell06a] [Bell06b] provides new proofs for the security 230 of HMAC that require fewer assumptions than previous published proofs 231 for HMAC. Those proofs indicate that the published issues with MD5 232 (and separately with SHA-1) do not create an attack on HMAC-MD5 (or 233 HMAC SHA-1). Most recently, Fouque and others [FLN07] have published 234 new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5. However, their 235 attacks are non-trivial computationally and they have not found an 236 equivalent attack on HMAC-MD5. So, despite the published issues with 237 the MD5 algorithm, there is no currently published attack that 238 applies to HMAC-MD5 as used in this IS-IS specification. As with any 239 cryptographic technique, there is the possibility of the discovery of 240 future attacks against this mechanism. 242 3.3. Other Considerations 244 Changes to the authentication mechanism described here (primarily: to 245 add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at 246 some length, but ultimately were rejected. The mechanism here was 247 already widely implemented in 1999. As of this writing, this 248 mechanism is fairly widely deployed within the users interested in 249 cryptographic authentication of IS-IS. The improvement provided by 250 the proposed revised mechanism was not large tnough to justify the 251 change, given the installed base and lack of operator interest in 252 deploying a revised mechanism. 254 If and when a key management protocol appears that is both widely 255 implemented and easily deployed to secure routing protocols such as 256 IS-IS, a different authentication mechanism that is designed for use 257 with that key management schema could be added if desired. 259 3.4. Future Directions 261 If a stronger authentication were believed to be required, then the 262 use of a full digital signature [RFC2154] would be an approach that 263 should be seriously considered. It was rejected for this purpose at 264 this time because the computational burden of full digital signatures 265 is believed to be much higher than is reasonable given the current 266 threat environment in operational commercial networks. 268 4. Acknowledgements 270 The authors would like to thank (in alphabetical order) Stephen 271 Farrell, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, and 272 Henk Smit for their comments and suggestions on this document. 274 5. IANA Considerations 276 This document requests that IANA create a new code point registry to 277 administer the Authentication Type code points for TLV 10. This 278 registry would be part of the existing IS-IS code points registry as 279 established by [RFC3563] and [RFC3359]. This registry should be 280 managed using the Designated Expert policy as described in [RFC5226] 281 and will be called IS-IS Authentication Type Codes. 283 The values in the IS-IS Authentication Type Codes registry should be 284 recorded in decimal and should only be approved after a designated 285 expert, appointed by the IESG area director, has been consulted. The 286 intention is that any allocation will be accompanied by a published 287 RFC. However, the Designated Expert can approve allocations once it 288 seems clear that an RFC will be published, allowing for the 289 allocation of values prior to the document being approved for 290 publication as an RFC. New items should be documented in a publicly 291 and freely available specification. We should also have the 292 provision of allowing external specifications to allocate and use the 293 IS-IS Authentication Type Codes maintained by this registry. 295 Initial values for the IS-IS Authentication Type Codes registry are 296 given below; future assignments are to be made through Expert Review. 297 Assignments consist of an authentication type name and its associated 298 value. 300 +---------------------------------------------+-------+-------------+ 301 | Authentication Type Code | Value | Reference | 302 +---------------------------------------------+-------+-------------+ 303 | Reserved | 0 | [ISO-10589] | 304 | Cleartext Password | 1 | [ISO-10589] | 305 | ISO 10589 Reserved | 2 | [ISO-10589] | 306 | HMAC-MD5 Authentication | 54 | [RFC3567] | 307 | Routeing Domain private authentication | 255 | [ISO-10589] | 308 | method | | | 309 +---------------------------------------------+-------+-------------+ 311 6. References 313 6.1. Normative References 315 [ISO-10589] 316 ISO, "Intermediate System to Intermediate System Intra- 317 Domain Routeing Exchange Protocol for use in Conjunction 318 with the Protocol for Providing the Connectionless-mode 319 Network Service (ISO 8473)", International Standard 10589: 320 2002, Second Edition, 2002. 322 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 323 Hashing for Message Authentication", RFC 2104, 324 February 1997. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 6.2. Informative References 331 [Bell06a] Bellare, M., "New Proofs for NMAC and HMAC: Security 332 without Collision-Resistance", Preliminary Version, in 333 Proceedings of Crypto 2006, Lecture Notes in Computer 334 Science Vol. 4117, August 2006. 336 [Bell06b] Bellare, M., "New Proofs for NMAC and HMAC: Security 337 without Collision-Resistance", August 2006, 338 . 341 [DoS] Voydock, V. and S. Kent, "Security Mechanisms in High- 342 level Networks", ACM Computing Surveys Vol. 15, No. 2, 343 June 1983. 345 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", EuroCrypt 346 Rump Session 1996, May 1996. 348 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 349 CryptoBytes Vol. 2, No. 2, 1996. 351 [Dobb98] Dobbertin, H., "Cryptanalysis of MD4", Journal of 352 Cryptology Vol. 11, No. 4, 1998. 354 [FLN07] Fouque, P., Leurent, G., and P. Nguyen, "Full Key-Recovery 355 Attacks on HMAC/NMAC-MD5 and NMAC-MD5", Proceedings of 356 Crypto 2007, August 2007. 358 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 359 dual environments", RFC 1195, December 1990. 361 [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", 362 RFC 1704, October 1994. 364 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 365 Digital Signatures", RFC 2154, June 1997. 367 [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 368 Codepoints in Intermediate System to Intermediate System", 369 RFC 3359, August 2002. 371 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 372 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 373 (JTC1/SC6) on IS-IS Routing Protocol Development", 374 RFC 3563, July 2003. 376 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 377 Intermediate System (IS-IS) Cryptographic Authentication", 378 RFC 3567, July 2003. 380 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 381 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 382 May 2008. 384 [WY05] Wang, X. and H. Yu, "How to Break MD5 and Other Hash 385 Functions", Proceedings of EuroCrypt 2005, Lecture Notes 386 in Computer Science Vol. 3494, 2005. 388 Authors' Addresses 390 Tony Li 391 Redback Networks, Inc. 392 300 Holger Way 393 San Jose, CA 95134 394 USA 396 Phone: +1 408 750 5160 397 Email: tony.li@tony.li 399 Ran J. Atkinson 400 Extreme Networks, Inc. 401 3585 Monroe St. 402 Santa Clara, CA 95051 403 USA 405 Phone: +1 408 579 2800 406 Email: rja@extremenetworks.com 408 Full Copyright Statement 410 Copyright (C) The IETF Trust (2008). 412 This document is subject to the rights, licenses and restrictions 413 contained in BCP 78, and except as set forth therein, the authors 414 retain all their rights. 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 419 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 420 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 421 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 Intellectual Property 426 The IETF takes no position regarding the validity or scope of any 427 Intellectual Property Rights or other rights that might be claimed to 428 pertain to the implementation or use of the technology described in 429 this document or the extent to which any license under such rights 430 might or might not be available; nor does it represent that it has 431 made any independent effort to identify any such rights. Information 432 on the procedures with respect to rights in RFC documents can be 433 found in BCP 78 and BCP 79. 435 Copies of IPR disclosures made to the IETF Secretariat and any 436 assurances of licenses to be made available, or the result of an 437 attempt made to obtain a general license or permission for the use of 438 such proprietary rights by implementers or users of this 439 specification can be obtained from the IETF on-line IPR repository at 440 http://www.ietf.org/ipr. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary 444 rights that may cover technology that may be required to implement 445 this standard. Please address the information to the IETF at 446 ietf-ipr@ietf.org.