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