idnits 2.17.00 (12 Aug 2021) /tmp/idnits8138/draft-ietf-isis-hmac-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (10 April 2000) is 8075 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) == Unused Reference: '1' is defined on line 347, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 349, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 359, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1636 (ref. '5') ** Obsolete normative reference: RFC 1826 (ref. '6') (Obsoleted by RFC 2402) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Li 2 Internet-Draft Procket Networks 3 Category: Standards Track R. Atkinson 4 draft-ietf-isis-hmac-01.txt 10 April 2000 6 IS-IS Cryptographic Authentication 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC-2026. This document is a 12 submission to the IETF IS-IS Working Group. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF) and its working groups. Note that other groups may 16 also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 6 months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/ietf/shadow.html 29 ABSTRACT 31 This document specifies an algorithm-independent cryptographic 32 authentication mechanism for use with the IS-IS routing protocol. 34 1. Use of Imperatives 36 Throughout this document, the words that are used to define the 37 significance of particular requirements are capitalized. These words 38 have the meaning defined in RFC-2119, which is hereby incorporated by 39 reference. [7] 41 2. Introduction 43 Growth in the Internet has made us aware of the need for improved 44 authentication of routing information. Other routing protocols are 45 known to have been the subject of both active and passive attacks. 46 At present, IS-IS provides for unauthenticated service or password 47 authentication. Both are vulnerable to passive attacks currently 48 widespread in the Internet. Well-understood security issues exist in 49 routing protocols [3]. Clear text passwords, currently specified for 50 use with IS-IS, are no longer considered sufficient [4] in the 51 Internet. 53 If authentication is disabled, then only simple misconfigurations 54 are detected. Simple passwords transmitted in the clear will further 55 protect against the honest neighbor, but are useless in the general 56 case. By simply capturing information on the wire - straightforward 57 even in a remote environment - a hostile process can learn the 58 password and overcome the network. While IS-IS packets aren't 59 themselves routed, anyone with access to a system on the physical 60 link can inject forged packets (unless a cryptographic authentication 61 method is in use). 63 We propose that IS-IS use an authentication algorithm, as was 64 originally proposed for SNMP Version 2. Keyed MD5 is proposed as the 65 standard authentication algorithm for IS-IS, but the authentication 66 mechanism is believed to be algorithm-independent. 68 While this mechanism is not unbreakable (no known mechanism 69 is), it provides a greatly enhanced probability that a system being 70 attacked will detect and ignore hostile messages. This is because we 71 transmit the output of an authentication algorithm (e.g., Keyed MD5) 72 rather than the secret IS-IS Authentication Key. This output is a 73 one-way function of a message and a secret IS-IS Authentication Key. 74 This IS-IS Authentication Key is never sent over the network in the 75 clear, thus providing protection against the passive attacks now 76 commonplace in the Internet. 78 In this way, protection is afforded against forgery or message 79 modification. It is possible to replay a LSP until the LSP sequence 80 number changes, but the normal dynamics of the protocol make LSP 81 replay less of an issue in the long-term. The mechanism does not 82 afford confidentiality, since messages stay in the clear; however, 83 the mechanism is also exportable from most countries, which test a 84 privacy algorithm would fail. 86 Other relevant rationales for the approach are that Keyed MD5 is 87 being used for RIPv2 and OSPF cryptographic authentication, and is 88 therefore present in routers already, as is some form of password 89 management. In the interest of code reuse, this IS-IS extension 90 specifies Keyed-MD5 as the mandatory-to-implement algorithm. There 91 are no specific known vulnerabilities in Keyed-MD5 as used in this 92 context. A similar approach has been standardized for use in IP- 93 layer authentication. [6] 95 This document is a publication of the IS-IS Working Group 96 within the IETF. It is also a contribution to ISO IEC JTC1/SC6, for 97 eventual inclusion with ISO 10589. 99 3. Implementation Approach 101 Implementation requires three issues to be addressed: 103 (1) TLV format for use with cryptographic authentication, 105 (2) Authentication procedures, and 107 (3) Management controls. 109 3.1. IS-IS PDU Format 111 The IS-IS protocol, as specified in ISO 10589, provides for the 112 authentication of Link-State PDUs (LSPs) through the inclusion of 113 authentication information as part of the LSP. This authentication 114 information is encoded as a Type-Length-Value triple. 116 The type of the Authentication TLV is 10. The length of the 117 TLV is variable. The value of the TLV depends on the Authentication 118 Type being used. 120 The first octet of the value field indicates the 121 Authentication Type. Authentication Type 0 is reserved. Type 1 122 indicates a clear-text password, and Type 255 is used for routing 123 domain private authentication methods. 125 This document specifies an extension for cryptographic 126 authentication. When cryptographic authentication is in use, the 127 Authentication Type in the first octet of the Value field is set to 128 54 and the second octet of the Value field contains a Key Identifier 129 (Key-ID). The Key Identifier is used by the recipient to select the 130 particular IS-IS Security Association in use for this PDU. The 131 remainder of the Value field contains the Authentication Data itself. 132 Thus, the Length of the TLV is (2 + sizeof(authentication data)), 133 when the Authentication Type is cryptographic authentication. 135 0 1 2 3 136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 137 +---------------+---------------+---------------+---------------+ 138 | TLV Type=10 | TLV Length | AuthType = 54 | Key Identifier| 139 +---------------+---------------+---------------+---------------+ 140 | Authentication Data (Length varies with Crypto Algorithm) | 141 +---------------+---------------+---------------+---------------+ 142 Figure 1: Authentication TLV Format, 143 when Cryptographic Authentication is in use 145 3.2 Authentication Procedures 147 Conforming or compliant implementations MUST implement the 148 HMAC-MD5 cryptographic algorithm with this extension. The 149 algorithm-dependent details of HMAC-MD5 are specified in Appendix A. 151 A fundamental concept of IS-IS Cryptographic Authentication 152 is the "IS-IS Security Association". An IS-IS Security Association 153 contains a Key Identifier, the Cryptographic Authentication Algorithm 154 (e.g. HMAC-MD5) to use, a Lifetime, and the Cryptographic 155 Authentication Key to use. The Cryptographic Authentication Key is 156 also the password for the PDU Type, as specified in ISO 10589. 158 An implementation MAY include cryptographic authentication 159 information in PDUs even if it does not fully implement cryptographic 160 authentication. This allows an implementation to generate 161 authentication information without verifying the authentication 162 information as a transition aid for networks in the process of 163 deploying authentication. 165 An implementation that does not implement cryptographic 166 authentication MAY accept a PDU that contains the cryptographic 167 authentication type. 169 The remainder of this section describes the algorithm- 170 independent processing for IS-IS Cryptographic Authentication. 172 The Type, Length, Authentication Type, and Key Identifier 173 fields are filled with their final values prior to calculation of the 174 cryptographic Authentication Data. The Authentication Data field, 175 the Checksum field, and the Remaining Lifetime fields are all filled 176 with all zeros for the calculation of the cryptographic 177 Authentication Data for a given LSP. Sending systems calculate the 178 Checksum value after the Authentication Data field has been filled 179 in. After the Checksum value has been calculated, it is placed in 180 the IS-IS packet. 182 [New paragraph discussing how contents are dealt with for non-LSPs 183 (e.g. CSNPs, IIHs) coming here soon.] 185 When multiple valid IS-IS Security Associations exist for a 186 given IS-IS system, sending systems SHOULD pick an IS-IS Security 187 Association that is not about to expire in order to facilitate smooth 188 key rollover. 190 Receiving systems first check the Key-ID field and use its 191 value to locate the appropriate IS-IS Security Association. If no 192 IS-IS Security Association exists, the packet is discarded as not 193 authentic, without any further processing. If the matching IS-IS 194 Security Association is located, then the receiving system 195 independently computes the cryptographic Authentication Data using 196 the key contained in that IS-IS Security Association and the values 197 in the received IS-IS packet. For receive-side authentication 198 computations, the Authentication Data field itself, the Checksum 199 field, and the Remaining Lifetime fields are each assumed to be zero. 200 If the computed cryptographic Authentication Data is identical to the 201 received Authentication Data, the packet is accepted as authentic and 202 undergoes normal IS-IS receive-side processing. If there is any 203 difference, the packet is discarded as not authentic, without any 204 further processing. 206 An implementation SHOULD log authentication failures of 207 received IS-IS PDUs if this can be done without creating a denial of 208 service attack on the Intermediate System. Details of this are 209 unspecified here. 211 Intermediate Systems (i.e. routers) that implement 212 cryptographic authentication and initiating LSP purges MUST remove 213 the body of the LSP and add the authentication TLV. Intermediate 214 Systems MUST NOT accept unauthenticated purges. Intermediate Systems 215 MUST NOT accept purges that contain TLVs other than the 216 Authentication TLV. These restrictions are necessary to prevent a 217 hostile system from receiving an LSP, setting the Remaining Lifetime 218 field to zero, and flooding it, thereby initiating a purge without 219 knowing any authentication information. 221 3.3. Key Management Requirements 223 It is strongly desirable that a hypothetical security breach in 224 one Internet protocol not automatically compromise other Internet 225 protocols. The Cryptographic Authentication Key of this 226 specification SHOULD NOT be stored or transmitted using protocols or 227 algorithms that have known flaws. 229 Implementations MUST support the storage and use of at least two 230 IS-IS Security Associations at the same time. During normal 231 operation, only one IS-IS Security Association (i.e. one key) will 232 usually be active in a given IS-IS system. However, during the key 233 change period, both the old IS-IS Security Association and the new 234 IS-IS Security Association (i.e. two keys) will be active in the same 235 system at the same time. 237 An IS-IS Security Association MUST contain at least the 238 lifetime of the IS-IS Security Association (e.g. date/time first 239 valid and date/time no longer valid), the Key Identifier, the 240 Cryptographic Authentication Algorithm, and the Cryptographic Key 241 itself. The IS-IS Security Association lifetime MAY be infinite or 242 MAY have a specific date/time for start and end. 244 Implementations MUST support manual key distribution (e.g., 245 the privileged user manually typing in the parameters for the IS-IS 246 Security Association (i.e. key, key lifetime, and key identifier) on 247 the router console. If more than one algorithm is supported, then 248 the implementation MUST require that the algorithm be specified for 249 each IS-IS Security Association at the time the other IS-IS Security 250 Association information is entered. IS-IS Security Associations that 251 are out of date MAY be deleted at will by the implementation without 252 requiring human intervention. Manual deletion of active IS-IS 253 Security Associations by the privileged operator SHOULD also be 254 supported. 256 It is desirable to use a key management protocol to 257 distribute IS-IS Authentication Keys among communicating IS-IS 258 implementations. Such a protocol would provide scalability and 259 significantly reduce the human administrative burden. The Key ID can 260 be used as a hook between IS-IS and such a future protocol. Key 261 management protocols have a long history of subtle flaws that are 262 often discovered long after the protocol was first described in 263 public. To avoid having to change all IS-IS implementations should 264 such a flaw be discovered, integrated key management protocol 265 techniques were deliberately omitted from this specification. 267 4.0. Key Management Procedures 269 As with all security methods using keys, it is necessary to 270 change the IS-IS Authentication Key on a regular basis. To maintain 271 routing stability during such changes, implementations MUST be able 272 to store and use at least two IS-IS Security Associations (hence: 273 authentication keys) in any given system at the same time. 275 Each IS-IS Security Association has its own Key Identifier, 276 which is stored locally. The Key Identifier uniquely identifies the 277 IS-IS Security Association in use. 279 The intermediate system creating the IS-IS message will 280 select a valid key from the set of valid keys for that interface. 281 The receiver will use the Key Identifier to determine which IS-IS 282 Security Association to use for authentication of the received 283 message. The receiver MUST NOT ignore the Key Identifier and try all 284 known keys on an incoming packet as this creates an easily prevented 285 denial-of-service attack on the IS-IS implementation. More than one 286 IS-IS Security Association (hence: more than one key) MAY be 287 associated with an interface at the same time. 289 Hence it is possible to have fairly smooth IS-IS 290 Authentication Key rollovers without losing legitimate LSPs because 291 the stored authentication key is incorrect and without requiring 292 people to change all the keys at once. To ensure a smooth rollover, 293 each communicating IS-IS system must be updated with the new key 294 several minutes before the current key will expire and several 295 minutes before the new key lifetime begins. The new key should have a 296 lifetime that starts several minutes before the old key expires. This 297 gives time for each system to learn of the new IS-IS Authentication 298 Key before that key will be used. It also ensures that the new key 299 will begin being used and the current key will go out of use before 300 the current key's lifetime expires. For the duration of the overlap 301 in key lifetimes, a system may receive messages using either key and 302 authenticate the message as indicated by the Key ID. 304 4.3. Pathological Cases 306 Two pathological cases exist which must be handled, which are 307 failures of the network manager. Both of these should be exceedingly 308 rare. 310 During key rollover, devices may exist which have not yet been 311 successfully configured with the new key. Therefore, routers SHOULD 312 implement (and would be well advised to implement) an algorithm that 313 detects the set of keys being used by its neighbors, and transmits 314 its messages using both the new and old keys until all of the 315 neighbors are using the new key or the lifetime of the old key 316 expires. Under normal circumstances, this elevated transmission rate 317 will exist for a single update interval. 319 In the event that the last key associated with a system, it is 320 unacceptable to revert to an unauthenticated condition, and not 321 advisable to disrupt routing. Therefore, the router should send a 322 "last authentication key expiration" notification to the network 323 manager and treat the key as having an infinite lifetime until the 324 lifetime is extended, the key is deleted by network management, or a 325 new key is configured. 327 5. Conformance Requirements 329 To conform to this specification, an implementation MUST support 330 all of its aspects. The HMAC-MD5 authentication algorithm MUST be 331 implemented by all conforming implementations. MD5 is defined in 332 RFC-1321. A conforming implementation MAY also support other 333 authentication algorithms such as Keyed Secure Hash Algorithm (SHA). 335 Manual key distribution as described above MUST be supported 336 by all conforming implementations. All conforming implementations 337 MUST support the smooth key rollover described under "Key Change 338 Procedures." 340 6. Acknowledgments 342 This work is derived directly from RFC-2082 and the similar work 343 done for OSPFv2 Cryptographic Authentication. 345 7. References 347 [1] ISO-10589 349 [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 350 1992. 352 [3] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", 353 ACM Computer Communications Review, Volume 19, Number 2, 354 pp.32-48, April 1989. 356 [4] Haller, N., and R. Atkinson, "Internet Authentication 357 Guidelines", RFC 1704, October 1994. 359 [5] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report 360 of IAB Workshop on Security in the Internet Architecture", 361 RFC 1636, June 1994. 363 [6] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. 365 [7] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", RFC-2119, March 1997. 368 8. Security Considerations 370 This entire memo describes and specifies an authentication 371 mechanism for the IS-IS routing protocol that is believed to be 372 reasonably secure against active and passive attacks. Passive attacks 373 are clearly widespread in the Internet at present. Protection 374 against active attacks is also needed because active attacks are 375 becoming more common. 377 Users need to understand that the quality of the security provided 378 by this mechanism depends completely on the strength of the 379 implemented authentication algorithms, the strength of the key being 380 used, and the correct implementation of the security mechanism in all 381 communicating IS-IS implementations. This mechanism also depends on 382 the IS-IS Cryptographic Authentication Key being kept confidential by 383 all parties. If any of these incorrect or insufficiently secure, 384 then no real security will be provided to the users of this 385 mechanism. 387 Specifically with respect to the use of SNMP, compromise of SNMP 388 security has the necessary result that the various IS-IS 389 configuration parameters (e.g. routing table, IS-IS Authentication 390 Key) manageable via SNMP could be compromised as well. Changing 391 Authentication Keys using non-encrypted SNMP is no more secure than 392 sending passwords in the clear. 394 Confidentiality is not provided by this mechanism. Protection 395 against traffic analysis is also not provided. Mechanisms such as 396 bulk link encryption might be used when protection against traffic 397 analysis is required. Finally, this technique does not prevent 398 replay attacks. Appropriate use of key management can reduce the 399 residual risk associated with replay attacks if desired by the 400 operator. 402 10. Authors' Addresses 404 Tony Li 405 Procket Networks 406 San Jose, CA 408 Email: tli@procket.com 410 Randall Atkinson 411 Engineer at large