idnits 2.17.1 draft-ietf-isis-hmac-sha-06.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 27. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 503. 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 == Line 200 has weird spacing: '... Ko is the...' -- 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 (November 2009) is 5269 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' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft IS-IS Generic Cryptographic Authentication November 2009 3 Network Working Group Manav Bhatia 4 Internet Draft Alcatel-Lucent 5 Intended Status: Proposed Standard Vishwas Manral 6 Expires: April 2009 IP Infusion 7 Tony Li 8 Redback Networks Inc. 9 Randall J. Atkinson 10 Extreme Networks 11 Russ White 12 Cisco Systems 13 Matthew J. Fanto 14 Ciber Inc. 16 IS-IS Generic Cryptographic Authentication 18 draft-ietf-isis-hmac-sha-06.txt 20 Status of this Memo 22 Distribution of this memo is unlimited. 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 This document proposes an extension to Intermediate System to 47 Intermediate System (IS-IS) to allow the use of any cryptographic 48 authentication algorithm in addition to the already documented 49 authentication schemes, described in the base specification and RFC 50 5304. 52 Although this document has been written specifically for using Hashed 53 Message Authentication Code (HMAC) construct along with the Secure 54 Hash algorithm (SHA) family of cryptographic hash functions, the 55 method described in this document is generic and can be used to 56 extend IS-IS to support any cryptographic hash function in the 57 future. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119. [KEYWORDS] 65 Contents 67 1. Introduction...................................................2 68 2. IS-IS Security Association.....................................3 69 3. Authentication Procedures......................................4 70 3.1 Authentication TLV.........................................4 71 3.2 Authentication Process.....................................4 72 3.3 Cryptographic Aspects......................................4 73 3.4 Procedures at the Sending Side.............................6 74 3.5 Procedure at the Receiving Side............................6 75 4. Security Considerations........................................7 76 5. Acknowledgements...............................................8 77 6. IANA Considerations............................................8 78 7. References.....................................................8 79 7.1 Normative References.......................................8 80 7.2 Informative References.....................................9 81 8. Author's Addresses.............................................9 83 1. Introduction 85 Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] 86 specification allows for authentication of its Protocol Data Units 87 (PDUs) via the authentication TLV 10 that is carried as the part of 88 the PDU. The base spec has provision for only clear text passwords 89 and RFC 5304 [RFC5304] augments this to provide the capability to use 90 Hashed Message Authentication Code - Message Digest 5 (HMAC MD5) 91 authentication for its PDUs. 93 The first octet of value field of TLV 10 specifies the type of 94 authentication to be carried out. Type 0 is reserved, Type 1 95 indicates a cleartext password, Type 54 indicates HMAC MD5 and Type 96 255 is used for routing domain private authentication methods. The 97 remainder of the value field contains the actual authentication data 98 determined by the value of the authentication type. 100 This document proposes a new authentication type to be carried in TLV 101 10, called the generic cryptographic authentication (CRYPTO_AUTH). 102 This can be used to specify any authentication algorithm for 103 authenticating and verifying IS-IS PDUs. 105 This document also explains how HMAC-SHA authentication can be used 106 in IS-IS. 108 By definition, HMAC [RFC2104] requires a cryptographic hash function. 109 We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384 and 110 SHA-512 [NIST] for this purpose to authenticate the IS-IS PDUs. 112 We propose to do away with the per interface keys and instead have 113 key IDs that map to unique IS-IS Security Associations (SA). 115 While at the time of this writing there are no openly published 116 attacks on the HMAC-MD5 mechanism, some reports [Dobb96a, Dobb96b] 117 create concern about the ultimate strength of the MD5 cryptographic 118 hash function. 120 2. IS-IS Security Association 122 An IS-IS Security Association contains a set of shared parameters 123 between any two legitimate IS-IS speakers. 125 Parameters associated with an IS-IS SA: 127 O Key ID : This is a two octet unsigned integer used to uniquely 128 identify an IS-IS SA, as manually configured by the network operator. 129 The receiver determines the active SA by looking at this field in the 130 incoming PDU. The sender puts this Key ID based on the active 131 configuration. 133 Using key IDs makes changing keys while maintaining protocol 134 operation convenient. Each key ID specifies two independent parts, 135 the authentication protocol and the authentication key, as explained 136 below. Normally, an implementation would allow the network operator 137 to configure a set of keys in a key chain, with each key in the chain 138 having fixed lifetime. The actual operation of these mechanisms is 139 outside the scope of this document. 141 Note that each key ID can indicate a key with a different 142 authentication protocol. This allows multiple authentication 143 mechanisms to be used at various times without disrupting IS-IS 144 peering, including the introduction of new authentication mechanisms. 146 o Authentication Algorithm : This signifies the authentication 147 algorithm to be used with the IS-IS SA. Valid values are HMAC-SHA-1, 148 HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512. 150 o Authentication Key : This value denotes the key associated with the 151 IS-IS SA. The length of this key is variable and depends upon the 152 authentication algorithm specified by the IS-IS SA. 154 3. Authentication Procedures 156 3.1 Authentication TLV 158 A new authentication code, 0x3, indicates the CRYPTO_AUTH mechanism 159 described in this document is in use, is inserted in the first octet 160 of the existing IS-IS Authentication TLV (10). 162 0 1 163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Type 10 | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Auth Type | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Key ID | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 + + 173 | Authentication Data (Variable)| 174 + + 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1 179 3.2 Authentication Process 181 When calculating the CRYPTO_AUTH result for Sequence Number PDUs, 182 Level 1 Sequence Number PDUs SHALL use the Area Authentication string 183 as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use 184 the domain authentication string as in Level 2 Link State PDUs. 186 IS-IS HELLO PDUs SHALL use the Link Level Authentication String, 187 which MAY be different from that of Link State PDUs. The CRYPTO_AUTH 188 result for the IS-IS HELLO PDUs SHALL be calculated after the PDU is 189 padded to the MTU size, if padding is not disabled. Implementations 190 that support the optional checksum for the Sequence Number PDUs and 191 IS-IS HELLO PDUs MUST NOT include the Checksum TLV. 193 3.3 Cryptographic Aspects 194 In the algorithm description below, the following nomenclature, which 195 is consistent with [FIPS-198], is used: 197 H is the specific hashing algorithm (e.g. SHA-256). 198 K is the password for the PDU type as per International 199 Standards Organization 10589 [ISO] 200 Ko is the cryptographic key used with the hash algorithm. 202 B is the block size of H, measured in octets rather than bits. 204 Note that B is the internal block size, not the hash size. 205 For SHA-1 and SHA-256: B == 64 206 For SHA-384 and SHA-512: B == 128 207 L is the length of the hash, measured in octets rather than bits. 209 XOR is the exclusive-or operation. 210 Opad is the hexadecimal value 0x5c repeated B times. 211 Ipad is the hexadecimal value 0x36 repeated B times. 212 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 214 (1)Preparation of the Key 216 In this application, Ko is always L octets long. 218 If the Authentication Key (K) is L octets long, then Ko is equal 219 to K. If the Authentication Key (K) is more than L octets long, 220 then Ko is set to H(K). If the Authentication Key (K) is less 221 than L octets long, then Ko is set to the Authentication Key (K) 222 with zeros appended to the end of the Authentication Key (K) such 223 that Ko is L octets long. 225 (2)First Hash 227 First, the IS-IS packet's Authentication Data field is filled with 228 the value Apad and the Authentication Type field is set to 0x3. 230 Then, a first hash, also known as the inner hash, is computed 231 as follows: 233 First-Hash = H(Ko XOR Ipad || (IS-IS PDU)) 235 (3)Second Hash 237 Then a second hash, also known as the outer hash, is computed 238 as follows: 240 Second-Hash = H(Ko XOR Opad || First-Hash) 242 (4)Result 243 The result Second-Hash becomes the Authentication Data that is 244 sent in the Authentication Data field of the IS-IS PDU. The length 245 of the Authentication Data field is always identical to the 246 message digest size of the specific hash function H that is being 247 used. 249 This also means that the use of hash functions with larger output 250 sizes will also increase the size of the IS-IS PDU as transmitted 251 on the wire. 253 3.4 Procedures at the Sending Side 255 An appropriate IS-IS SA is selected for use with an outgoing IS-IS 256 PDU. This is done based on the active key at that instant. If IS-IS 257 is unable to find an active key, then the PDU is discarded. 259 If IS-IS is able to find the active key, then the key gives the 260 authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, 261 HMAC-SHA-384 or HMAC-SHA-512) that needs to be applied on the PDU. 263 An implementation MUST fill the authentication type and the length 264 before the authentication data is computed. The authentication data 265 is computed as explained in the previous section. The length of the 266 TLV is set as per the authentication algorithm that is being used. 268 It is set to 23 for HMAC-SHA-1, 31 for HMAC-SHA-224, 35 for HMAC-SHA- 269 256, 51 for HMAC-SHA-384 and 67 for HMAC-SHA-512. Note that two 270 octets have been added to account for the Key ID and one octet for 271 the authentication type. 273 The key ID is filled. 275 The Checksum and Remaining Life time fields are set to Zero for the 276 LSPs before authentication is calculated. 278 The result of the authentication algorithm is placed in the 279 Authentication data, following the key ID. 281 The authentication data for the IS-IS IIH PDUs MUST be computed after 282 the IIH has been padded to the MTU size, if padding is not explicitly 283 disabled. 285 3.5 Procedure at the Receiving Side 287 The appropriate IS-IS SA is identified by looking at the Key ID from 288 the Authentication TLV 10 from the incoming IS-IS PDU. 290 Authentication algorithm dependent processing, needs to be performed, 291 using the algorithm specified by the appropriate IS-IS SA for the 292 received packet. 294 Before an implementation performs any processing it needs to save the 295 values of the Authentication Value field, the Checksum and the 296 Remaining Life time. 298 It should then set the Authentication Value field with Apad and zero 299 the Checksum and Remaining Life time fields before the authentication 300 data is computed. The calculated data is compared with the received 301 authentication data in the PDU and the PDU is discarded if the two do 302 not match. In such a case, an error event SHOULD be logged. 304 An implementation MAY have a transition mode where it includes 305 CRYPTO_AUTH information in the PDUs but does not verify this 306 information. This is provided as a transition aid for networks in the 307 process of migrating to the new CRYPTO_AUTH based authentication 308 schemes. 310 4. Security Considerations 312 The document proposes extensions to IS-IS which would make it more 313 secure than what it is today. It does not provide confidentiality as 314 a routing protocol contains information that does not need to be kept 315 secret. It does however, provide means to authenticate the sender of 316 the PDUs which is of interest to us. 318 The technology in this document provides an authentication mechanism 319 for IS-IS. The mechanism described here is not perfect and does not 320 need to be perfect. Instead, this mechanism represents a significant 321 increase in the work function of an adversary attacking the IS-IS 322 protocol, while not causing undue implementation, deployment, or 323 operational complexity. 325 The mechanism detailed in this document does not protect IS-IS 326 against replay attacks. An adversary could in theory replay old IIHs 327 and bring down the adjacency [CRYPTO] or replay old CSNPs and PSNPs 328 that would cause a flood of LSPs in the network. Using some sort of 329 crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to 330 solve this problem. Discussing this is beyond the scope of this 331 document and it is a matter which needs to be followed in the WG. 333 This document states that the remaining lifetime of the LSP MUST be 334 set to zero before computing the authentication, thus this field is 335 not authenticated. This field is excluded so that the LSPs may be 336 aged by the ISes in between without requiring to recompute the 337 authentication data. This can be exploited by an attacker. 339 There is a transition mode suggested where routers can ignore the 340 CRYPTO_AUTH information carried in the PDUs. The operator must ensure 341 that this mode is only used when migrating to the new CRYPTO_AUTH 342 based authentication scheme as this leaves the router vulnerable to 343 an attack. 345 To ensure greater security, the keys used must be changed 346 periodically and implementations MUST be able to store and use more 347 than one key at the same time. 349 It should be noted that the cryptographic strength of the HMAC 350 depends upon the cryptographic strength of the underlying hash 351 function and on the size and quality of the key. 353 If a stronger authentication were believed to be required, then the 354 use of a full digital signature [RFC-2154] would be an approach that 355 should be seriously considered. It was rejected for this purpose at 356 this time because the computational burden of full digital signatures 357 is believed to be much higher than is reasonable given the current 358 threat environment in operational commercial networks. 360 5. Acknowledgements 362 The authors would like to thank Hugo Krawczyk, Arjen K. Lenstra (Bell 363 Labs) and Eric Grosse (Bell Labs) for educating us on some of the 364 finer points related to Crypto Mathematics. 366 We would also like to thank Bill Burr, Tim Polk, John Kelsey, and 367 Morris Dworkin of (US) NIST for review of portions of this document 368 that are directly derived from the closely related work on RIPv2 369 Cryptographic Authentication [RFC-4822]. 371 6. IANA Considerations 373 IANA needs to give value for the CRYPTO_AUTH field in the 374 authentication TLV 10. This document currently defines a value 375 of 0x3 to be used to denote CRYPTO_AUTH mechanism for authenticating 376 IS-IS PDUs. 378 7. References 380 7.1 Normative References 382 [ISO] "Intermediate system to Intermediate system routeing 383 information exchange protocol for use in conjunction with 384 the Protocol for providing the Connectionless-mode Network 385 Service (ISO 8473)", ISO/IEC 10589:1992 387 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 388 dual environments", RFC 1195, December 1990. 390 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119 393 [RFC5304] Li, T. and Atkinson, R. "Intermediate System to 394 Intermediate System (IS-IS) Cryptographic Authentication", 395 RFC 5304, October 2008. 397 [RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message 398 Authentication", RFC 2104, February 1997 400 [NIST] National Institute of Standards and Technology, "Secure 401 Hash Standard", FIPS PUB 180-2, August 2002 403 [FIPS-198] US National Institute of Standards & Technology, "The 404 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 405 198, March 2002. 407 7.2 Informative References 409 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical 410 Report, 2 May 1996. (Presented at the Rump Session of 411 EuroCrypt 1996.) 413 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", 414 CryptoBytes, Vol. 2, No. 2, Summer 1996. 416 [CRYPTO] Manral, V. et al., "Issues with existing Cryptographic 417 Protection Methods for Routing Protocols", Work in 418 Progress, February 2006 420 [RFC-2154] S. Murphy, M. Badger, and B. Wellington, "OSPF with 421 Digital Signatures", RFC 2154, June 1997. 423 [RFC-4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic 424 Authentication", RFC 4822, February 2007. 426 8. Author's Addresses 428 Manav Bhatia 429 Alcatel-Lucent 430 Bangalore, India 431 Email: manav@alcatel-lucent.com 433 Tony Li 434 Redback Networks Inc. 435 300 Holger Way 436 San Jose CA 95134 437 USA 438 EMail: tony.li@tony.li 440 Vishwas Manral 441 IP Infusion 442 Almora, Uttarakhand 443 India 444 Email: vishwas@ipinfusion.com 446 Russ White 447 Cisco Systems 448 RTP North Carolina 449 USA 450 Email: riw@cisco.com 452 Randall J. Atkinson 453 Extreme Networks 454 3585 Monroe Street 455 Santa Clara, CA 95051 456 USA 457 Email: rja@extremenetworks.com 459 Matthew J. Fanto 460 Ciber Inc. 461 Dearborn, Mi 462 USA 463 Email: mfanto@ciber.com 465 Full Copyright Statement 467 Copyright (C) The IETF Trust (2008). 469 This document is subject to the rights, licenses and restrictions 470 contained in BCP 78, and except as set forth therein, the authors 471 retain all their rights. 473 This document and the information contained herein are provided on an 474 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 475 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 476 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 477 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 478 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 479 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 481 Intellectual Property 483 The IETF takes no position regarding the validity or scope of any 484 Intellectual Property Rights or other rights that might be claimed 485 to pertain to the implementation or use of the technology described 486 in this document or the extent to which any license under such rights 487 might or might not be available; nor does it represent that it has 488 made any independent effort to identify any such rights. Information 489 on the procedures with respect to rights in RFC documents can be 490 found in BCP 78 and BCP 79. 492 Copies of IPR disclosures made to the IETF Secretariat and any 493 assurances of licenses to be made available, or the result of an 494 attempt made to obtain a general license or permission for the use 495 of such proprietary rights by implementers or users of this 496 specification can be obtained from the IETF on-line IPR repository 497 at http://www.ietf.org/ipr. 499 The IETF invites any interested party to bring to its attention any 500 copyrights, patents or patent applications, or other proprietary 501 rights that may cover technology that may be required to implement 502 this standard. Please address the information to the IETF at ietf- 503 ipr@ietf.org.