idnits 2.17.1 draft-ietf-isis-hmac-sha-02.txt: -(115): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(156): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(341): 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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 406. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 16 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 -- 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) -- 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' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 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: October 2007 Vishwas Manral 4 IP Infusion 5 Russ White 6 Cisco Systems 8 IS-IS Generic Cryptographic Authentication 10 draft-ietf-isis-hmac-sha-02.txt 12 Status of this Memo 14 Distribution of this memo is unlimited. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document proposes an extension to IS-IS to allow the use of any 39 cryptographic authentication algorithm in addition to the already 40 documented authentication schemes, described in the base 41 specification and RFC 3567. 43 Although this document has been written specifically for using MAC 44 construct along with the SHA family of cryptographic hash functions, 45 the method described in this document is generic and can be used to 46 extend IS-IS to support any cryptographic hash function in the 47 future. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 1. Introduction 57 IS-IS [ISO] [RFC1195] specification allows for authentication of its 58 PDUs via the authentication TLV 10 that is carried as the part of the 59 PDU. The base spec has provision for only clear text passwords and 60 RFC 3567 [RFC3567] augments this to provide the capability to use 61 HMAC MD5 authentication for its PDUs. 63 The first octet of value field of TLV 10 specifies the type of 64 authentication to be carried out. Type 0 is reserved, Type 1 65 indicates a cleartext password, Type 54 indicates HMAC MD5 and Type 66 255 is used for routing domain private authentication methods. The 67 remainder of the value field contains the actual authentication data 68 determined by the value of the authentication type. 70 This document proposes a new authentication type to be carried in TLV 71 10, called the cryptographic authentication (CRYPTO_AUTH). This can 72 be used to specify any authentication algorithm for authenticating 73 and verifying IS-IS PDUs. 75 This document also explains how HMAC-SHA authentication can be used 76 in IS-IS. 78 By definition, HMAC [RFC2104] requires a cryptographic hash function. 79 We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384 and 80 SHA-512 [NIST] for this purpose to authenticate the IS-IS PDUs. 82 We propose to do away with the per interface keys and instead have 83 key IDs that map to unique IS-IS Security Associations. 85 2. IS-IS Security Association 87 An IS-IS Security Association (SA) contains a set of shared 88 parameters between any two legitimate IS-IS speakers. 90 Parameters associated with an IS-IS SA: 92 O Key ID � This is a one octet unsigned integer used to uniquely 93 identify an IS-IS SA, as manually configured by the network operator. 94 The receiver determines the active SA by looking at this field in the 95 incoming PDU. The sender puts this Key ID based on the active 96 configuration. 98 Using key IDs makes changing keys while maintaining protocol 99 operation convenient. Each key ID specifies two independent parts, 100 the authentication protocol and the authentication key, as explained 101 below. Normally, an implementation would allow the network operator 102 to configure a set of keys in a key chain, with each key in the chain 103 having fixed lifetime. The actual operation of these mechanisms is 104 outside the scope of this document. 106 Note that each key ID can indicate a key with a different 107 authentication protocol. This allows multiple authentication 108 mechanisms to be used at various times without disrupting IS-IS 109 peering, including the introduction of new authentication mechanisms. 111 o Authentication Algorithm � This signifies the authentication 112 algorithm to be used with the IS-IS SA. Valid values are HMAC-SHA-1, 113 HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512. 115 o Authentication Key � This value denotes the key associated with the 116 IS-IS SA. The length of this key is variable and depends upon the 117 authentication algorithm specified by the IS-IS SA. 119 3. Authentication Procedures 121 3.1 Authentication TLV 123 A new authentication code, 3, indicates the CRYPTO_AUTH mechanism 124 described in this document is in use, is inserted in the first octet 125 of the existing IS-IS Authentication TLV (10). 127 0 1 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type 10 | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Auth Type | Key ID | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 + + 136 | Authentication Data (Variable)| 137 + + 138 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 1 142 3.2 Procedures at the Sending Side 144 An appropriate IS-IS SA is selected for use with an outgoing IS-IS 145 PDU. This is done based on the active key at that instant. If IS-IS 146 is unable to find an active key, then the PDU is discarded. 148 If IS-IS is able to find the active key, then the key gives the 149 authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, 150 HMAC-SHA-384 or HMAC-SHA-512) that needs to be applied on the PDU. 152 An implementation MUST fill the authentication type and the length 153 before the authentication data is computed. The length of the TLV is 154 set as per the authentication algorithm that is being used. 156 It�s set to 22 for HMAC-SHA-1, 30 for HMAC-SHA-224, 34 for HMAC-SHA- 157 256, 50 for HMAC-SHA-384 and 66 for HMAC-SHA-512. Note that one octet 158 has been added to account for the Key ID and one octet for the 159 authentication type. The authentication value field is set to Zero. 161 The key ID is filled. 163 The checksum and remaining life time fields are set to Zero for the 164 LSPs before authentication is calculated. 166 The result of the authentication algorithm is placed in the 167 Authentication data, following the key ID. 169 The authentication data for the IS-IS IIH PDUs MUST be computed after 170 the IIH has been padded to the MTU size, if padding is not explicitly 171 disabled. 173 3.3 Procedure at the Receiving Side 175 The appropriate IS-IS SA is identified by looking at the Key ID from 176 the Authentication TLV 10 from the incoming IS-IS PDU. 178 Authentication algorithm dependent processing, needs to be performed, 179 using the algorithm specified by the appropriate IS-IS SA for the 180 received packet. 182 Before an implementation performs any processing it needs to save the 183 values of the Authentication value field, the checksum and the 184 remaining life time. 186 These fields are set to Zero and the authentication data is computed. 187 The calculated data is compared with the received authentication data 188 in the PDU and the PDU is discarded if the two do not match. In such 189 a case, an error event SHOULD be logged. 191 An implementation MAY have a transition mode where it includes 192 CRYPTO_AUTH information in the PDUs but does not verify this 193 information. This is provided as a transition aid for networks in the 194 process of migrating to the new CRYPTO_AUTH based authentication 195 schemes. 197 Similarly, implementations not supporting the CRYPTO_AUTH field MAY 198 accept PDUs that contain this particular field in TLV 10. 200 4. Algorithm Dependent Processing 202 HMAC is a mechanism for message authentication using cryptographic 203 hash functions and has been explained in depth in [RFC2104]. The 204 reader is suggested to go through it to clearly understand how it 205 works. HMAC can be used, without modifying any hash function, for 206 calculating and verifying the message authentication values. It thus 207 verifies both the data integrity and the authenticity of a message. 209 The HMAC algorithm takes key K and text T as the input. The block 210 size B is 64 for SHA-1, SHA-224 and SHA-256 and its 128 for SHA-384 211 and SHA-512 213 The Key K is the password that has been chosen and text T is the IS- 214 IS PDU that needs to be authenticated. 216 Because of the way the hash functions are used in HMAC construction, 217 the collision attacks currently known against MD5 [MD5-attack] and 218 SHA-1 [SHA-1-attack] do not apply. 220 5. Security Considerations 222 The document proposes extensions to IS-IS which would make it more 223 secure than what it is today. It does not provide confidentiality as 224 a routing protocol contains information that does not need to be kept 225 secret. It does however, provide means to authenticate the sender of 226 the PDUs which is of interest to us. 228 The mechanism detailed in this document does not protect IS-IS 229 against replay attacks. An adversary could in theory replay old IIHs 230 and bring down the adjacency [CRYPTO] or replay old CSNPs and PSNPs 231 that would cause a flood of LSPs in the network. Using some sort of 232 crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to 233 solve this problem. Discussing this is beyond the scope of this 234 document and it�s a matter which needs to be followed in the WG. 236 This document states that the remaining lifetime of the LSP MUST be 237 set to zero before computing the authentication, thus this field is 238 not authenticated. This field is excluded so that the LSPs may be 239 aged by the ISes in between without requiring to recompute the 240 authentication data. This can be exploited by an attacker. 242 To ensure greater security, the keys used must be changed 243 periodically and implementations MUST be able to store and use more 244 than one key at the same time. 246 It should be noted that the cryptographic strength of the HMAC 247 depends upon the cryptographic strength of the underlying hash 248 function and on the size and quality of the key. 250 There are certain hash functions that require all the fields of the 251 message text T to be filled with non-zero values for greater 252 security. Any extension using such hash functions to calculate the 253 HMAC MUST fill the checksum field with some predefined non-zero 254 number. 256 6. Acknowledgements 258 We would like to thank Tony Li for his detailed comments on this 259 draft and helping us out with sorting the IANA issues. We also thank 260 him and Ran Atkinson for their work on IS-IS HMAC-MD5 authentication, 261 from which this draft has been derived. 263 Thanks to Hugo Krawczyk, Arjen K. Lenstra (Bell Labs), Eric Grosse 264 (Bell Labs) and Matthew J. Fanto for educating us on some of the 265 finer points related to Crypto Mathematics. 267 7. IANA Considerations 269 This document requests that IANA create a new code point registry to 270 administer the Authentication Type code points for TLV 10. This 271 registry would be part of the existing IS-IS code points registry as 272 established by RFC 3563 and RFC 3359. This registry should be 273 managed using the Designated Expert policy as described in 274 [RFC-2434bis] and will be called IS-IS Authentication Type Codes. 276 The values in the IS-IS Authentication Type Codes registry should be 277 recorded in decimal and should only be approved after a designated 278 expert, appointed by the IESG area director, has been consulted. 279 The intention is that any allocation will be accompanied by a 280 published RFC. However, the Designated Expert can approve 281 allocations once it seems clear that an RFC will be published, 282 allowing for the allocation of values prior to the document being 283 approved for publication as an RFC. New items should be documented in 284 a publicly and freely available specification. We should also have 285 the provision of allowing external specifications to allocate and use 286 the IS-IS Authentication Type Codes maintained by this registry. 288 Initial values for the IS-IS Authentication Type Codes registry are 289 given below; future assignments are to be made through Expert 290 Review. Assignments consist of an authentication type name 291 and its associated value. 293 Authentication Type Code Value Reference 294 ------------------------ ------ --------- 296 Reserved 0 [ISO] 297 Cleartext Password 1 [ISO] 298 ISO 10589 Reserved 2 [ISO] 299 Cryptographic Authentication 3 300 HMAC-MD5 Authentication 54 [RFC3567] 301 Routeing Domain private authentication method 255 [ISO] 303 This document currently defines and uses the value 3 to foster 304 prestandard implementations. 306 8. References 308 8.1 Normative References 310 [ISO] �Intermediate system to Intermediate system routeing 311 information exchange protocol for use in conjunction with 312 the Protocol for providing the Connectionless-mode Network 313 Service (ISO 8473)�, ISO/IEC 10589:1992 315 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 316 dual environments", RFC 1195, December 1990. 318 [RFC2119] Bradner, S., �Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119 321 [RFC3567] Li, T. and R. Atkinson, �Intermediate System to 322 Intermediate System (IS-IS) Cryptographic Authentication", 323 RFC 3567, July 2003 325 [RFC2104] Krawczyk, H. et al., �HMAC: Keyed-Hashing for Message 326 Authentication�, RFC 2104, February 1997 328 [NIST] National Institute of Standards and Technology, "Secure 329 Hash Standard", FIPS PUB 180-2, August 2002 331 8.2 Informative References 333 [MD5-attack] Wang, X. et al., �Collisions for Hash Functions MD4, 334 MD5, HAVAL-128 and RIPEMD", August 2004, 335 http://eprint.iacr.org/2004/199 337 [SHA-1-attack] Wang, X. et al., �Collision Search Attacks on SHA1", 338 February 2005, 339 http://theory.csail.mit.edu/~yiqun/shanote.pdf 341 [CRYPTO] Manral, V. et al., �Issues with existing Cryptographic 342 Protection Methods for Routing Protocols�, Work in 343 Progress, February 2006 345 [RFC-2434bis] Narten, T. and Alvestrand, H., "Guidelines for Writing 346 an IANA Considerations Section in RFCs�, Work in 347 Progress, March 2007 349 9. Author's Addresses 351 Manav Bhatia 352 Alcatel-Lucent 353 Bangalore, India 354 Email: manav@alcatel-lucent.com 356 Vishwas Manral 357 IP Infusion 358 Almora, Uttarakhand 359 India 360 Email: vishwas@ipinfusion.com 362 Russ White 363 Cisco Systems 364 RTP North Carolina 365 USA 366 Email: riw@cisco.com 368 Full Copyright Statement 370 Copyright (C) The IETF Trust (2007). 372 This document is subject to the rights, licenses and restrictions 373 contained in BCP 78, and except as set forth therein, the authors 374 retain all their rights. 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 379 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 380 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 381 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Intellectual Property 386 The IETF takes no position regarding the validity or scope of any 387 Intellectual Property Rights or other rights that might be claimed 388 to pertain to the implementation or use of the technology described 389 in this document or the extent to which any license under such rights 390 might or might not be available; nor does it represent that it has 391 made any independent effort to identify any such rights. Information 392 on the procedures with respect to rights in RFC documents can be 393 found in BCP 78 and BCP 79. 395 Copies of IPR disclosures made to the IETF Secretariat and any 396 assurances of licenses to be made available, or the result of an 397 attempt made to obtain a general license or permission for the use 398 of such proprietary rights by implementers or users of this 399 specification can be obtained from the IETF on-line IPR repository 400 at http://www.ietf.org/ipr. 402 The IETF invites any interested party to bring to its attention any 403 copyrights, patents or patent applications, or other proprietary 404 rights that may cover technology that may be required to implement 405 this standard. Please address the information to the IETF at ietf- 406 ipr@ietf.org.