idnits 2.17.1 draft-ietf-ospf-hmac-sha-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == 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. -- The draft header indicates that this document updates RFC2328, but the abstract doesn't seem to directly say this. It does mention RFC2328 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Category: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (31 August 2009) is 5350 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. 'FIPS-180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' -- Obsolete informational reference (is this intentional?): RFC 4634 (ref. 'RFC 4684') (Obsoleted by RFC 6234) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Bhatia 3 Alcatel-Lucent 4 Category: Standards-Track V. Manral 5 Expires: 31 Jan 2010 IP Infusion 6 Updates: RFC 2328 M. Fanto 7 Aegis Data Security 8 R. White 9 Cisco Systems 10 T. Li 11 Ericsson 12 M. Barnes 13 Cisco Systems 14 R. Atkinson 15 Extreme Networks 17 31 August 2009 19 OSPFv2 HMAC-SHA Cryptographic Authentication 20 22 Status of this Memo 24 Distribution of this memo is unlimited. 26 This Internet-Draft is submitted to IETF in full conformance 27 with the provisions of BCP 78 and BCP 79. 29 Copyright (c) 2009 IETF Trust and the persons identified 30 as the document authors. All rights reserved. 32 This document is subject to BCP 78 and the IETF Trust's Legal 33 Provisions Relating to IETF Documents in effect on the date of 34 publication of this document 35 (http://trustee.ietf.org/license-info). Please review these 36 documents carefully, as they describe your rights and 37 restrictions with respect to this document. 39 This document may contain material from IETF Documents or IETF 40 Contributions published or made publicly available before 41 November 10, 2008. The person(s) controlling the copyright in 42 some of this material may not have granted the IETF Trust the 43 right to allow modifications of such material outside the IETF 44 Standards Process. Without obtaining an adequate license from 45 the person(s) controlling the copyright in such materials, this 46 document may not be modified outside the IETF Standards Process, 47 and derivative works of it may not be created outside the IETF 48 Standards Process, except to format it for publication as an RFC 49 or to translate it into languages other than English. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF), its areas, and its working groups. Note that 53 other groups may also distribute working documents as 54 Internet-Drafts. 56 Internet-Drafts are draft documents valid for a maximum of 57 six months and may be updated, replaced, or obsoleted by other 58 documents at any time. It is inappropriate to use 59 Internet-Drafts as reference material or to cite them 60 other than as "work in progress." 62 The list of current Internet-Drafts can be accessed at 63 http://www.ietf.org/1id-abstracts.html 65 The list of Internet-Draft Shadow Directories can be accessed at 66 http://www.ietf.org/shadow.html. 68 Abstract 70 This document describes how the NIST Secure Hash Standard family of 71 algorithms can be used with OSPF version 2's built-in cryptographic 72 authentication mechanism. This updates, but does not supercede, 73 the cryptographic authentication mechanism specified in RFC 2328. 75 1. INTRODUCTION 77 A variety of risks exist when depoying any routing 78 protocol.[Bell89] This document provides an update to OSPFv2 79 Cryptographic Authentication, which is specified in Appendix D 80 of RFC 2328. This document does not deprecate or supercede 81 RFC 2328. OSPFv2 itself is defined in RFC 2328. [RFC 2328] 83 This document adds support for Secure Hash Algorithms defined in 84 the US NIST Secure Hash Standard (SHS) as defined by NIST FIPS 85 180-2. [FIPS-180-2] includes SHA-1, SHA-224, SHA-256, SHA-384, 86 and SHA-512. The HMAC authentication mode defined in NIST FIPS 87 198 is used. [FIPS-198] 89 It is believed that [RFC 2104] is mathematically identical to 90 [FIPS-198] and also believed that algorithms in [RFC 4684] are 91 mathematically identical to [FIPS-180-2]. 93 The creation of this addition to OSPFv2 was driven by operator 94 requests that they be able to use the NIST SHS family of 95 algorithms in the NIST HMAC mode, instead of being forced 96 to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic 97 Authentication. Cryptographic matters are discussed in more 98 detail in the Security Considerations section of this document. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 101 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 102 and "OPTIONAL" in this document are to be interpreted as 103 described in RFC 2119. [RFC 2119] 105 2. Background 107 All OSPF protocol exchanges can be authenticated. The OSPF 108 packet header (see Section A.3.1 of RFC-2328) includes an 109 Authentication Type field, and 64-bits of data for use by 110 the appropriate authentication scheme (determined by the 111 type field). 113 The authentication type is configurable on a per-interface 114 (or equivalently, on a per-network/subnet) basis. Additional 115 authentication data is also configurable on a per-interface 116 basis. 118 OSPF Authentication types 0, 1, and 2 are defined by RFC 2328. 119 This document provides an update to RFC 2328 that is only 120 applicable to Authentication Type 2, "Cryptographic 121 Authentication". 123 3. Cryptographic authentication with NIST SHS in HMAC mode 125 Using this authentication type, a shared secret key is configured 126 in all routers attached to a common network/subnet. For each 127 OSPF protocol packet, the key is used to generate/verify a 128 "message digest" that is appended to the end of the OSPF packet. 129 The message digest is a one-way function of the OSPF protocol 130 packet and the secret key. Since the secret key is never sent 131 over the network in the clear, protection is provided against 132 passive attacks. [RFC 1704] 134 The algorithms used to generate and verify the message digest 135 are specified implicitly by the secret key. This specification 136 discusses the computation of OSPF Cryptographic Authentication 137 data when any of the NIST SHS family of algorithms is used in 138 the Hashed Message Authentication Code (HMAC) mode. 139 Please also see RFC 2328, Appendix D. 141 With the additions in this document, the currently valid algorithms 142 (including mode) for OSPFv2 Cryptographic Authentication include: 143 Keyed-MD5 (defined in RFC-2328, Appendix D) 144 HMAC-SHA-1 (defined here) 145 HMAC-SHA-256 (defined here) 146 HMAC-SHA-384 (defined here) 147 HMAC-SHA-512 (defined here) 149 Of the above, implementations of this specification MUST 150 include support for at least: 151 HMAC-SHA-256 153 and SHOULD include support for: 154 HMAC-SHA-1 156 and SHOULD also (for backwards compatibility with existing 157 implementations and deployments) include support for: 158 Keyed-MD5 160 and MAY also include support for: 161 HMAC-SHA-384 162 HMAC-SHA-512 164 An implementation of this specification MUST allow network 165 operators to configure ANY authentication algorithm supported 166 by that implementation for use with ANY given Key-ID value 167 that is configured into that OSPFv2 router. 169 3.1. Generating Cryptographic Authentication 171 The overall cryptographic authentication process defined in 172 Appendix D of RFC 2328 remains unchanged. However, the specific 173 cryptographic details (i.e. SHA rather than MD5, HMAC rather 174 than Keyed-Hash) are defined herein. To reduce the potential for 175 confusion, this section minimises the repetition of text from RFC 176 2328, Appendix D, which is incorporated here by reference.[RFC 177 2328] 179 First, following the procedure defined in RFC 2328, Appendix D, 180 select the appropriate OSPFv2 Security Association for use with 181 this packet and set the Key-ID field to the KeyID value of that 182 OSPFv2 Security Association. 184 Second, set the Authentication Type to cryptographic 185 authentication, and set the Authentication Data Length field to 186 the length (measured in bytes, not bits) of the cryptographic 187 hash that will be used. When any NIST SHS algorithm is used in 188 HMAC mode with OSPFv2 Cryptographic Authentication, the 189 Authentication Data Length is equal to the normal hash output 190 length (measured in bytes) for the specific NIST SHS algorithm in 191 use. For example, with NIST SHA-256, the Authentication Data 192 Length is 32 bytes. 194 Third, The 32-bit Cryptographic sequence number is set in 195 accordance with the procedures in RFC 2328, Appendix D 196 applicable to the Cryptographic Authentication type. 198 Fourth, The message digest is then calculated and appended 199 to the OSPF packet, as described below in Section 3.3. The 200 KeyID, Authentication Algorithm, and Key to be used for 201 calculating the digest are all components of the selected 202 OSPFv2 Security Association. Input to the authentication 203 algorithm consists of the OSPF packet and the secret key. 205 3.2 OSPFv2 Security Association 207 This document uses the term OSPFv2 Security Association 208 (OSPFv2 SA) to refer to the authentication key information 209 defined in Section D.3, pages 228 and 229, of RFC 2328. 210 The OSPFv2 protocol does not include an in-band mechanism 211 to create or manage OSPFv2 Security Associations. The 212 parameters of an OSPFv2 Security Association are updated 213 to be: 215 Key Identifier (KeyID) 216 This is an 8-bit unsigned value used to 217 uniquely identify an OSPFv2 SA and is 218 configured either by the router administrator 219 (or, in the future, possibly by some key 220 management protocol specified by the 221 IETF). The receiver uses this to locate 222 the appropriate OSPFv2 SA to use. The 223 sender puts this KeyID value in the OSPF 224 packet based on the active OSPF configuration. 226 Authentication Algorithm 227 This indicates the authentication algorithm 228 (and also the cryptographic mode, such as HMAC) 229 to be used. This information SHOULD never be 230 sent over the wire in cleartext form. 231 At present valid values are: Keyed-MD5, 232 HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, 233 and HMAC-SHA-512. 235 Authentication Key 236 This is the cryptographic key used for 237 cryptographic authentication with this 238 OSPFv2 SA. This value SHOULD never be 239 sent over the wire in cleartext form. 240 This is noted as "K" in Section 3.3 below. 242 Key Start Accept 243 The time that this OSPF router will accept 244 packets that have been created with this 245 OSPF Security Association. 247 Key Start Generate 248 The time that this OSPF router will begin 249 using this OSPF Security Association for 250 OSPF packet generation. 252 Key Stop Generate 253 The time that this OSPF router will stop 254 using this OSPF Security Association for 255 OSPF packet generation. 257 Key Stop Accept 258 The time that this OSPF router will stop 259 accepting packets generated with this 260 OSPF Security Association. 262 In order to achieve smooth key transition, KeyStartAccept SHOULD 263 be less than KeyStartGenerate and KeyStopGenerate SHOULD be less 264 than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left 265 unspecified, the key's lifetime is infinite. When a new key 266 replaces an old, the KeyStartGenerate time for the new key MUST 267 be less than or equal to the KeyStopGenerate time of the old key. 269 Key storage SHOULD persist across a system restart, warm or cold, 270 to avoid operational issues. In the event that the last key 271 associated with an interface expires, it is unacceptable to 272 revert to an unauthenticated condition, and not advisable to 273 disrupt routing. Therefore, the router should send a "last 274 authentication key expiration" notification to the network 275 manager and treat the key as having an infinite lifetime until 276 the lifetime is extended, the key is deleted by network 277 management, or a new key is configured. 279 3.3 Cryptographic Aspects 281 This describes the computation of the Authentication Data value 282 when any NIST SHS algorithm is used in the HMAC mode with OSPFv2 283 Cryptographic Authentication. 285 In the algorithm description below, the following nomenclature, 286 which is consistent with [FIPS-198], is used: 288 H is the specific hashing algorithm (e.g. SHA-256). 289 K is the authentication key for the OSPFv2 security 290 association. 291 Ko is the cryptographic key used with the hash algorithm. 292 B is the block size of H, measured in octets, 293 rather than bits. Note well that B is the 294 internal block size, not the hash size. 295 For SHA-1 and SHA-256: B == 64 296 For SHA-384 and SHA-512: B == 128 297 L is the length of the hash, measured in octets, 298 rather than bits. 299 XOR is the exclusive-or operation. 300 Opad is the hexadecimal value 0x5c repeated B times. 301 Ipad is the hexadecimal value 0x36 repeated B times. 302 Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. 304 Implementation note: 305 This definition of Apad means that Apad always 306 is the same length as the hash output. 308 (1) PREPARATION OF KEY 309 In this application, Ko is always L octets long. 311 If the Authentication Key (K) is L octets long, then Ko is equal 312 to K. If the Authentication Key (K) is more than L octets long, 313 then Ko is set to H(K). If the Authentication Key (K) is less 314 than L octets long, then Ko is set to the Authentication Key (K) 315 with zeros appended to the end of the Authentication Key (K) such 316 that Ko is L octets long. 318 (2) FIRST HASH 319 First, the OSPFv2 packet's Authentication Trailer, which 320 is the appendage described in RFC 2328, Section D.4.3, 321 Page 233, items (6)(a) and (6)(d), is filled with the value 322 Apad, and the Authentication Type field is set to 2. 324 Then, a first hash, also known as the inner hash, is computed 325 as follows: 326 First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet)) 328 Implementation Notes: 329 Note that the First-Hash above includes the Authentication 330 Trailer containing the Apad value, as well as the OSPF 331 packet, as per RFC 2328, Section D.4.3. 333 The definition of Apad (above) ensures it is always the same 334 length as the hash output. This is consistent with RFC 2328. 335 The "(OSPFv2 Packet)" mentioned in the First Hash (above) 336 does include the OSPF Authentication Trailer. 338 The digest length for SHA-1 is 20 bytes, for SHA-256 is 339 32 bytes, for SHA-384 is 48 bytes, and for SHA-512 is 340 64-bytes. 342 (3) SECOND HASH 343 Then a second hash, also known as the outer hash, is computed 344 as follows: 345 Second-Hash = H(Ko XOR Opad || First-Hash) 347 (4) RESULT 348 The result Second-Hash becomes the Authentication Data that 349 is sent in the Authentication Trailer of the OSPFv2 packet. 350 The length of the Authentication Trailer is always identical 351 to the message digest size of the specific hash function H 352 that is being used. 354 This also means that the use of hash functions with larger 355 output sizes will also increase the size of the OSPFv2 packet 356 as transmitted on the wire. 358 Implementation Note: 359 RFC 2328, Appendix D specifies that the Authentication 360 Trailer is not counted in the OSPF packet's own length 361 field, but is included in the packet's IP length field. 363 3.4. Message verification 365 Message verification follows the procedure defined in RFC 2328, 366 except that the cryptographic calculation of the message digest 367 follows the procedure in Section 3.3 above when any NIST SHS 368 algorithm in the HMAC mode is in use. Kindly recall that the 369 cryptographic algorithm/mode in use is indicated implicitly 370 by the Key-ID of the received OSPFv2 packet. 372 Implementation Notes: 373 One must save the received digest value before calculating 374 the expected digest value, so that after that calculation 375 the received value can be compared with the expected 376 value to determine whether to accept that OSPF packet. 378 RFC 2328, Section D.4.3 (6) (c) should be read very 379 closely prior to implementing the above. With SHA 380 algorithms in HMAC mode, Apad is placed where the MD5 381 key would be put if Keyed-MD5 were in use. 383 3.5 Changing OSPFv2 Security Associations 385 Using KeyIDs makes changing the active OSPFv2 SA convenient. 386 An implementation can choose to associate a lifetime with 387 each OSPFv2 SA and can thus automatically switch to a different 388 OSPFv2 SA based on the lifetimes of the configured OSPFv2 SA(s). 390 After changing the active OSPFv2 SA, the OSPF sender will use 391 the (different) KeyID value associated with the newly active 392 OSPFv2 SA. The receiver will use this new KeyID to select 393 the appropriate (new) OSPFv2 SA to use with the received OSPF 394 packet containing the new KeyID value. 396 Because the KeyID field is present, the receiver does not need 397 to try all configured OSPFv2 Security Associations with any 398 received OSPFv2 packet. This can mitigate some of the risks 399 of a Denial-of-Service attack on the OSPF instance, but does 400 not entirely prevent all conceivable DoS attacks. For example, 401 an on-link adversary still could generate OSPFv2 packets that 402 are synactically valid, but contain invalid Authentication 403 Data, thereby forcing the receiver(s) to perform expensive 404 cryptographic computations to discover that the packets are 405 invalid. 407 4. Security Considerations 409 This document enhances the security of the OSPFv2 routing 410 protocol by adding support for the algorithms defined in 411 the NIST Secure Hash Standard (SHS) using the Hashed 412 Message Authentication Code (HMAC) mode to the existing 413 OSPFv2 Cryptographic Authentication method, and support 414 for the Hashed Message Authentication Code (HMAC) mode. 416 This provides several alternatives to the existing Keyed-MD5 417 mechanism. There are published concerns about the overall 418 strength of the MD5 algorithm. [Dobb96a, Dobb96b, Wang04] 419 While those published concerns apply to the use of MD5 in 420 other modes (e.g. use of MD5 X.509v3/PKIX digital certificates), 421 they are not an attack upon Keyed-MD5, which is what OSPFv2 422 specified in RFC 2328. There are also published concerns 423 about the SHA algorithm [Wang05] and also concerns about 424 the MD5 and SHA algorithms in the HMAC mode [RR07, RR08]. 425 Separately, some organisations (e.g. US Government) 426 prefer NIST algorithms, such as the SHA family, over 427 other algorithms for local policy reasons. 429 The value Apad is used here primarily for consistency with 430 IETF specifications for HMAC-SHA authentication of RIPv2 SHA 431 [RFC 4822] and IS-IS SHA [RFC 5310] and to minimise OSPF 432 protocol processing changes in Section D.4.3 of RFC 2328. 433 [RFC 2328] 435 The quality of the security provided by the Cryptographic 436 Authentication option depends completely on the strength 437 of the cryptographic algorithm and cryptographic mode in use, 438 the strength of the key being used, and the correct 439 implementation of the security mechanism in all communicating 440 OSPF implementations. Accordingly, the use of high assurance 441 development methods is recommended. It also requires that 442 all parties maintain the secrecy of the shared secret key. 443 [RFC 4086] provides guidance on methods for generating 444 cryptographically random bits. 446 This mechanism is vulnerable to a replay attack by any on-link 447 node. An on-link node could record a legitimate OSPF packet 448 sent on the link, then replay that packet at the next time 449 the recorded OSPF packet's sequence number is valid. This 450 replay attack could cause significant routing disruptions 451 within the OSPF domain. 453 Ideally, for example to prevent the preceding attack, each 454 OSPF Security Association would be replaced by a new and 455 different OSPF Security Association before any sequence number 456 were reused. As of the date this document was published, 457 no form of automated key management has been standardised 458 for OSPF. So, as of the date this document was published, 459 common operational practice has been to use the same OSPF 460 authentication key for very long periods of time. This 461 operational practice is undesirable for many reasons. 462 Therefore, it is clearly desirable to develop and 463 standardise some automated key management mechanism for 464 OSPF. 466 Because all of the currently specified algorithms use 467 symmetric cryptography, one cannot authenticate precisely 468 which OSPF router sent a given packet. However, one can 469 authenticate that the sender knew the OSPF Security 470 Association (including the OSPFv2 SA's parameters) 471 currently in use. 473 Because a routing protocol contains information that need 474 not be kept secret, privacy is not a requirement. However, 475 authentication of the messages within the protocol is of 476 interest, to reduce the risk of an adversary compromising 477 the routing system by deliberately injecting false 478 information into the routing system. 480 The technology in this document enhances an authentication 481 mechanism for OSPFv2. The mechanism described here is not 482 perfect and need not be perfect. Instead, this mechanism 483 represents a significant increase in the work function of 484 an adversary attacking OSPFv2, as compared with plain-text 485 authentication or null authentication, while not causing 486 undue implementation, deployment, or operational complexity. 487 Denial of service attacks are not generally preventable 488 in a useful networking protocol. [VK83] 490 Because of implementation considerations, including the 491 need for backwards compatibility, this specification uses 492 the same mechanism as specified in RFC 2328 and limits 493 itself to adding support for additional cryptographic hash 494 functions. Also, some large network operators have indicated 495 they prefer to retain the basic mechanism defined in RFC 2328, 496 rather than migrate to IP Security, due to deployment and 497 operational considerations. If all the OSPFv2 routers 498 supported IPsec, then IPsec tunnels could be used in lieu 499 of this mechanism.[RFC 4301] This would, however, relegate 500 the topology to point-to-point adjacencies over the mesh 501 of IPsec tunnels. 503 If a stronger authentication were believed to be required, 504 then the use of a full digital signature [RFC 2154] would be 505 an approach that should be seriously considered. Use of full 506 digital signatures would enable precise authentication of the 507 OSPF router originating each OSPF link-state advertisement, 508 and thereby provide much stronger integrity protection for 509 the OSPF routing domain. 511 5. IANA CONSIDERATIONS 513 The OSPF Authentication Codes registry entry for Cryptographic 514 Authentication (Registry Code 2) must be updated to refer to 515 this document as well as RFC 2328. 517 6. ACKNOWLEDGEMENTS 519 The authors would like to thank Bill Burr, Tim Polk, John Kelsey, 520 and Morris Dworkin of (US) NIST for review of portions of this 521 document that are directly derived from the closely related work 522 on RIPv2 Cryptographic Authentication [RFC 4822]. 524 David Black, Nevil Brownlee, Acee Lindem, and Hilarie Orman (in 525 alphabetical order by last name) provided feedback on earlier 526 versions of this document. That feedback has greatly improved 527 both the technical content and the readability of the current 528 draft. 530 Henrik Levkowetz's Internet Draft tools were very helpful 531 in preparing this draft and are much appreciated. 533 7. REFERENCES 535 7.1 Normative References 537 [FIPS-180-2] US National Institute of Standards & Technology, 538 "Secure Hash Standard (SHS)", FIPS PUB 180-2, 539 August 2002. 541 [FIPS-198] US National Institute of Standards & Technology, 542 "The Keyed-Hash Message Authentication Code (HMAC)", 543 FIPS PUB 198, March 2002. 545 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 546 Requirement Levels", RFC 2119, BCP-14, March 1997. 548 [RFC 2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 550 7.2 Informative References 552 [Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol 553 Suite", ACM Computer Communications Review, Volume 19, 554 Number 2, pp. 32-48, April 1989. 556 [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", 557 Technical Report, 2 May 1996. (Presented at the 558 Rump Session of EuroCrypt 1996.) 560 [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent 561 Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996. 563 [RFC 1704] N. Haller and R. Atkinson, "On Internet 564 Authentication", RFC 1704, October 1994. 566 [RFC 2104] Krawczyk, H. et alia, "HMAC: Keyed-Hashing 567 for Message Authentication", RFC 2104, 568 February 1997. 570 [RFC 2154] Murphy, S., Badger, M. and B. Wellington, 571 "OSPF with Digital Signatures", RFC 2154, June 1997. 573 [RFC 4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 574 "Randomness Requirements for Security", BCP-106, 575 RFC 4086, June 2005. 577 [RFC 4301] Kent, S. & K. Seo, "Security Architecture for 578 the Internet Protocol", RFC 4301, December 2005. 580 [RFC 4684] Eastlake 3rd, D., & T. Hansen, "US Secure Hash 581 Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. 583 [RFC 4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic 584 Authentication", RFC 4822, February 2007. 586 [RFC 5310] M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, 587 & M. Fanto, "IS-IS Generic Cryptographic 588 Authentication", RFC 5310, February 2009. 590 [RR07] Rechberger, Christian & Vincent Rijmen, "On 591 Authentication with HMAC and Non-random Properties", 592 Financial Cryptography and Data Security, 593 Lecture Notes in Computer Science, Volume 4886/2008, 594 Springer-Verlag, Berlin, December 2007. 596 [RR08] Rechberger, Christian & Vincent Rijmen, "New 597 Results on NMAC/HMAC when Instantiated with Popular 598 Hash Functions", Journal of Universal Computer Science, 599 Volume 14, Number 3, pp. 347-376, 1 February 2008. 601 [VK83] Voydock, V. and S. Kent, "Security Mechanisms in 602 High-level Networks", ACM Computing Surveys, 603 Vol. 15, No. 2, June 1983. 605 [Wang04] Wang, X. et alia, "Collisions for Hash Functions MD4, 606 MD5, HAVAL-128, and RIPEMD", August 2004, IACR. 607 http://eprint.iacr.org/2004/199 609 [Wang05] Wang, X. et alia, "Finding Collisions in the Full SHA-1" 610 Proceedings of Crypto 2005, Lecture Notes in Computer 611 Science, Volume 3621, pp. 17-36, Springer-Verlag, Berlin, 612 August 31, 2005. 614 AUTHORS 616 Manav Bhatia 617 Alcatel-Lucent 618 Bangalore, 619 India 620 EMail: manav@alcatel-lucent.com 622 Vishwas Manral 623 IP Infusion 624 Almora, Uttarakhand 625 India 627 EMail: vishwas@ipinfusion.com 629 Matthew J. Fanto 630 Aegis Data Security 631 Dearborn, MI 632 USA 634 EMail: mfanto@aegisdatasecurity.com 636 Russ I. White 637 Cisco Systems 638 7025 Kit Creek Road 639 P.O. Box 14987 640 RTP, NC 641 27709 USA 643 EMail: riw@cisco.com 645 Tony Li 646 Ericsson 647 300 Holger Way 648 San Jose, CA 649 95134 USA 651 Email: tony.li@tony.li 653 M. Barnes 654 Cisco Systems 655 225 West Tasman Drive 656 San Jose, CA 657 95134 USA 659 Email: mjbarnes@cisco.com 661 Randall J. Atkinson 662 Extreme Networks 663 3585 Monroe Street 664 Santa Clara, CA 665 95051 USA 667 Phone: +1 (408) 579-2800 668 EMail: rja@extremenetworks.com 670 Expires: 31 JAN 2010