idnits 2.17.1 draft-rja-ospf-hmac-shs-01.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 3979, Section 5, paragraph 1 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 383. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 146 has weird spacing: '... Ko is t...' -- 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 (28 February 2007) is 6267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC-2119' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC-2328' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'Bell89' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC-1704' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC-4086' is defined on line 311, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Atkinson 3 Extreme Networks 4 Category: Informational M. Fanto 5 Expires 28 Aug 2007 Ford Motor Company 6 Updates: RFC-2328 T. Li 7 Cisco Systems 8 28 February 2007 10 OSPFv2 Authentication with HMAC-SHS 11 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 Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 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 material 29 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 describes how the NIST Secure Hash Standard family of 40 algorithms can be used with OSPF version 2's built-in cryptographic 41 authentication mechanism. This updates, but does not supercede, 42 the cryptographic authentication mechanism specified in RFC-2328. 44 1. INTRODUCTION 46 This document provides an update to OSPFv2 Cryptographic Authentication, 47 which is specified in Appendix D of RFC-2328. This document does not 48 deprecate or supercede RFC-2328. OSPFv2 itself is defined in RFC-2328. 50 This document adds support for Secure Hash Algorithms defined in the 51 US NIST Secure Hash Standard (SHS) as defined by NIST FIPS 180-2. 52 [FIPS-180-2] includes SHA-1, SHA-256, SHA-384, and SHA-512. The 53 HMAC authentication mode defined in NIST FIPS 198 is used.[FIPS-198] 55 The creation of this addition to OSPFv2 was driven by operator 56 requests that they be able to use the NIST SHS family of algorithms 57 in the NIST HMAC mode, instead of being forced to use the Keyed-MD5 58 algorithm and mode with OSPFv2 Cryptographic Authentication. 60 While there are no openly published attacks on the Keyed-MD5 61 mechanism specified in RFC-2328, some reports [Dobb96a, Dobb96b] 62 create concern about the ultimate strength of the MD5 cryptographic 63 hash function. 65 2. Background 67 All OSPF protocol exchanges are authenticated. The OSPF packet 68 header (see Section A.3.1 of RFC-2328) includes an Authentication 69 Type field, and 64-bits of data for use by the appropriate 70 authentication scheme (determined by the type field). 72 The authentication type is configurable on a per-interface 73 (or equivalently, on a per-network/subnet) basis. Additional 74 authentication data is also configurable on a per-interface basis. 76 Authentication types 0, 1, and 2 are defined by RFC-2328. This 77 document provides an update to RFC-2328 that is only applicable 78 to Authentication Type 2, "Cryptographic Authentication". 80 3. Cryptographic authentication with NIST SHS in HMAC mode 82 Using this authentication type, a shared secret key is configured 83 in all routers attached to a common network/subnet. For each OSPF 84 protocol packet, the key is used to generate/verify a "message digest" 85 that is appended to the end of the OSPF packet. The message digest 86 is a one-way function of the OSPF protocol packet and the secret key. 87 Since the secret key is never sent over the network in the clear, 88 protection is provided against passive attacks. 90 The algorithms used to generate and verify the message digest are 91 specified implicitly by the secret key. This specification discusses 92 the computation of OSPF Cryptographic Authentication data when 93 any of the NIST SHS family of algorithms is used in the 94 Hashed Message Authentication Code (HMAC) mode. 95 Please also see RFC-2328, Appendix D. 97 With the additions in this document, the currently valid algorithms 98 (including mode) for OSPFv2 Cryptographic Authentication include: 100 Keyed-MD5 (defined in RFC-2328, Appendix D) 101 HMAC-SHA-1 (defined here) 102 HMAC-SHA-256 (defined here) 103 HMAC-SHA-384 (defined here) 104 HMAC-SHA-512 (defined here) 106 An implementation of this specification must enhance allow network 107 operators to specify any one of the above algorithms for use with 108 each given Key-ID value that is configured into an OSPFv2 109 implementation. 111 3.1. Generating Cryptographic Authentication 113 First, following the procedure defined in RFC-2328, Appendix D, 114 select the appropriate key for use with this packet and set the 115 Key-ID field to the chosen key's Key-ID value. 117 Second, set the Authentication Data Length field to the length 118 (measured in bytes, not bits) of the cryptographic hash that will be 119 used. When any NIST SHS algorithm is used in HMAC mode with OSPFv2 120 Cryptographic Authentication, the Authentication Data Length is equal 121 to the normal hash output length (measured in bytes) for the specific 122 NIST SHS algorithm in use. For example, with NIST SHA-256, the 123 Authentication Data Length is 32 bytes. 125 Third, The 32-bit Cryptographic sequence number is set in accordance 126 with the procedures in RFC-2328, Appendix D applicable to the 127 Cryptographic Authentication type. 129 Fourth, The message digest is then calculated and appended to the OSPF 130 packet. The authentication algorithm and algorithm mode to be used 131 in calculating the digest is indicated implicitly by the Key-ID. 132 Input to the authentication algorithm consists of the OSPF packet 133 and the secret key. 135 3.2 Cryptographic Aspects 137 This describes the computation of the Authentication Data value 138 when any NIST SHS algorithm is used in the HMAC mode with OSPFv2 139 Cryptographic Authentication. 141 In the algorithm description below, the following nomenclature, 142 which is consistent with [FIPS-198], is used: 144 H is the specific hashing algorithm (e.g. SHA-256). 145 K is the selected OSPFv2 key 146 Ko is the cryptographic key used with the hash algorithm. 147 B is the block size of H, measured in octets, rather than bits. 148 Note that B is the internal block size, not the hash size. 149 For SHA-1 and SHA-256: B == 64 150 For SHA-384 and SHA-512: B == 128 151 L is the length of the hash, measured in octets, rather than bits. 152 XOR is the exclusive-or operation. 153 Opad is the hexadecimal value 0x5c repeated B times. 154 Ipad is the hexadecimal value 0x36 repeated B times. 155 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 157 (1) PREPARATION OF KEY 158 In this application, Ko is always L octets long. 160 If the Authentication Key (K) is L octets long, then Ko is equal 161 to K. If the Authentication Key (K) is more than L octets long, 162 then Ko is set to H(K). If the Authentication Key (K) is less 163 than L octets long, then Ko is set to the Authentication Key (K) 164 with zeros appended to the end of the Authentication Key (K) such 165 that Ko is L octets long. 167 (2) FIRST HASH 168 First, the OSPFv2 packet's Authentication Data field is filled 169 with the value Apad and the Authentication Type field is set 170 to 2. 172 Then, a first hash, also known as the inner hash, is computed 173 as follows: 174 First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet)) 176 (3) SECOND HASH 177 Then a second hash, also known as the outer hash, is computed 178 as follows: 179 Second-Hash = H(Ko XOR Opad || First-Hash) 181 (4) RESULT 182 The result Second-Hash becomes the Authentication Data that is 183 sent in the Authentication Data field of the OSPFv2 packet. The 184 length of the Authentication Data field is always identical to 185 the message digest size of the specific hash function H that is 186 being used. 188 This also means that the use of hash functions with larger 189 output sizes will also increase the size of the OSPFv2 packet 190 as transmitted on the wire. 192 Implementation Note: RFC-2328, Appendix D specifies that the 193 Authentication Data is not counted in the OSPF packet's own 194 length field, but is included in the packet's IP length field. 196 3.3. Message verification 198 Message verification follows the procedure defined in RFC-2328, 199 except that the cryptographic calculation of the message digest 200 follows the procedure above when any NIST SHS algorithm in the 201 HMAC mode is in use. Kindly recall that the cryptographic 202 algorithm/mode in use is indicated implicitly by the Key-ID 203 of the received OSPFv2 packet. 205 4. Security Considerations 207 This document enhances the security of the OSPFv2 routing protocol 208 by adding support for additional cryptographic hash functions. 209 This document adds support for the algorithms defined in the 210 NIST Secure Hash Standard (SHS) using the NIST Hashed Message 211 Authentication Code (HMAC) mode to the existing OSPFv2 Cryptographic 212 Authentication method. 214 This provides several alternatives to the existing Keyed-MD5 215 mechanism. Although there are no published attacks on the 216 MD5 algorithm as used in RFC-2328, there are published concerns 217 about the overall strength of the MD5 algorithm. [Dobb96a, Dobb96b] 219 The quality of the security provided by the Cryptographic 220 Authentication option depends completely on the strength 221 of the cryptographic algorithm and cryptographic mode in use, 222 the strength of the key being used, and the correct implementation 223 of the security mechanism in all communicating OSPF implementations. 224 Accordingly, the use of high assurance development methods is 225 recommended. It also requires that all parties maintain the 226 secrecy of the shared secret key. 228 Because a routing protocol contains information that need not be 229 kept secret, privacy is not a requirement. However, authentication 230 of the messages within the protocol is of interest, to reduce the 231 risk of an adversary compromising the routing system by deliberately 232 injecting false information into the routing system. 234 The technology in this document enhances an authentication mechanism 235 for OSPFv2. The mechanism described here is not perfect and need 236 not be perfect. Instead, this mechanism represents a significant 237 increase in the work function of an adversary attacking OSPFv2, 238 as compared with plain-text authentication or null authentication, 239 while not causing undue implementation, deployment, or operational 240 complexity. Denial of service attacks are not generally preventable 241 in a useful networking protocol. [VK83] 243 Because of implementation considerations, including the need for 244 backwards compatibility, this specification uses the same mechanism 245 as specified in RFC-2328 and limits itself to adding support for 246 additional cryptographic hash functions. Also, some large network 247 operators have indicated they strongly prefer to retain the basic 248 mechanism defined in RFC-2328 due to deployment and operational 249 considerations. If all the OSPFv2 systems deployed by a given 250 network operator also supported using the IP Authentication Header 251 to protect OSPFv2, then such a network operator might consider 252 using the IP Authentication Header in lieu of this mechanism. 254 If a stronger authentication were believed to be required, 255 then the use of a full digital signature [RFC-2154] would be 256 an approach that should be seriously considered. It was 257 rejected for this purpose at this time because the computational 258 burden of full digital signatures is believed to be much higher 259 than is reasonable given the current threat environment in 260 operational commercial networks. Also, moving to full digital 261 signatures significantly increases the deployment complexity and 262 operational burden for network operators. 264 5. IANA CONSIDERATIONS 266 There are no IANA considerations for this document. 268 6. ACKNOWLEDGEMENTS 270 The authors would like to thank Bill Burr, Tim Polk, John Kelsey, 271 and Morris Dworkin of (US) NIST for review of portions of this 272 document that are directly derived from the closely related work 273 on RIPv2 Cryptographic Authentication [RFC-4822]. 275 7. REFERENCES 277 7.1 Normative References 279 [FIPS-180-2] US National Institute of Standards & Technology, 280 "Secure Hash Standard (SHS)", FIPS PUB 180-2, 281 August 2002. 283 [FIPS-198] US National Institute of Standards & Technology, 284 "The Keyed-Hash Message Authentication Code (HMAC)", 285 FIPS PUB 198, March 2002. 287 [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate 288 Requirement Levels", RFC-2119, BCP-14, March 1997. 290 [RFC-2328] Moy, J., "OSPF Version 2", RFC-2328, April 1998. 292 7.2 Informative References 294 [Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol 295 Suite", ACM Computer Communications Review, Volume 19, 296 Number 2, pp. 32-48, April 1989. 298 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", 299 Technical Report, 2 May 1996. (Presented at the 300 Rump Session of EuroCrypt 1996.) 302 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent 303 Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996. 305 [RFC-1704] N. Haller and R. Atkinson, "On Internet 306 Authentication", RFC 1704, October 1994. 308 [RFC-2154] Murphy, S., Badger, M. and B. Wellington, 309 "OSPF with Digital Signatures", RFC 2154, June 1997. 311 [RFC-4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 312 "Randomness Requirements for Security", BCP-106, 313 RFC-4086, June 2005. 315 [RFC-4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic Authentication", 316 RFC-4822, February 2007. 318 [VK83] Voydock, V. and S. Kent, "Security Mechanisms in High-level 319 Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. 321 AUTHORS 323 Randall J. Atkinson 324 Extreme Networks 325 3585 Monroe Street 326 Santa Clara, CA 95051 USA 328 Phone: +1 (408) 579-2800 329 EMail: rja@extremenetworks.com 330 Matt Fanto 331 Ford Motor Company 332 Michigan 333 USA 335 EMail: tbd 337 Tony Li 338 Cisco Systems 339 Tasman Drive 340 San Jose, CA 341 USA 343 EMail: tli@cisco.com 345 Full Copyright Statement 347 Copyright (C) The IETF Trust (2007). 349 This document is subject to the rights, licenses and restrictions 350 contained in BCP 78, and except as set forth therein, the authors 351 retain all their rights. 353 This document and the information contained herein are provided on an 354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND 356 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 357 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 358 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 361 Intellectual Property 363 The IETF takes no position regarding the validity or scope of any 364 Intellectual Property Rights or other rights that might be claimed 365 to pertain to the implementation or use of the technology 366 described in this document or the extent to which any license 367 under such rights might or might not be available; nor does it 368 represent that it has made any independent effort to identify any 369 such rights. Information on the procedures with respect to 370 rights in RFC documents can be found in BCP 78 and BCP 79. 372 Copies of IPR disclosures made to the IETF Secretariat and any 373 assurances of licenses to be made available, or the result of an 374 attempt made to obtain a general license or permission for the use 375 of such proprietary rights by implementers or users of this 376 specification can be obtained from the IETF on-line IPR repository 377 at http://www.ietf.org/ipr. 379 The IETF invites any interested party to bring to its attention 380 any copyrights, patents or patent applications, or other 381 proprietary rights that may cover technology that may be required 382 to implement this standard. Please address the information to the 383 IETF at ietf-ipr@ietf.org.