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