idnits 2.17.1 draft-ietf-isis-rfc3567bis-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. 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 Copyright Line does not match the current year -- 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 (January 16, 2008) is 5938 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 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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 Cisco Systems, Inc. 4 Intended status: Standards Track R. Atkinson 5 Expires: July 19, 2008 Extreme Networks, Inc. 6 January 16, 2008 8 Intermediate System to Intermediate System (IS-IS) Cryptographic 9 Authentication 10 draft-ietf-isis-rfc3567bis-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes the authentication of Intermediate System to 44 Intermediate System (IS-IS) Protocol Data Units (PDUs) using the 45 Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) 46 algorithm as found in RFC 2104. IS-IS is specified in International 47 Standards Organization (ISO) 10589, with extensions to support 48 Internet Protocol version 4 (IPv4) described in RFC 1195. The base 49 specification includes an authentication mechanism that allows for 50 multiple authentication algorithms. The base specification only 51 specifies the algorithm for cleartext passwords. 53 This document proposes an extension to that specification that allows 54 the use of the HMAC-MD5 authentication algorithm to be used in 55 conjunction with the existing authentication mechanisms. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Authentication Procedures . . . . . . . . . . . . . . . . . . . 3 61 2.1. Implementation Considerations . . . . . . . . . . . . . . . 4 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Security Limitations . . . . . . . . . . . . . . . . . . . 5 64 3.2. Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 6 66 3.4. Future Directions . . . . . . . . . . . . . . . . . . . . . 6 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Intellectual Property and Copyright Statements . . . . . . . . . . 9 75 1. Introduction 77 The IS-IS protocol, as specified in [ISO-10589], provides for the 78 authentication of Link State PDUs (LSPs) through the inclusion of 79 authentication information as part of the LSP. This authentication 80 information is encoded as a Type-Length-Value (TLV) tuple. The use 81 of IS-IS for IPv4 networks is described in [RFC1195]. 83 The type of the TLV is specified as 10. The length of the TLV is 84 variable. The value of the TLV depends on the authentication 85 algorithm and related secrets being used. The first octet of the 86 value is used to specify the authentication type. Type 0 is 87 reserved, type 1 indicates a cleartext password, and type 255 is used 88 for routing domain private authentication methods. The remainder of 89 the TLV value is known as the Authentication Value. 91 This document extends the above situation by allocating a new 92 authentication type for HMAC-MD5 and specifying the algorithms for 93 the computation of the Authentication Value. This document also 94 describes modifications to the base protocol to ensure that the 95 authentication mechanisms described in this document are effective. 97 This document is a publication of the IS-IS Working Group within the 98 IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual 99 inclusion with ISO 10589. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Authentication Procedures 107 The authentication type used for HMAC-MD5 is 54 (0x36). The length 108 of the Authentication Value for HMAC-MD5 is 16, and the length field 109 in the TLV is 17. 111 The HMAC-MD5 algorithm requires a key K and text T as input 112 [RFC2104]. The key K is the password for the PDU type, as specified 113 in ISO 10589. The text T is the IS-IS PDU to be authenticated with 114 the Authentication Value field inside of the Authentication 115 Information TLV set to zero. Note that the Authentication Type is 116 set to 54 and the length of the TLV is set to 17 before 117 authentication is computed. When LSPs are authenticated, the 118 Checksum and Remaining Lifetime fields are set to zero (0) before 119 authentication is computed. The result of the algorithm is placed in 120 the Authentication Value field. 122 When calculating the HMAC-MD5 result for Sequence Number PDUs, Level 123 1 Sequence Number PDUs SHALL use the Area Authentication string as in 124 Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the 125 domain authentication string as in Level 2 Link State PDUs. IS-IS 126 HELLO PDUs SHALL use the Link Level Authentication String, which MAY 127 be different from that of Link State PDUs. The HMAC-MD5 result for 128 the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded 129 to the MTU size, if padding is not disabled. Implementations that 130 support the optional checksum for the Sequence Number PDUs and IS-IS 131 HELLO PDUs MUST NOT include the Checksum TLV. 133 To authenticate an incoming PDU, a system should save the values of 134 the Authentication Value field, the Checksum and the Remaining 135 Lifetime field, set these fields to zero, compute authentication, and 136 then restore the values of these fields. 138 An implementation that implements HMAC-MD5 authentication and 139 receives HMAC-MD5 Authentication Information MUST discard the PDU if 140 the Authentication Value is incorrect. 142 An implementation MAY have a transition mode where it includes HMAC- 143 MD5 Authentication Information in PDUs but does not verify the HMAC- 144 MD5 authentication information. This is a transition aid for 145 networks in the process of deploying authentication. 147 An implementation MAY check a set of passwords when verifying the 148 Authentication Value. This provides a mechanism for incrementally 149 changing passwords in a network. 151 An implementation that does not implement HMAC-MD5 authentication MAY 152 accept a PDU that contains the HMAC-MD5 Authentication Type. ISes 153 (routers) that implement HMAC-MD5 authentication and initiate LSP 154 purges MUST remove the body of the LSP and add the authentication 155 TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept 156 unauthenticated purges. ISes MUST NOT accept purges that contain 157 TLVs other than the authentication TLV. These restrictions are 158 necessary to prevent a hostile system from receiving an LSP, setting 159 the Remaining Lifetime field to zero, and flooding it, thereby 160 initiating a purge without knowing the authentication password. 162 2.1. Implementation Considerations 164 There is an implementation issue just after password rollover on an 165 IS-IS router that might benefit from additional commentary. 166 Immediately after password rollover on the router, the router or IS- 167 IS process may restart. If this happens, this causes the LSP 168 Sequence Number restarts from the value 1 using the new password. 169 However, neighbors will reject those new LSPs because the Sequence 170 Number is smaller. The router can not increase its own LSP Sequence 171 Number because it fails to authenticate its own old LSP that 172 neighbors keep sending to it. So the router can not update its LSP 173 Sequence Number to its neighbors until all the neighbors time out all 174 of the original LSPs. One possible solution to this problem is for 175 the IS-IS process to detect if any inbound LSP with an authentication 176 failure has the local System ID and also has a higher Sequence Number 177 than the IS-IS process has. In this event, the IS-IS process SHOULD 178 increase its own LSP Sequence Number accordingly and re-flood the 179 LSPs. However, as this scenario could also be triggered by an active 180 attack by an adversary, it is recommended that a counter also be kept 181 on this case to mitigate the risk from such an active attack. 183 3. Security Considerations 185 This document enhances the security of the IS-IS routing protocol. 186 Because a routing protocol contains information that need not be kept 187 secret, privacy is not a requirement. However, authentication of the 188 messages within the protocol is of interest, to reduce the risk of an 189 adversary compromising the routing system by deliberately injecting 190 false information into the routing system. 192 3.1. Security Limitations 194 The technology in this document provides an authentication mechanism 195 for IS-IS. The mechanism described here is not perfect and does not 196 need to be perfect. Instead, this mechanism represents a significant 197 increase in the work function of an adversary attacking the IS-IS 198 protocol, while not causing undue implementation, deployment, or 199 operational complexity. It is believed secure against passive 200 attacks, as defined in [RFC1704], unlike cleartext password 201 authentication. 203 This mechanism does not prevent replay attacks; however, in most 204 cases, such attacks would trigger existing mechanisms in the IS-IS 205 protocol that would effectively reject old information. Denial of 206 service attacks are not generally preventable in a useful networking 207 protocol [DoS]. 209 3.2. Assurance 211 Users need to understand that the quality of the security provided by 212 this mechanism depends completely on the strength of the implemented 213 authentication algorithms, the strength of the key being used, and 214 the correct implementation of the security mechanism in all 215 communicating IS-IS implementations. This mechanism also depends on 216 the IS-IS Authentication Key being kept confidential by all parties. 218 If any of these are incorrect or insufficiently secure, then no real 219 security will be provided to the users of this mechanism. 221 Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were 222 first published a dozen years ago, there have been growing concerns 223 about the effectiveness of the compression function within MD5. More 224 recent work by Wang and Yu [WY05] accentuates these concerns. 225 However, despite these research results, there are no published 226 attacks at present on either Keyed-MD5 or HMAC-MD5. A recent paper 227 by Bellare [Bell06a] [Bell06b] provides new proofs for the security 228 of HMAC that require fewer assumptions than previous published proofs 229 for HMAC. Those proofs indicate that the published issues with MD5 230 (and separately with SHA-1) do not create an attack on HMAC-MD5 (or 231 HMAC SHA-1). Most recently, Fouque and others [FLN07] have published 232 new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5. However, their 233 attacks are non-trivial computationally and they have not found an 234 equivalent attack on HMAC-MD5. So, despite the published issues with 235 the MD5 algorithm, there is no currently published attack that 236 applies to HMAC-MD5 as used in this IS-IS specification. As with any 237 cryptographic technique, there is the possibility of the discovery of 238 future attacks against this mechanism. 240 3.3. Other Considerations 242 Changes to the authentication mechanism described here (primarily: to 243 add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at 244 some length, but ultimately were rejected. The mechanism here was 245 already widely implemented in 1999. As of this writing, this 246 mechanism is fairly widely deployed within the users interested in 247 cryptographic authentication of IS-IS. The improvement provided by 248 the proposed revised mechanism was not large tnough to justify the 249 change, given the installed base and lack of operator interest in 250 deploying a revised mechanism. 252 If and when a key management protocol appears that is both widely 253 implemented and easily deployed to secure routing protocols such as 254 IS-IS, a different authentication mechanism that is designed for use 255 with that key management schema could be added if desired. 257 3.4. Future Directions 259 If a stronger authentication were believed to be required, then the 260 use of a full digital signature [RFC2154] would be an approach that 261 should be seriously considered. It was rejected for this purpose at 262 this time because the computational burden of full digital signatures 263 is believed to be much higher than is reasonable given the current 264 threat environment in operational commercial networks. 266 4. Acknowledgements 268 The authors would like to thank (in alphabetical order) Dave Katz, 269 Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their 270 comments and suggestions on this document. 272 5. IANA Considerations 274 This memo includes no request to IANA. 276 6. References 278 6.1. Normative References 280 [ISO-10589] 281 ISO, "Intermediate System to Intermediate System Intra- 282 Domain Routeing Exchange Protocol for use in Conjunction 283 with the Protocol for Providing the Connectionless-mode 284 Network Service (ISO 8473)", International Standard 10589: 285 2002, Second Edition, 2002. 287 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 288 Hashing for Message Authentication", RFC 2104, 289 February 1997. 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 6.2. Informative References 296 [Bell06a] Bellare, M., "New Proofs for NMAC and HMAC: Security 297 without Collision-Resistance", Preliminary Version, in 298 Proceedings of Crypto 2006, Lecture Notes in Computer 299 Science Vol. 4117, August 2006. 301 [Bell06b] Bellare, M., "New Proofs for NMAC and HMAC: Security 302 without Collision-Resistance", August 2006, 303 . 306 [DoS] Voydock, V. and S. Kent, "Security Mechanisms in High- 307 level Networks", ACM Computing Surveys Vol. 15, No. 2, 308 June 1983. 310 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", EuroCrypt 311 Rump Session 1996, May 1996. 313 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 314 CryptoBytes Vol. 2, No. 2, 1996. 316 [Dobb98] Dobbertin, H., "Cryptanalysis of MD4", Journal of 317 Cryptology Vol. 11, No. 4, 1998. 319 [FLN07] Fouque, P., Leurent, G., and P. Nguyen, "Full Key-Recovery 320 Attacks on HMAC/NMAC-MD5 and NMAC-MD5", Proceedings of 321 Crypto 2007, August 2007. 323 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 324 dual environments", RFC 1195, December 1990. 326 [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", 327 RFC 1704, October 1994. 329 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 330 Digital Signatures", RFC 2154, June 1997. 332 [WY05] Wang, X. and H. Yu, "How to Break MD5 and Other Hash 333 Functions", Proceedings of EuroCrypt 2005, Lecture Notes 334 in Computer Science Vol. 3494, 2005. 336 Authors' Addresses 338 Tony Li 339 Cisco Systems, Inc. 340 170 W. Tasman Dr. 341 San Jose, CA 95134 342 USA 344 Phone: +1 408 853 1494 345 Email: tony.li@tony.li 347 Ran J. Atkinson 348 Extreme Networks, Inc. 349 3585 Monroe St. 350 Santa Clara, CA 95051 351 USA 353 Phone: +1 408 579 2800 354 Email: rja@extremenetworks.com 356 Full Copyright Statement 358 Copyright (C) The IETF Trust (2008). 360 This document is subject to the rights, licenses and restrictions 361 contained in BCP 78, and except as set forth therein, the authors 362 retain all their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Intellectual Property 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use of 386 such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository at 388 http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at 394 ietf-ipr@ietf.org. 396 Acknowledgment 398 Funding for the RFC Editor function is provided by the IETF 399 Administrative Support Activity (IASA).