idnits 2.17.1 draft-ietf-isis-hmac-sha-05.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 3978, Section 5.5, updated by RFC 4748 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 537. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 187 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 (October 2008) is 5670 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' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft IS-IS Generic Cryptographic Authentication October 2008 3 Network Working Group Manav Bhatia 4 Internet Draft Alcatel-Lucent 5 Expires: March 2009 Vishwas Manral 6 IP Infusion 7 (Editors) 9 IS-IS Generic Cryptographic Authentication 11 draft-ietf-isis-hmac-sha-05.txt 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 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups 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 29 material 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 proposes an extension to IS-IS to allow the use of any 40 cryptographic authentication algorithm in addition to the already 41 documented authentication schemes, described in the base 42 specification and RFC 5304. 44 Although this document has been written specifically for using HMAC 45 construct along with the SHA family of cryptographic hash functions, 46 the method described in this document is generic and can be used to 47 extend IS-IS to support any cryptographic hash function in the 48 future. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119. [KEYWORDS] 56 Contents 58 1. Introduction...................................................2 59 2. IS-IS Security Association.....................................3 60 3. Authentication Procedures......................................4 61 3.1 Authentication TLV.........................................4 62 Figure 1..........................................................4 63 3.2 Authentication Process.....................................4 64 3.3 Cryptographic Aspects......................................4 65 3.4 Procedures at the Sending Side.............................6 66 3.5 Procedure at the Receiving Side............................6 67 4. Security Considerations........................................7 68 5. Acknowledgements...............................................8 69 6. IANA Considerations............................................8 70 7. References.....................................................9 71 7.1 Normative References.......................................9 72 7.2 Informative References.....................................9 73 8. Author's Addresses............................................10 75 1. Introduction 77 IS-IS [ISO] [RFC1195] specification allows for authentication of its 78 PDUs via the authentication TLV 10 that is carried as the part of the 79 PDU. The base spec has provision for only clear text passwords and 80 RFC 5304 [RFC5304] augments this to provide the capability to use 81 HMAC MD5 authentication for its PDUs. 83 The first octet of value field of TLV 10 specifies the type of 84 authentication to be carried out. Type 0 is reserved, Type 1 85 indicates a cleartext password, Type 54 indicates HMAC MD5 and Type 86 255 is used for routing domain private authentication methods. The 87 remainder of the value field contains the actual authentication data 88 determined by the value of the authentication type. 90 This document proposes a new authentication type to be carried in TLV 91 10, called the generic cryptographic authentication (CRYPTO_AUTH). 92 This can be used to specify any authentication algorithm for 93 authenticating and verifying IS-IS PDUs. 95 This document also explains how HMAC-SHA authentication can be used 96 in IS-IS. 98 By definition, HMAC [RFC2104] requires a cryptographic hash function. 99 We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384 and 100 SHA-512 [NIST] for this purpose to authenticate the IS-IS PDUs. 102 We propose to do away with the per interface keys and instead have 103 key IDs that map to unique IS-IS Security Associations. 105 While there are no openly published attacks on the HMAC-MD5 106 mechanism, some reports [Dobb96a, Dobb96b] create concern about the 107 ultimate strength of the MD5 cryptographic hash function. 109 2. IS-IS Security Association 111 An IS-IS Security Association (SA) contains a set of shared 112 parameters between any two legitimate IS-IS speakers. 114 Parameters associated with an IS-IS SA: 116 o Key ID : This is a one octet unsigned integer used to uniquely 117 identify an IS-IS SA, as manually configured by the network operator. 118 The receiver determines the active SA by looking at this field in the 119 incoming PDU. The sender puts this Key ID based on the active 120 configuration. 122 Using key IDs makes changing keys while maintaining protocol 123 operation convenient. Each key ID specifies two independent parts, 124 the authentication protocol and the authentication key, as explained 125 below. Normally, an implementation would allow the network operator 126 to configure a set of keys in a key chain, with each key in the chain 127 having fixed lifetime. The actual operation of these mechanisms is 128 outside the scope of this document. 130 Note that each key ID can indicate a key with a different 131 authentication protocol. This allows multiple authentication 132 mechanisms to be used at various times without disrupting IS-IS 133 peering, including the introduction of new authentication mechanisms. 135 o Authentication Algorithm : This signifies the authentication 136 algorithm to be used with the IS-IS SA. Valid values are HMAC-SHA-1, 137 HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512. 139 o Authentication Key : This value denotes the key associated with the 140 IS-IS SA. The length of this key is variable and depends upon the 141 authentication algorithm specified by the IS-IS SA. 143 3. Authentication Procedures 145 3.1 Authentication TLV 147 A new authentication code, 0x3, indicates the CRYPTO_AUTH mechanism 148 described in this document is in use, is inserted in the first octet 149 of the existing IS-IS Authentication TLV (10). 151 0 1 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type 10 | Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Auth Type | Key ID | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 + + 160 | Authentication Data (Variable)| 161 + + 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1 166 3.2 Authentication Process 168 When calculating the CRYPTO_AUTH result for Sequence Number PDUs, 169 Level 1 Sequence Number PDUs SHALL use the Area Authentication string 170 as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use 171 the domain authentication string as in Level 2 Link State PDUs. 173 IS-IS HELLO PDUs SHALL use the Link Level Authentication String, 174 which MAY be different from that of Link State PDUs. The CRYPTO_AUTH 175 result for the IS-IS HELLO PDUs SHALL be calculated after the PDU is 176 padded to the MTU size, if padding is not disabled. Implementations 177 that support the optional checksum for the Sequence Number PDUs and 178 IS-IS HELLO PDUs MUST NOT include the Checksum TLV. 180 3.3 Cryptographic Aspects 182 In the algorithm description below, the following nomenclature, which 183 is consistent with [FIPS-198], is used: 185 H is the specific hashing algorithm (e.g. SHA-256). 186 K is the password for the PDU type as per ISO 10589. 187 Ko is the cryptographic key used with the hash algorithm. 189 B is the block size of H, measured in octets rather than bits. 191 Note that B is the internal block size, not the hash size. 193 For SHA-1 and SHA-256: B == 64 194 For SHA-384 and SHA-512: B == 128 195 L is the length of the hash, measured in octets rather than bits. 197 XOR is the exclusive-or operation. 198 Opad is the hexadecimal value 0x5c repeated B times. 199 Ipad is the hexadecimal value 0x36 repeated B times. 200 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 202 (1)Preparation of the Key 204 In this application, Ko is always L octets long. 206 If the Authentication Key (K) is L octets long, then Ko is equal 207 to K. If the Authentication Key (K) is more than L octets long, 208 then Ko is set to H(K). If the Authentication Key (K) is less 209 than L octets long, then Ko is set to the Authentication Key (K) 210 with zeros appended to the end of the Authentication Key (K) such 211 that Ko is L octets long. 213 (2)First Hash 215 First, the IS-IS packet's Authentication Data field is filled with 216 the value Apad and the Authentication Type field is set to 0x3. 218 Then, a first hash, also known as the inner hash, is computed 219 as follows: 221 First-Hash = H(Ko XOR Ipad || (IS-IS PDU)) 223 (3)Second Hash 225 Then a second hash, also known as the outer hash, is computed 226 as follows: 228 Second-Hash = H(Ko XOR Opad || First-Hash) 230 (4)Result 232 The result Second-Hash becomes the Authentication Data that is 233 sent in the Authentication Data field of the IS-IS PDU. The length 234 of the Authentication Data field is always identical to the 235 message digest size of the specific hash function H that is being 236 used. 238 This also means that the use of hash functions with larger output 239 sizes will also increase the size of the IS-IS PDU as transmitted 240 on the wire. 242 3.4 Procedures at the Sending Side 244 An appropriate IS-IS SA is selected for use with an outgoing IS-IS 245 PDU. This is done based on the active key at that instant. If IS-IS 246 is unable to find an active key, then the PDU is discarded. 248 If IS-IS is able to find the active key, then the key gives the 249 authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, 250 HMAC-SHA-384 or HMAC-SHA-512) that needs to be applied on the PDU. 252 An implementation MUST fill the authentication type and the length 253 before the authentication data is computed. The authentication data 254 is computed as explained in the previous section. The length of the 255 TLV is set as per the authentication algorithm that is being used. 257 It's set to 22 for HMAC-SHA-1, 30 for HMAC-SHA-224, 34 for HMAC-SHA- 258 256, 50 for HMAC-SHA-384 and 66 for HMAC-SHA-512. Note that one octet 259 has been added to account for the Key ID and one octet for the 260 authentication type. 262 The key ID is filled. 264 The Checksum and Remaining Life time fields are set to Zero for the 265 LSPs before authentication is calculated. 267 The result of the authentication algorithm is placed in the 268 Authentication data, following the key ID. 270 The authentication data for the IS-IS IIH PDUs MUST be computed after 271 the IIH has been padded to the MTU size, if padding is not explicitly 272 disabled. 274 3.5 Procedure at the Receiving Side 276 The appropriate IS-IS SA is identified by looking at the Key ID from 277 the Authentication TLV 10 from the incoming IS-IS PDU. 279 Authentication algorithm dependent processing, needs to be performed, 280 using the algorithm specified by the appropriate IS-IS SA for the 281 received packet. 283 Before an implementation performs any processing it needs to save the 284 values of the Authentication Value field, the Checksum and the 285 Remaining Life time. 287 It should then set the Authentication Value field with Apad and zero 288 the Checksum and Remaining Life time fields before the authentication 289 data is computed. The calculated data is compared with the received 290 authentication data in the PDU and the PDU is discarded if the two do 291 not match. In such a case, an error event SHOULD be logged. 293 An implementation MAY have a transition mode where it includes 294 CRYPTO_AUTH information in the PDUs but does not verify this 295 information. This is provided as a transition aid for networks in the 296 process of migrating to the new CRYPTO_AUTH based authentication 297 schemes. 299 Similarly, implementations not supporting the CRYPTO_AUTH field MAY 300 accept PDUs that contain this particular field in TLV 10. 302 4. Security Considerations 304 The document proposes extensions to IS-IS which would make it more 305 secure than what it is today. It does not provide confidentiality as 306 a routing protocol contains information that does not need to be kept 307 secret. It does however, provide means to authenticate the sender of 308 the PDUs which is of interest to us. 310 The technology in this document provides an authentication mechanism 311 for IS-IS. The mechanism described here is not perfect and does not 312 need to be perfect. Instead, this mechanism represents a significant 313 increase in the work function of an adversary attacking the IS-IS 314 protocol, while not causing undue implementation, deployment, or 315 operational complexity. 317 The mechanism detailed in this document does not protect IS-IS 318 against replay attacks. An adversary could in theory replay old IIHs 319 and bring down the adjacency [CRYPTO] or replay old CSNPs and PSNPs 320 that would cause a flood of LSPs in the network. Using some sort of 321 crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to 322 solve this problem. Discussing this is beyond the scope of this 323 document and it's a matter which needs to be followed in the WG. 325 This document states that the remaining lifetime of the LSP MUST be 326 set to zero before computing the authentication, thus this field is 327 not authenticated. This field is excluded so that the LSPs may be 328 aged by the ISes in between without requiring to recompute the 329 authentication data. This can be exploited by an attacker. 331 To ensure greater security, the keys used must be changed 332 periodically and implementations MUST be able to store and use more 333 than one key at the same time. 335 It should be noted that the cryptographic strength of the HMAC 336 depends upon the cryptographic strength of the underlying hash 337 function and on the size and quality of the key. 339 If a stronger authentication were believed to be required, then the 340 use of a full digital signature [RFC-2154] would be an approach that 341 should be seriously considered. It was rejected for this purpose at 342 this time because the computational burden of full digital signatures 343 is believed to be much higher than is reasonable given the current 344 threat environment in operational commercial networks. 346 5. Acknowledgements 348 The authors would like to thank Hugo Krawczyk, Arjen K. Lenstra (Bell 349 Labs) and Eric Grosse (Bell Labs) for educating us on some of the 350 finer points related to Crypto Mathematics. 352 We would also like to thank Bill Burr, Tim Polk, John Kelsey, and 353 Morris Dworkin of (US) NIST for review of portions of this document 354 that are directly derived from the closely related work on RIPv2 355 Cryptographic Authentication [RFC-4822]. 357 6. IANA Considerations 359 This document requests that IANA create a new code point registry to 360 administer the Authentication Type code points for TLV 10. This 361 registry would be part of the existing IS-IS code points registry as 362 established by [RFC-3563] and [RFC-3359]. This registry should be 363 managed using the Designated Expert policy as described in [RFC-5226] 364 and will be called IS-IS Authentication Type Codes. 366 The values in the IS-IS Authentication Type Codes registry should be 367 recorded in decimal and should only be approved after a designated 368 expert, appointed by the IESG area director, has been consulted. 369 The intention is that any allocation will be accompanied by a 370 published RFC. However, the Designated Expert can approve 371 allocations once it seems clear that an RFC will be published, 372 allowing for the allocation of values prior to the document being 373 approved for publication as an RFC. New items should be documented in 374 a publicly and freely available specification. We should also have 375 the provision of allowing external specifications to allocate and use 376 the IS-IS Authentication Type Codes maintained by this registry. 378 Initial values for the IS-IS Authentication Type Codes registry are 379 given below; future assignments are to be made through Expert Review. 380 Assignments consist of an authentication type name and its associated 381 value. 383 Authentication Type Code Value Reference 384 ------------------------ ------ --------- 386 Reserved 0 [ISO] 387 Cleartext Password 1 [ISO] 388 ISO 10589 Reserved 2 [ISO] 389 Cryptographic Authentication 3 390 HMAC-MD5 Authentication 54 [RFC5304] 391 Routeing Domain private authentication method 255 [ISO] 393 This document currently defines and uses the value 3 to foster 394 prestandard implementations. 396 7. References 398 7.1 Normative References 400 [ISO] "Intermediate system to Intermediate system routeing 401 information exchange protocol for use in conjunction with 402 the Protocol for providing the Connectionless-mode Network 403 Service (ISO 8473)", ISO/IEC 10589:1992 405 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 406 dual environments", RFC 1195, December 1990. 408 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119 411 [RFC5304] Li, T. and Atkinson, R. "Intermediate System to 412 Intermediate System (IS-IS) Cryptographic Authentication", 413 RFC 5304, October 2008. 415 [RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message 416 Authentication", RFC 2104, February 1997 418 [NIST] National Institute of Standards and Technology, "Secure 419 Hash Standard", FIPS PUB 180-2, August 2002 421 [FIPS-198] US National Institute of Standards & Technology, "The 422 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 423 198, March 2002. 425 7.2 Informative References 427 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical 428 Report, 2 May 1996. (Presented at the Rump Session of 429 EuroCrypt 1996.) 431 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", 432 CryptoBytes, Vol. 2, No. 2, Summer 1996. 434 [CRYPTO] Manral, V. et al., "Issues with existing Cryptographic 435 Protection Methods for Routing Protocols", Work in 436 Progress, February 2006 438 [RFC-2154] S. Murphy, M. Badger, and B. Wellington, "OSPF with 439 Digital Signatures", RFC 2154, June 1997. 441 [RFC-4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic 442 Authentication", RFC 4822, February 2007. 444 [RFC-3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 445 Codepoints in Intermediate System to Intermediate System", 446 RFC 3359, August 2002. 448 [RFC-3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 449 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 450 (JTC1/SC6) on IS-IS Routing Protocol Development", 451 RFC 3563, July 2003. 453 [RFC-5226] Narten, T. and Alvestrand, H., "Guidelines for Writing 454 an IANA Considerations Section in RFCs", RFC 5226, May 455 2008. 457 8. Author's Addresses 459 Manav Bhatia 460 Alcatel-Lucent 461 Bangalore, India 462 Email: manav@alcatel-lucent.com 464 Tony Li 465 Cisco Systems 466 San Jose, CA 467 USA 468 EMail: tli@cisco.com 470 Vishwas Manral 471 IP Infusion 472 Almora, Uttarakhand 473 India 474 Email: vishwas@ipinfusion.com 476 Bhatia, Manral, et. al. Expires March 2009 [Page 477 10] 478 Russ White 479 Cisco Systems 480 RTP North Carolina 481 USA 482 Email: riw@cisco.com 484 Randall J. Atkinson 485 Extreme Networks 486 3585 Monroe Street 487 Santa Clara, CA 95051 488 USA 489 Email: rja@extremenetworks.com 491 Matthew J. Fanto 492 Ciber Inc. 493 Dearborn, Mi 494 USA 495 Email: mfanto@ciber.com 497 Full Copyright Statement 499 Copyright (C) The IETF Trust (2008). 501 This document is subject to the rights, licenses and restrictions 502 contained in BCP 78, and except as set forth therein, the authors 503 retain all their rights. 505 This document and the information contained herein are provided on an 506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 508 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 509 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 510 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Intellectual Property 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed 517 to pertain to the implementation or use of the technology described 518 in this document or the extent to which any license under such rights 519 might or might not be available; nor does it represent that it has 520 made any independent effort to identify any such rights. Information 521 on the procedures with respect to rights in RFC documents can be 522 found in BCP 78 and BCP 79. 524 Bhatia, Manral, et. al. Expires March 2009 [Page 525 11] 526 Copies of IPR disclosures made to the IETF Secretariat and any 527 assurances of licenses to be made available, or the result of an 528 attempt made to obtain a general license or permission for the use 529 of such proprietary rights by implementers or users of this 530 specification can be obtained from the IETF on-line IPR repository 531 at http://www.ietf.org/ipr. 533 The IETF invites any interested party to bring to its attention any 534 copyrights, patents or patent applications, or other proprietary 535 rights that may cover technology that may be required to implement 536 this standard. Please address the information to the IETF at ietf- 537 ipr@ietf.org. 539 Bhatia, Manral, et. al. Expires March 2009 [Page 540 12]