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