idnits 2.17.1 draft-ietf-isis-hmac-03.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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There are 73 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 16 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 86: '...equence Number PDUs SHALL use the Area...' RFC 2119 keyword, line 89: '...IS-IS HELLO PDUs SHALL use the Link ...' RFC 2119 keyword, line 90: '...on String, which MAY be different from...' RFC 2119 keyword, line 91: '...or the IS-IS HELLO PDUs SHALL be...' RFC 2119 keyword, line 94: '... IS-IS HELLO PDUs MUST NOT include the...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 33 has weird spacing: '..., with exten...' == Line 35 has weird spacing: '...chanism that ...' == Line 39 has weird spacing: '...to that speci...' == Line 46 has weird spacing: '...des for the...' == Line 47 has weird spacing: '...ication of L...' == (68 more instances...) -- 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 (4 July 2001) is 8331 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '1') ** Obsolete normative reference: RFC 1142 (ref. '2') (Obsoleted by RFC 7142) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Experimental RFC: RFC 2154 (ref. '5') Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Li 2 INTERNET DRAFT Procket Networks 3 draft-ietf-isis-hmac-03.txt RJ Atkinson 4 Extreme Networks 5 4 July 2001 7 IS-IS Cryptographic Authentication 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026 except that the right to produce 13 derivative works is not granted. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet-Drafts as reference material or to cite 22 them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 ABSTRACT 32 This document describes the authentication of IS-IS PDUs using the 33 HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions 34 to support IPv4 described in [3]. The base specification includes an 35 authentication mechanism that allows for multiple authentication 36 algorithms. The base specification only specifies the algorithm for 37 cleartext passwords. 39 This document proposes an extension to that specification that 41 allows the use of the HMAC-MD5 authentication algorithm to be used in 42 conjunction with the existing authentication mechanisms. 44 1. Introduction 46 The IS-IS protocol, as specified in ISO 10589, provides for the 47 authentication of Link State PDUs (LSPs) through the inclusion of 48 authentication information as part of the LSP. This authentication 49 information is encoded as a Type-Length-Value (TLV) tuple. 51 The type of the TLV is specified as 10. The length of the TLV 52 is variable. The value of the TLV depends on the authentication 53 algorithm and related secrets being used. The first octet of the 54 value is used to specify the authentication type. Type 0 is 55 reserved, type 1 indicates a cleartext password, and type 255 is used 56 for routing domain private authentication methods. The remainder of 57 the TLV value is known as the Authentication Value. 59 This document extends the above situation by allocating a new 60 authentication type for HMAC-MD5 and specifying the algorithms for 61 the computation of the Authentication Value. This document also 62 describes modifications to the base protocol to insure that the 63 authentication mechanisms described in this document are effective. 65 This document is a publication of the IS-IS Working Group within 66 the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual 67 inclusion with ISO 10589. 69 2. Authentication Procedures 71 The authentication type used for HMAC-MD5 is 54 (0x36). The 72 length of the Authentication Value for HMAC-MD5 is 16, and the length 73 field in the TLV is 17. 75 The HMAC-MD5 algorithm requires a key K and text T as input. 76 The key K is the password for the PDU type, as specified in ISO 77 10589. The text T is the IS-IS PDU to be authenticated with the 78 Authentication Value field inside of the Authentication Information 79 TLV set to zero. Note that the Authentication Type is set to 54 and 80 the length of the TLV is set to 17 before authentication is computed. 81 When LSPs are authenticated, the Checksum and Remaining Lifetime 82 fields are set to zero (0) before authentication is computed. The 83 result of the algorithm is placed in the Authentication Value field. 85 When calculating the HMAC-MD5 result for Sequence Number PDUs 86 and IS-IS HELLO PDUs, Level 1 Sequence Number PDUs SHALL use the Area 87 Authentication string as in Level 1 Link State PDUs. Level 2 88 Sequence Number PDUs shall use the domain authentication string as in 89 Level 2 Link State PDUs. IS-IS HELLO PDUs SHALL use the Link Level 90 Authentication String, which MAY be different from that of Link State 91 PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be 92 calculated after the Packet is padded to the MTU size, if padding is 93 not disabled. Implementations that support the optional checksum for 94 the Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the 95 Checksum TLV. 97 An implementation that implements HMAC-MD5 authentication and 98 receives HMAC-MD5 Authentication Information MUST discard the PDU if 99 the Authentication Value is incorrect. 101 An implementation MAY have a transition mode where it includes 102 HMAC-MD5 Authentication Information in PDUs but does not verify the 103 HMAC-MD5 authentication information. This is a transition aid for 104 networks in the process of deploying authentication. 106 An implementation MAY check a set of passwords when verifying the 107 Authentication Value. This provides a mechanism for incrementally 108 changing passwords in a network. 110 An implementation that does not implement HMAC-MD5 authentication 111 MAY accept a PDU that contains the HMAC-MD5 Authentication Type. 112 ISes (routers) that implement HMAC-MD5 authentication and initiate 113 LSP purges MUST remove the body of the LSP and add the authentication 114 TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept 115 unauthenticated purges. ISes MUST NOT accept purges that contain 116 TLVs other than the authentication TLV. These restrictions are 117 necessary to prevent a hostile system from receiving an LSP, setting 118 the Remaining Lifetime field to zero, and flooding it, thereby 119 initiating a purge without knowing the authentication password. 121 2.1 Implementation Considerations 123 There is an implementation issue just after password rollover on 124 an IS-IS router that might benefit from additional commentary. 125 Immediately after password rollover on the router, the router or IS- 126 IS process may restart. If this happens, this causes the LSP 127 Sequence Number restarts from the value 1 using the new password. 128 However, neighbors will reject those new LSPs because the Sequence 129 Number is smaller. The router can not increase its own LSP Sequence 130 Number because it fails to authenticate its own old LSP that 131 neighbors keep sending to it. So the router can not update its LSP 132 Sequence Number to its neighbors until all the neighbors time out all 133 of the original LSPs. One possible solution to this problem is for 134 the IS-IS process to detect if any inbound LSP with an authentication 135 failure has the local System ID and also has a higher Sequence Number 136 than the IS-IS process has. In this event, the IS-IS process SHOULD 137 increase its own LSP Sequence Number accordingly and re-flood the 138 LSPs. However, as this scenario could also be triggered by an active 139 attack by an adversary, it is recommended that a counter also be kept 140 on this case to mitigate the risk from such an active attack. 142 3. Security Considerations 144 This document enhances the security of the IS-IS routing 145 protocol. Because a routing protocol contains information that need 146 not be kept secret, privacy is not a requirement. However, 147 authentication of the messages within the protocol is of interest, to 148 reduce the risk of an adversary compromising the routing system by 149 deliberately injecting false information into the routing system. 151 The technology in this document provides an authentication 152 mechanism for IS-IS. The mechanism described here is not perfect and 153 does not need to be perfect. Instead, this mechanism represents a 154 significant increase in the work function of an adversary attacking 155 the IS-IS protocol, while not causing undue implementation, 156 deployment, or operational complexity. 158 This mechanism does not prevent replay attacks, however such 159 attacks would trigger existing mechanisms in the IS-IS protocol that 160 would effectively reject old information. Denial of service attacks 161 are not generally preventable in a useful networking protocol [4]. 163 Changes to the authentication mechanism described here 164 (primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were 165 considered at some length, but ultimately were rejected. The 166 mechanism here was already widely implemented in 1999. As of this 167 writing, this mechanism is fairly widely deployed within the users 168 interested in cryptographic authentication of IS-IS. The improvement 169 provided by the proposed revised mechanism was not large enough to 170 justify the change, given the installed base and lack of operator 171 interest in deploying the proposed revised mechanism. 173 If and when a key management protocol appears that is both 174 widely implemented and easily deployed to secure routing protocols 175 such as IS-IS, a different authentication mechanism that is designed 176 for use with that key management schema could be added if desired. 178 If a stronger authentication were believed to be required, then 180 the use of a full digital signature [5] would be an approach that 181 should be seriously considered. It was rejected for this purpose at 182 this time because the computational burden of full digital signatures 183 is believed to be much higher than is reasonable given the current 184 threat environment in operational commercial networks. 186 ACKNOWLEDGMENTS 188 The author would like to thank (in alphabetical order) Ran 189 Atkinson, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, 190 and Henk Smit for their comments and suggestions on this document. 192 REFERENCES 194 [1] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for Message 195 Authentication", RFC-2104, February 1997 197 [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routing 198 Exchange Protocol for use in Conjunction with the Protocol for Providing 199 the Connectionless-mode Network Service (ISO 8473)", International Standard 200 10589 [Also republished as RFC 1142]. 202 [3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual 203 environments", RFC-1195, December 1990. 205 [4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level 206 Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. 208 [5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital Signatures", 209 RFC-2154, June 1997. 211 Author's Address 213 Tony Li 214 Procket Networks 215 1100 Cadillac Ct. 216 Milpitas, California 217 95035 USA 219 Email: tli@procket.net 220 Phone: +1 (408) 635-7903 222 RJ Atkinson 223 Extreme Networks 224 3585 Monroe Street 225 Santa Clara, CA 226 95051 USA 227 Email: rja@extremenetworks.com 228 Phone: +1 (408) 579-2800