idnits 2.17.1 draft-ietf-isis-hmac-sha-07.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 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. 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 221 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 5274 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) == Missing Reference: 'RFC4086' is mentioned on line 379, but not defined == Missing Reference: 'RFC-4822' is mentioned on line 402, but not defined == Unused Reference: 'RFC4822' is defined on line 467, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' Summary: 2 errors (**), 0 flaws (~~), 5 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-07.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. IS-IS is specified in International Standards Organization 51 (ISO) 10589, with extensions to support Internet Protocol version 4 52 (IPv4) described in RFC 1195. 54 Although this document has been written specifically for using the 55 Hashed Message Authentication Code (HMAC) construct along with the 56 Secure Hash Algorithm (SHA) family of cryptographic hash functions, 57 the method described in this document is generic and can be used to 58 extend IS-IS to support any cryptographic hash function in the 59 future. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119. [RFC2119] 67 Contents 69 1. Introduction...................................................2 70 2. IS-IS Security Association.....................................3 71 3. Authentication Procedures......................................4 72 3.1 Authentication TLV.........................................4 73 3.2 Authentication Process.....................................5 74 3.3 Cryptographic Aspects......................................5 75 3.4 Procedures at the Sending Side.............................6 76 3.5 Procedure at the Receiving Side............................7 77 4. Security Considerations........................................8 78 5. Acknowledgements...............................................9 79 6. IANA Considerations............................................9 80 7. References.....................................................9 81 7.1 Normative References.......................................9 82 7.2 Informative References....................................10 83 8. Author's Addresses............................................10 85 1. Introduction 87 Intermediate System to Intermediate System (IS-IS) specification 88 [ISO] [RFC1195] allows for authentication of its Protocol Data Units 89 (PDUs) via the authentication TLV 10 that is carried as a part of the 90 PDU. The base specification has provision for only clear text 91 passwords and RFC 5304 [RFC5304] augments this to provide the 92 capability to use Hashed Message Authentication Code - Message Digest 93 5 (HMAC-MD5) authentication for its PDUs. 95 The first octet of the value field of TLV 10 specifies the type of 96 authentication to be carried out. Type 0 is reserved, Type 1 97 indicates a cleartext password, Type 54 indicates HMAC MD5 and Type 98 255 is used for routing domain private authentication methods. The 99 remainder of the value field contains the actual authentication data 100 determined by the value of the authentication type. 102 This document proposes a new authentication type to be carried in TLV 103 10, called the generic cryptographic authentication (CRYPTO_AUTH). 104 This can be used to specify any authentication algorithm for 105 authenticating and verifying IS-IS PDUs. 107 This document also explains how HMAC-SHA authentication can be used 108 in IS-IS. 110 By definition, HMAC [RFC2104] requires a cryptographic hash function. 111 We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384 and 112 SHA-512 [FIPS-180-3] for this purpose to authenticate the IS-IS PDUs. 114 We propose to do away with the per interface keys and instead have 115 key IDs that map to unique IS-IS Security Associations (SA). 117 While at the time of this writing there are no openly published 118 attacks on the HMAC-MD5 mechanism, some reports [Dobb96a, Dobb96b] 119 create concern about the ultimate strength of the MD5 cryptographic 120 hash function. 122 The mechanism described in this document does not provide 123 confidentiality, since PDUs are sent in the clear. However, the 124 objective of a routing protocol is to advertise the routing topology, 125 and confidentiality is not normally required for routing protocols. 127 2. IS-IS Security Association 129 An IS-IS Security Association contains a set of parameters shared 130 between any two legitimate IS-IS speakers. 132 Parameters associated with an IS-IS SA: 134 O Key Identifier (Key ID) : This is a two octet unsigned integer used 135 to uniquely identify an IS-IS SA, as manually configured by the 136 network operator. 138 The receiver determines the active SA by looking at the Key ID field 139 in the incoming PDU. 141 The sender based on the active configuration, selects the Security 142 Association to use and puts the correct Key ID value associated with 143 the Security Association in the IS-IS PDU. If multiple valid and 144 active IS-IS Security Associations exist for a given outbound 145 interface at the time an IS-IS PDU is sent, the sender may use any of 146 those security associations to protect the packet. 148 Using key IDs makes changing keys while maintaining protocol 149 operation convenient. Each key ID specifies two independent parts, 150 the authentication protocol and the authentication key, as explained 151 below. Normally, an implementation would allow the network operator 152 to configure a set of keys in a key chain, with each key in the chain 153 having fixed lifetime. The actual operation of these mechanisms is 154 outside the scope of this document. 156 Note that each key ID can indicate a key with a different 157 authentication protocol. This allows multiple authentication 158 mechanisms to be used at various times without disrupting an IS-IS 159 peering, including the introduction of new authentication mechanisms. 161 o Authentication Algorithm : This signifies the authentication 162 algorithm to be used with the IS-IS SA. This information is never 163 sent in cleartext over the wire. Because this information is not sent 164 on the wire, the implementer chooses an implementation specific 165 representation for this information. At present, the following values 166 are possible: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 167 and HMAC-SHA-512. 169 o Authentication Key : This value denotes the cryptographic 170 authentication key associated with the IS-IS SA. The length of this 171 key is variable and depends upon the authentication algorithm 172 specified by the IS-IS SA. 174 3. Authentication Procedures 176 3.1 Authentication TLV 178 A new authentication code, 3, indicates the CRYPTO_AUTH mechanism 179 described in this document is in use, is inserted in the first octet 180 of the existing IS-IS Authentication TLV (10). 182 0 1 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type 10 | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Auth Type | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Key ID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 + + 193 | Authentication Data (Variable)| 194 + + 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 1 199 3.2 Authentication Process 201 When calculating the CRYPTO_AUTH result for Sequence Number PDUs, 202 Level 1 Sequence Number PDUs SHALL use the Area Authentication string 203 as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use 204 the domain authentication string as in Level 2 Link State PDUs. 206 IS-IS HELLO PDUs SHALL use the Link Level Authentication String, 207 which MAY be different from that of Link State PDUs. The CRYPTO_AUTH 208 result for the IS-IS HELLO PDUs SHALL be calculated after the PDU is 209 padded to the MTU size, if padding is not disabled. Implementations 210 that support the optional checksum for the Sequence Number PDUs and 211 IS-IS HELLO PDUs MUST NOT include the Checksum TLV. 213 3.3 Cryptographic Aspects 215 In the algorithm description below, the following nomenclature, which 216 is consistent with [FIPS-198], is used: 218 H is the specific hashing algorithm (e.g. SHA-256). 219 K is the password for the PDU type as per the International 220 Standard ISO/IEC 10589 [ISO]. 221 Ko is the cryptographic key used with the hash algorithm. 223 B is the block size of H, measured in octets rather than bits. 225 Note that B is the internal block size, not the hash size. 226 For SHA-1 and SHA-256: B == 64 227 For SHA-384 and SHA-512: B == 128 228 L is the length of the hash, measured in octets rather than bits. 230 XOR is the exclusive-or operation. 232 Opad is the hexadecimal value 0x5c repeated B times. 233 Ipad is the hexadecimal value 0x36 repeated B times. 234 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 236 (1)Preparation of the Key 238 In this application, Ko is always L octets long. 240 If the Authentication Key (K) is L octets long, then Ko is equal 241 to K. If the Authentication Key (K) is more than L octets long, 242 then Ko is set to H(K). If the Authentication Key (K) is less 243 than L octets long, then Ko is set to the Authentication Key (K) 244 with zeros appended to the end of the Authentication Key (K) such 245 that Ko is L octets long. 247 (2)First Hash 249 First, the IS-IS packet's Authentication Data field is filled with 250 the value Apad and the Authentication Type field is set to 0x3. 252 Then, a first hash, also known as the inner hash, is computed 253 as follows: 255 First-Hash = H(Ko XOR Ipad || (IS-IS PDU)) 257 (3)Second Hash 259 Then a second hash, also known as the outer hash, is computed 260 as follows: 262 Second-Hash = H(Ko XOR Opad || First-Hash) 264 (4)Result 266 The result Second-Hash becomes the Authentication Data that is 267 sent in the Authentication Data field of the IS-IS PDU. The length 268 of the Authentication Data field is always identical to the 269 message digest size of the specific hash function H that is being 270 used. 272 This also means that the use of hash functions with larger output 273 sizes will also increase the size of the IS-IS PDU as transmitted 274 on the wire. 276 3.4 Procedures at the Sending Side 278 An appropriate IS-IS SA is selected for use with an outgoing IS-IS 279 PDU. This is done based on the active key at that instant. If IS-IS 280 is unable to find an active key, then the PDU is discarded. 282 If IS-IS is able to find the active key, then the key gives the 283 authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, 284 HMAC-SHA-384 or HMAC-SHA-512) that needs to be applied on the PDU. 286 An implementation MUST fill the authentication type and the length 287 before the authentication data is computed. The authentication data 288 is computed as explained in the previous section. The length of the 289 TLV is set as per the authentication algorithm that is being used. 291 The length is set to 23 for HMAC-SHA-1, 31 for HMAC-SHA-224, 35 for 292 HMAC-SHA-256, 51 for HMAC-SHA-384 and 67 for HMAC-SHA-512. Note that 293 two octets have been added to account for the Key ID and one octet 294 for the authentication type. 296 The key ID is filled. 298 The Checksum and Remaining Life time fields are set to Zero for the 299 LSPs before authentication is calculated. 301 The result of the authentication algorithm is placed in the 302 Authentication data, following the key ID. 304 The authentication data for the IS-IS IIH PDUs MUST be computed after 305 the IIH has been padded to the MTU size, if padding is not explicitly 306 disabled. 308 3.5 Procedure at the Receiving Side 310 The appropriate IS-IS SA is identified by looking at the Key ID from 311 the Authentication TLV 10 from the incoming IS-IS PDU. 313 Authentication algorithm dependent processing, needs to be performed, 314 using the algorithm specified by the appropriate IS-IS SA for the 315 received packet. 317 Before an implementation performs any processing it needs to save the 318 values of the Authentication Value field, the Checksum and the 319 Remaining Life time. 321 It should then set the Authentication Value field with Apad and zero 322 the Checksum and Remaining Life time fields before the authentication 323 data is computed. The calculated data is compared with the received 324 authentication data in the PDU and the PDU is discarded if the two do 325 not match. In such a case, an error event SHOULD be logged. 327 An implementation MAY have a transition mode where it includes 328 CRYPTO_AUTH information in the PDUs but does not verify this 329 information. This is provided as a transition aid for networks in the 330 process of migrating to the new CRYPTO_AUTH based authentication 331 schemes. 333 4. Security Considerations 335 The document proposes extensions to IS-IS which would make it more 336 secure than what it is today. It does not provide confidentiality as 337 a routing protocol contains information that does not need to be kept 338 secret. It does, however, provide means to authenticate the sender of 339 the PDUs which is of interest to us. 341 It should be noted that authentication method described in this 342 document is not being used to authenticate the specific originator of 343 a PDU, but is rather being used to confirm that the PDU has indeed 344 been issued by an intermediate system which had access to the area or 345 the domain password, depending upon the kind of PDU it is. 347 The mechanism described here is not perfect and does not need to be 348 perfect. Instead, this mechanism represents a significant increase in 349 the work function of an adversary attacking the IS-IS 350 protocol, while not causing undue implementation, deployment, or 351 operational complexity. 353 The mechanism detailed in this document does not protect IS-IS 354 against replay attacks. An adversary could in theory replay old IIHs 355 and bring down the adjacency [CRYPTO] or replay old CSNPs and PSNPs 356 that would cause a flood of LSPs in the network. Using some sort of 357 crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to 358 solve this problem. Discussing this is beyond the scope of this 359 document. 361 This document states that the remaining lifetime of the LSP MUST be 362 set to zero before computing the authentication, thus this field is 363 not authenticated. This field is excluded so that the LSPs may be 364 aged by the ISes in between without requiring to recompute the 365 authentication data. This can be exploited by an attacker. 367 There is a transition mode suggested where routers can ignore the 368 CRYPTO_AUTH information carried in the PDUs. The operator must ensure 369 that this mode is only used when migrating to the new CRYPTO_AUTH 370 based authentication scheme as this leaves the router vulnerable to 371 an attack. 373 To ensure greater security, the keys used should be changed 374 periodically and implementations MUST be able to store and use more 375 than one key at the same time. Operators should ensure that the 376 authentication key is never sent over the network in clear-text via 377 any protocol. Care should also be taken to ensure that the selected 378 key is unpredictable, avoiding any keys known to be weak for the 379 algorithm in use. [RFC4086] contains helpful information on both key 380 generation techniques and cryptographic randomness. 382 It should be noted that the cryptographic strength of the HMAC 383 depends upon the cryptographic strength of the underlying hash 384 function and on the size and quality of the key. 386 If a stronger authentication were believed to be required, then the 387 use of a full digital signature [RFC2154] would be an approach that 388 should be seriously considered. It was rejected for this purpose at 389 this time because the computational burden of full digital signatures 390 is believed to be much higher than is reasonable given the current 391 threat environment in operational commercial networks. 393 5. Acknowledgements 395 The authors would like to thank Hugo Krawczyk, Arjen K. Lenstra (Bell 396 Labs) and Eric Grosse (Bell Labs) for educating us on some of the 397 finer points related to Crypto Mathematics. 399 We would also like to thank Bill Burr, Tim Polk, John Kelsey, and 400 Morris Dworkin of (US) NIST for review of portions of this document 401 that are directly derived from the closely related work on RIPv2 402 Cryptographic Authentication [RFC-4822]. 404 We would also like to mention Alfred Hoenes for his careful and 405 detailed review during the last call. 407 6. IANA Considerations 409 Upon publication of this RFC, IANA shall register the pre-allocated 410 value for the CRYPTO_AUTH method in the "IS-IS Authentication Type 411 Codes for TLV 10" subregistry established by [RFC5304]. 413 This document currently defines the value 3 to be used to denote the 414 CRYPTO_AUTH mechanism for authenticating IS-IS PDUs. 416 +--------------------------------------------+-------+-------------+ 417 | Authentication Type Code | Value | Reference | 418 +--------------------------------------------+-------+-------------+ 419 | Cryptographic Authentication (CRYPTO_AUTH) | 3 | RFC {this} | 420 +--------------------------------------------+-------+-------------+ 422 7. References 424 7.1 Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119 429 [ISO] "Intermediate system to Intermediate system routeing 430 information exchange protocol for use in conjunction with 431 the Protocol for providing the Connectionless-mode Network 432 Service (ISO 8473)", ISO/IEC 10589:1992 434 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 435 dual environments", RFC 1195, December 1990. 437 [RFC5304] Li, T. and Atkinson, R. "Intermediate System to 438 Intermediate System (IS-IS) Cryptographic Authentication", 439 RFC 5304, October 2008. 441 [RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message 442 Authentication", RFC 2104, February 1997 444 [FIPS-180-3] National Institute of Standards and Technology, "Secure 445 Hash Standard (SHS)", FIPS PUB 180-3, October 2008 447 [FIPS-198] US National Institute of Standards & Technology, "The 448 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 449 198, March 2002. 451 7.2 Informative References 453 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical 454 Report, 2 May 1996. (Presented at the Rump Session of 455 EuroCrypt 1996.) 457 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", 458 CryptoBytes, Vol. 2, No. 2, Summer 1996. 460 [CRYPTO] Manral, V. et al., "Issues with existing Cryptographic 461 Protection Methods for Routing Protocols", Work in 462 Progress, February 2006 464 [RFC2154] S. Murphy, M. Badger, and B. Wellington, "OSPF with 465 Digital Signatures", RFC 2154, June 1997. 467 [RFC4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic 468 Authentication", RFC 4822, February 2007. 470 8. Author's Addresses 472 Manav Bhatia 473 Alcatel-Lucent 474 Bangalore, India 475 Email: manav@alcatel-lucent.com 476 Tony Li 477 Redback Networks Inc. 478 300 Holger Way 479 San Jose CA 95134 480 USA 481 EMail: tony.li@tony.li 483 Vishwas Manral 484 IP Infusion 485 Almora, Uttarakhand 486 India 487 Email: vishwas@ipinfusion.com 489 Russ White 490 Cisco Systems 491 RTP North Carolina 492 USA 493 Email: riw@cisco.com 495 Randall J. Atkinson 496 Extreme Networks 497 3585 Monroe Street 498 Santa Clara, CA 95051 499 USA 500 Email: rja@extremenetworks.com 502 Matthew J. Fanto 503 Ciber Inc. 504 Dearborn, Mi 505 USA 506 Email: mfanto@ciber.com 508 Full Copyright Statement 510 Copyright (C) The IETF Trust (2008). 512 This document is subject to the rights, licenses and restrictions 513 contained in BCP 78, and except as set forth therein, the authors 514 retain all their rights. 516 This document and the information contained herein are provided on an 517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 519 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 520 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 521 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Intellectual Property 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed 527 to pertain to the implementation or use of the technology described 528 in this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the procedures with respect to rights in RFC documents can be 532 found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use 537 of such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository 539 at http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at ietf- 545 ipr@ietf.org.