idnits 2.17.1 draft-li-isis-hmac-shs-01.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 20. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 440. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 97 has weird spacing: '... Ko is t...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (28 February 2007) is 6264 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ISO-10589' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC-3692' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'Bell89' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC-1195' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC-1704' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC-3359' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC-3563' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC-3567' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC-4086' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3567 (Obsoleted by RFC 5304) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Atkinson 3 Extreme Networks 4 Category: Informational T. Li 5 Expires 28 Aug 2007 Cisco Systems 6 Updates: RFC-3567 M. Fanto 7 Ford Motor Company 8 28 February 2007 10 IS-IS Authentication with HMAC-SHS 11 13 Status of this Memo 15 Distribution of this memo is unlimited. 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes how the NIST Secure Hash Standard 40 family of algorithms are used for IS-IS authentication. 42 1. INTRODUCTION 44 This document provides an update to IS-IS Cryptographic 45 Authentication, which is specified in RFC-3567. This document 46 does not deprecate RFC-3567. IS-IS as deployed in the Internet 47 is defined by RFC-1195 and ISO 10589. 49 This document adds support for all algorithms defined in the 51 US NIST Secure Hash Standard (SHS) as defined in NIST FIPS 180-2. 52 [FIPS-180-2] includes SHA-1, SHA-256, SHA-384, and SHA-512. 53 The HMAC authentication mode as defined in NIST FIPS 198 is used. 54 [FIPS-198] 56 This creation of this addition to IS-IS was driven by operator 57 requests that they be able to use the NIST SHS family of algorithms, 58 in the NIST HMAC mode, instead of being forced to use the 59 Keyed-MD5 algorithm and mode. 61 While there are no openly published attacks on the HMAC-MD5 62 mechanism, some reports [Dobb96a, Dobb96b] create concern 63 about the ultimate strength of the MD5 cryptographic hash 64 function. 66 2. AUTHENTICATION PROCEDURES 68 The authentication type used for any of the HMAC-SHS algorithms 69 is XX. 71 The length of the Authentication Value varies with the specific 72 hashing algorithm used. The length field in the TLV is the sum 73 of the length of the Authentication Value field and the number 1. 74 For example, when SHA-256 is in use, the length of the Authentication 75 Value is 32 and the length field in the TLV is 33. 77 2.1 Authentication Process. 79 When calculating the HMAC-SHS result for Sequence Number PDUs, 80 Level 1 Sequence Number PDUs SHALL use the Area Authentication string 81 as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall 82 use the domain authentication string as in Level 2 Link State PDUs. 83 IS-IS HELLO PDUs SHALL use the Link Level Authentication String, 84 which MAY be different from that of Link State PDUs. The HMAC-SHS 85 result for the IS-IS HELLO PDUs SHALL be calculated after the Packet 86 is padded to the MTU size, if padding is not disabled. Implementations 87 that support the optional checksum for the Sequence Number PDUs and 88 IS-IS HELLO PDUs MUST NOT include the Checksum TLV. 90 2.2 Cryptographic Aspects 92 In the algorithm description below, the following nomenclature, 93 which is consistent with [FIPS-198], is used: 95 H is the specific hashing algorithm (e.g. SHA-256). 96 K is the password for the PDU type as per ISO 10589. 97 Ko is the cryptographic key used with the hash algorithm. 99 B is the block size of H, measured in octets rather than bits. 100 Note that B is the internal block size, not the hash size. 101 For SHA-1 and SHA-256: B == 64 102 For SHA-384 and SHA-512: B == 128 103 L is the length of the hash, measured in octets rather than bits. 104 XOR is the exclusive-or operation. 105 Opad is the hexadecimal value 0x5c repeated B times. 106 Ipad is the hexadecimal value 0x36 repeated B times. 107 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 109 (1) PREPARATION OF KEY 110 In this application, Ko is always L octets long. 112 If the Authentication Key (K) is L octets long, then Ko is equal 113 to K. If the Authentication Key (K) is more than L octets long, 114 then Ko is set to H(K). If the Authentication Key (K) is less 115 than L octets long, then Ko is set to the Authentication Key (K) 116 with zeros appended to the end of the Authentication Key (K) such 117 that Ko is L octets long. 119 (2) FIRST HASH 120 First, the IS-IS packet's Authentication Data field is filled 121 with the value Apad and the Authentication Type field is set 122 to XX. 124 Then, a first hash, also known as the inner hash, is computed 125 as follows: 126 First-Hash = H(Ko XOR Ipad || (IS-IS Packet)) 128 (3) SECOND HASH 129 Then a second hash, also known as the outer hash, is computed 130 as follows: 131 Second-Hash = H(Ko XOR Opad || First-Hash) 133 (4) RESULT 134 The result Second-Hash becomes the Authentication Data that is 135 sent in the Authentication Data field of the IS-IS packet. The 136 length of the Authentication Data field is always identical to 137 the message digest size of the specific hash function H that is 138 being used. 140 This also means that the use of hash functions with larger 141 output sizes will also increase the size of the IS-IS packet 142 as transmitted on the wire. 144 2.3 Accepting Authenticated IS-IS Packets 146 To authenticate an incoming PDU, a system should save the value 148 of the Authentication Value field, the Checksum, and the Remaining 149 Lifetime fields. Then set the Authentication Value equal to Apad 150 and zero the Checksum and Remaining Lifetime fields. The 151 Authentication Value is then computed as described above, 152 and finally the values of these three fields is restored. 154 An implementation that implements HMAC-SHS authentication and 155 receives HMAC-SHS Authentication Information MUST discard the PDU 156 if the Authentication Value is incorrect. The implementation 157 SHOULD log such authentication failures in some implementation 158 specific manner. 160 An implementation MAY have a transition mode where it includes 161 HMAC-SHS Authentication Information in PDUs but does not verify 162 the HMAC-SHS authentication information. This is a transition aid 163 for networks in the process of deploying authentication. 165 An implementation MAY check a set of passwords when verifying the 166 Authentication Value. This provides a mechanism for incrementally 167 changing passwords in a network. 169 An implementation that does not implement HMAC-SHS authentication 170 MAY accept a PDU that contains the HMAC-SHS Authentication Type. 171 ISes (routers) that implement HMAC-SHS authentication and initiate 172 LSP purges MUST remove the body of the LSP and add the authentication 173 TLV. ISes implementing HMAC-SHS authentication MUST NOT accept 174 unauthenticated purges. ISes MUST NOT accept purges that contain 175 TLVs other than the authentication TLV. These restrictions are 176 necessary to prevent a hostile system from receiving an LSP, setting 177 the Remaining Lifetime field to zero, and flooding it, thereby 178 initiating a purge without knowing the authentication password. 180 2.4 Implementation Considerations 182 Conceptually, there is an "IS-IS Security Association", both 183 in this specification and in RFC-3567. This security association 184 consists of a cryptographic key (K), an authentication algorithm 185 (e.g. SHA-256), a cryptographic mode (e.g. HMAC), a start time, 186 and a stop time. Start Time is a local representation of the 187 day and time when the security association first becomes valid. 188 Stop Time is a local representation of the day and time when the 189 security association ceases to be valid. However, this is an 190 architectural concept and does not strictly constrain the 191 implementation to follow precisely that representation internally. 192 For example, one might choose to combine the authentication algorithm 193 with the cryptographic mode as a single integrated datum inside 194 a particular IS-IS implementation. Similarly, one might choose 195 to store the Start Time and a time duration, in lieu of storing 196 the literal Start Time and Stop Time. In such a case, the Stop 197 Time could be computed by adding the time duration to the Start 198 Time. Note that it is permitted for an IS-IS Security Association 199 to have infinite lifetime, although this is not recommended 200 operational practice. In order to support smooth key rollover, 201 an implementation MUST be able to support at least 2 concurrent 202 IS-IS Security Associations. 204 There is an implementation issue just after password rollover 205 on an IS-IS router that might benefit from additional commentary. 206 Immediately after password rollover on the router, the router or 207 IS-IS process may restart. If this happens, this causes the LSP 208 Sequence Number restarts from the value 1 using the new password. 209 However, neighbors will reject those new LSPs because the Sequence 210 Number is smaller. The router can not increase its own LSP 211 Sequence Number because it fails to authenticate its own old LSP 212 that neighbors keep sending to it. So the router can not update 213 its LSP Sequence Number to its neighbors until all the neighbors 214 time out all of the original LSPs. One possible solution to this 215 problem is for the IS-IS process to detect if any inbound LSP with 216 an authentication failure has the local System ID and also has 217 a higher Sequence Number than the IS-IS process has. In this event, 218 the IS-IS process SHOULD increase its own LSP Sequence Number 219 accordingly and re-flood the LSPs. However, as this scenario 220 could also be triggered by an active attack by an adversary, 221 it is recommended that a counter also be kept on this case 222 to mitigate the risk from such an active attack. 224 3. SECURITY CONSIDERATIONS 226 This document enhances the security of the IS-IS routing protocol 227 by adding support for additional cryptographic hash functions. 229 Because a routing protocol contains information that need not 230 remain secret, privacy is not a requirement. However, authentication 231 of the messages within the protocol is of interest, to reduce the 232 risk of an adversary compromising the routing system by deliberately 233 injecting false information into the routing system. 235 The technology in this document provides an authentication mechanism 236 for IS-IS. The mechanism described here is not perfect and does not 237 need to be perfect. Instead, this mechanism represents a significant 238 increase in the work function of an adversary attacking the IS-IS 239 protocol, while not causing undue implementation, deployment, or 240 operational complexity. 242 This mechanism does not prevent replay attacks, however, in most 243 cases, such attacks would trigger existing mechanisms in the IS-IS 244 protocol that would effectively reject old information. Denial of 245 service attacks are not generally preventable in a useful networking 246 protocol [VK83]. 248 Because of implementation considerations, including the need for 249 backwards compatibility, this specification uses the same mechanism 250 as specified in RFC-3567 and limits itself to adding support for 251 additional cryptographic hash functions. Network operators have 252 indicated they strongly prefer to retain the basic mechanism 253 defined in RFC-3567. In particular, network operators have 254 indicated a preference for omitting the Key-ID field used with 255 OSPFv2 or RIPv2 authentication. They do not consider the absence 256 of a Key-ID field in the packet problematic, given the existing 257 successful deployments of "keychains" with IS-IS cryptographic 258 authentication. 260 If a stronger authentication were believed to be required, then 261 the use of a full digital signature [RFC-2154] would be an approach 262 that should be seriously considered. It was rejected for this purpose 263 at this time because the computational burden of full digital signatures 264 is believed to be much higher than is reasonable given the current 265 threat environment in operational commercial networks. 267 4. IANA CONSIDERATIONS 269 ISO 10589 created an Authentication Information TLV (code 10) for use 270 in IS-IS routing protocol packets (PDUs). The first octet in the TLV 271 is defined as the Authentication Type. ISO 10589 reserves the 272 following IS-IS authentication code points: 274 0 - Reserved 275 1 - Cleartext Password 276 255 - Routeing Domain private authentication method 278 ISO 10589 also reserves code points 2-254. 280 This document requests that IANA create a new code point registry 281 to administer the Authentication Type code points for TLV 10. 282 This registry would be part of the existing IS-IS code points 283 registry as established by RFC 3563 and RFC 3359. This registry 284 should be managed using the Designated Expert policy as described 285 in [RFC-2434]. 287 This document also requests that IANA populate the registry with 288 the code points described above and also reserve code point 54 for 289 HMAC-MD5 authentication, as described by RFC 3567. This document 290 also requests that IANA reserve a code point for HMAC-SHA 291 authentication, as described by this document. The value for this 292 HMAC-SHA code point should be inserted into this document in 293 Section 2 above, to replace the value XX found therein. 295 [RFC Editor note: This section should be removed prior 296 to RFC publication.] 298 5. ACKNOWLEDGEMENTS 300 The authors would like to thank Bill Burr, Tim Polk, John Kelsey, and 301 Morris Dworkin of (US) NIST for review of portions of this document 302 that are directly derived from the closely related work on RIPv2 303 Cryptographic Authentication [RFC-4822]. 305 6. REFERENCES 307 6.1 Normative References 309 [ISO-10589] International Standards Organisation, "Intermediate 310 System to Intermediate System Routing Information 311 Exchange Protocol for use in Conjunction with the 312 Protocol for Providing the Connectionless-mode 313 Network Service (ISO 8473)", ISO/IEC 10589:2002, 314 Second Edition, 2002. 316 [FIPS-180-2] US National Institute of Standards & Technology, 317 "Secure Hash Standard (SHS)", FIPS PUB 180-2, 318 August 2002. 320 [FIPS-198] US National Institute of Standards & Technology, 321 "The Keyed-Hash Message Authentication Code (HMAC)", 322 FIPS PUB 198, March 2002. 324 [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate 325 Requirement Levels", RFC-2119, BCP-14, March 1997. 327 [RFC-2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 328 Considerations Section in RFCs", RFC-2434, October 1998. 330 [RFC-3692] T. Narten, "Assigning Experimental and Testing Numbers 331 Considered Useful. RFC-3692, January 2004. 333 6.2 Informative References 335 [Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol 336 Suite", ACM Computer Communications Review, Volume 19, 337 Number 2, pp. 32-48, April 1989. 339 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", 340 Technical Report, 2 May 1996. (Presented at the 341 Rump Session of EuroCrypt 1996.) 343 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent 344 Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996. 346 [RFC-1195] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP 347 and Dual Environments", RFC 1195, December 1990. 349 [RFC-1704] Haller, N. and R. Atkinson, "On Internet 350 Authentication", RFC 1704, October 1994. 352 [RFC-2154] S. Murphy, M. Badger, and B. Wellington, 353 "OSPF with Digital Signatures", RFC 2154, June 1997. 355 [RFC-3359] T. Przygienda, "Reserved Type, Length and Value (TLV) 356 Codepoints in Intermediate System to Intermediate System", 357 RFC-3359, August 2002. 359 [RFC-3563] A. Zinin, "Cooperative Agreement Between the ISOC/IETF 360 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 361 (JTC1/SC6) on IS-IS Routing Protocol Development", 362 RFC-3563, July 2003. 364 [RFC-3567] T. Li, R. Atkinson, "Intermediate System to Intermediate 365 System (IS-IS) Cryptographic Authentication", RFC-3567, 366 July 2003. 368 [RFC-4086] D. Eastlake III, J. Schiller, and S. Crocker, 369 "Randomness Requirements for Security", 370 BCP 106, RFC 4086, June 2005 372 [RFC-4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic 373 Authentication", RFC 4822, February 2007. 375 [VK83] Voydock, V. and S. Kent, "Security Mechanisms in High-level 376 Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. 378 AUTHORS 380 Randall J. Atkinson 381 Extreme Networks 382 3585 Monroe Street 383 Santa Clara, CA 95051 USA 385 Phone: +1 (408) 579-2800 386 EMail: rja@extremenetworks.com 388 Tony Li 389 Cisco Systems 390 San Jose, CA 391 USA 393 EMail: tli@cisco.com 395 Matt Fanto 396 Ford Motor Company 397 Michigan 398 USA 400 EMail: tbd 402 Full Copyright Statement 404 Copyright (C) The IETF Trust (2007). 406 This document is subject to the rights, licenses and restrictions 407 contained in BCP 78, and except as set forth therein, the authors 408 retain all their rights. 410 This document and the information contained herein are provided on an 411 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 412 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND 413 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 414 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 415 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 416 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 418 Intellectual Property 420 The IETF takes no position regarding the validity or scope of any 421 Intellectual Property Rights or other rights that might be claimed 422 to pertain to the implementation or use of the technology 423 described in this document or the extent to which any license 424 under such rights might or might not be available; nor does it 425 represent that it has made any independent effort to identify any 426 such rights. Information on the procedures with respect to 427 rights in RFC documents can be found in BCP 78 and BCP 79. 429 Copies of IPR disclosures made to the IETF Secretariat and any 430 assurances of licenses to be made available, or the result of an 431 attempt made to obtain a general license or permission for the use 432 of such proprietary rights by implementers or users of this 433 specification can be obtained from the IETF on-line IPR repository 434 at http://www.ietf.org/ipr. 436 The IETF invites any interested party to bring to its attention 437 any copyrights, patents or patent applications, or other 438 proprietary rights that may cover technology that may be required 439 to implement this standard. Please address the information to the 440 IETF at ietf-ipr@ietf.org.