idnits 2.17.1 draft-ietf-rsvp-md5-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction |' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 107 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 277: '...heirs. Implementations SHOULD |...' RFC 2119 keyword, line 287: '...red interface. User interfaces SHOULD...' RFC 2119 keyword, line 301: '...ed. Implementations SHOULD maintain a...' RFC 2119 keyword, line 417: '...the order listed SHOULD form a non-dec...' RFC 2119 keyword, line 436: '...is specification SHOULD NOT be stored ...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 615 has weird spacing: '...Why not use ...' -- 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 (May 1997) is 9843 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) -- Missing reference section? '1' on line 534 looks like a reference -- Missing reference section? '7' on line 556 looks like a reference -- Missing reference section? '9' on line 566 looks like a reference -- Missing reference section? '8' on line 559 looks like a reference -- Missing reference section? '10' on line 203 looks like a reference -- Missing reference section? '2' on line 539 looks like a reference -- Missing reference section? '3' on line 543 looks like a reference -- Missing reference section? '4' on line 546 looks like a reference -- Missing reference section? '5' on line 550 looks like a reference -- Missing reference section? '6' on line 553 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft RSVP Cryptographic Authentication May 1997 4 RSVP Cryptographic Authentication | 5 draft-ietf-rsvp-md5-03.txt | 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are 10 working documents of the Internet Engineering Task Force 11 (IETF), its Areas, and its Working Groups. Note that other 12 groups may also distribute working documents as Internet 13 Drafts. 15 Internet Drafts are valid for a maximum of six months and may 16 be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet Drafts as reference 18 material or to cite them other than as a "work in progress". | 19 Comments should be made on the list rsvp@isi.edu. 21 Abstract 23 This document describes the format and use of RSVP's INTEGRITY 24 object to provide hop-by-hop integrity and authentication of 25 RSVP messages. 27 Draft RSVP Cryptographic Authentication May 1997 29 1. Introduction | 31 The Resource ReSerVation Protocol RSVP [1] is a protocol for 32 setting up distributed state in routers and hosts, and in 33 particular for reserving resources to implement integrated 34 service. RSVP allows particular users to obtain preferential 35 access to network resources, under the control of an admission 36 control mechanism. Permission to make a reservation will 37 depend both upon the availability of the requested resources 38 along the path of the data, and upon satisfaction of policy 39 rules. 41 To protect the integrity of this admission control mechanism, 42 RSVP requires the ability to protect its messages against 43 corruption and spoofing. This document proposes a mechanism 44 to protect RSVP message integrity hop-by-hop. The proposed 45 scheme transmits the result of applying a cryptographic | 46 algorithm to a one-way function or "digest" of the message 47 together with a secret Authentication Key. This scheme 48 affords protection against forgery or message modification, 49 but not replays. It is possible to replay a message until the 50 sequence number changes, but the sequence number makes replays 51 less of an issue. The proposed mechanism does not afford 52 confidentiality, since messages stay in the clear; however, 53 the mechanism is also exportable from most countries, which 54 would be impossible were a privacy algorithm to be used. 56 The proposed mechanism is independent of a specific 57 cryptographic algorithm, but the document describes the use of | 58 Keyed-Hashing for Message Authentication using H-MD5 [7] [9] | 59 for this purpose. As noted in [9], there exist stronger | 60 hashes, such as H-SHA-1; where warranted, implementations will | 61 do well to make them available. However, in the general case, | 62 [9] suggests that H-MD5 is adequate to the purpose at hand and | 63 has preferable performance characteristics. [9] also offers | 64 source code and test vectors for this algorithm, a boon to | 65 those who would test for interoperability. The author | 66 therefore suggests that H-MD5 should be the baseline, | 67 universally implemented by RSVP implementations implementing | 68 cryptographic authentication, with other proposals optional. 70 The cost of computing an H-MD5 message digest far exceeds the | 71 cost of computing an RSVP checksum; therefore the RSVP 72 checksum should be disabled (set to zero) ifH-MD5 | 73 authentication is used, as theH-MD5 digest is a much stronger 74 integrity check. 76 Draft RSVP Cryptographic Authentication May 1997 78 Two uses are envisioned: authentication of RSVP messages or 79 message fragments (should a fragmentation procedure be defined 80 in the future), and authentication of sessions. The INTEGRITY 81 object used in both is the same, and is defined in this 82 document. The use of the INTEGRITY object for those purposes 83 is defined in other more appropriate documents [1] [8]. | 85 1.1. Why not use the Standard IPSEC Authentication Header? | 87 One obvious question is why, since there exists a standard 88 mechanism for authentication, we would choose to not use it. 89 This was discussed at length in the working group, and was 90 rejected due to the operational impact of manually opening a 91 new security association among the routers that a flow 92 traverses for each flow making reservations. In addition, it | 93 was noted that neighbor relationships between RSVP systems are | 94 not limited to those which face one another across a | 95 communication channel; RSVP relationships across non-RSVP | 96 clouds, such as those described in section 2.8 of [1], are not | 97 necessarily visible to the sending system, suggesting that key | 98 management based on the source address may be a simpler key | 99 management strategy. 101 It is also not clear that RSVP messages are well defined for 102 the security associations, as a router must forward PATH and 103 PATH TEAR messages using the same source address as the sender 104 listed in the SENDER TEMPLATE, as in RSVP traffic may | 105 otherwise not follow exactly the same IP path as data traffic. 107 These matters are simplified if a secure key management 108 protocol exists which can be used to open and key the security 109 associations; should such a protocol come into existence, it 110 may be worthwhile reviewing this decision. However, the non- | 111 RSVP cloud considerations conspire against using the same | 112 solution as one which would work for IPSEC. Therefore, this 113 consideration cannot be understood as a promise that this 114 procedure will go away. 116 2. Data Structures 118 2.1. INTEGRITY Object Format * 120 The RSVP Message consists of a sequence of "objects," which 121 are type-length-value encoded fields having specific purposes. 122 The information required for hop-by-hop integrity checking is 124 Draft RSVP Cryptographic Authentication May 1997 126 carried in an INTEGRITY object. 128 The contents of INTEGRITY object are defined as a "Keyed 129 Message Digest" structure, with one of the following formats: 131 IP4 Keyed Message Digest INTEGRITY Object: Class = 4, | 132 C-Type = 1 134 +-------------+-------------+-------------+-------------+ * 135 | Key Identifier | 136 +-------------+-------------+-------------+-------------+ 137 | Sequence Number | 138 +-------------+-------------+-------------+-------------+ 139 | Sending System IP4 Address | 140 +-------------+-------------+-------------+-------------+ 141 | | 142 + + 143 | | 144 + Keyed Message Digest | 145 | | 146 + + 147 | | 148 +-------------+-------------+-------------+-------------+ 150 IP6 Keyed Message Digest INTEGRITY Object: Class = 4, * 151 C-Type = 2 153 +-------------+-------------+-------------+-------------+ * 154 | Key Identifier | 155 +-------------+-------------+-------------+-------------+ 156 | Sequence Number | 157 +-------------+-------------+-------------+-------------+ 158 | | 159 + + 160 | | 161 + Sending System IP6 Address + 162 | | 163 + + 164 | | 165 +-------------+-------------+-------------+-------------+ 166 | | 167 + + 168 | | 169 + Keyed Message Digest + 170 | | 171 + + 172 | | 174 Draft RSVP Cryptographic Authentication May 1997 176 +-------------+-------------+-------------+-------------+ 178 (1) Key Identifier | 180 An unsigned 32-bit number that acts as a key selector. 181 With the key, the system stores an algorithm for its 182 application. 184 (2) Sending System Address 186 This is the same address as would be carried in the 187 Next Hop or Previous Hop object, the address of the 188 interface of the RSVP system that sent this message. 190 (3) Sequence Number 192 unsigned 32-bit non-decreasing sequence number. | 194 Any non-decreasing sequence of numbers may be used as 195 Sequence Number values. For example, a timestamp on 196 the message's creation or a simple message counter 197 might be used. 199 This sequence number is reset to zero upon any key 200 change. | 202 Note that when procedures such as the Network Time | 203 Protocol [10] are in use to synchronize clocks, it is | 204 feasible and advisable to use the current time as a | 205 sequence number. Doing this obviates the need to | 206 store sequence numbers in memory that survives a | 207 system or process failure. 209 (4) Keyed Message Digest 211 The digest must be a multiple of 4 octets long. For | 212 H-MD5, it will be 16 bytes long. 214 2.2. H-MD5 Message Header and Trailer | 216 The H-MD5 algorithm requires affixing a header and trailer to | 217 the message to be sent before the hash is computed. This | 218 extra information is not transmitted, since the receiver can 219 reconstruct it knowing the message length and hash algorithm. 221 The content of this trailer is specified by [7] and [9]. | 223 Draft RSVP Cryptographic Authentication May 1997 225 3. Message Processing Rules 227 3.1. Message Generation * 229 An RSVP message is created as specified in [1], with these | 230 exceptions: * 232 (1) The RSVP checksum is not calculated, but is set to zero. | 234 (2) The INTEGRITY object is inserted in the appropriate 235 place, and its location in the message is remembered for 236 later use. 238 (3) The current sequence number is placed in the Sequence 239 Number field of the INTEGRITY object. 241 If several messages are being created simultaneously (for 242 example, in a periodic refresh generated by a router), 243 the messages should all use the same sequence number. 244 This is to assure that message reordering between RSVP 245 peers (in non-FIFO queues or in an RSVP tunnel) does not 246 cause authentication to fail for some of them. 248 (4) The appropriate Authentication Key is selected and placed 249 in the Keyed Message Digest field of the INTEGRITY 250 object. 252 (5) The Key Identifier is placed into the INTEGRITY object. 254 (6) The H-MD5 message header and trailer are placed in memory | 255 as described in [7] and [9]. 257 (7) A Keyed Message Digest of the augmented message is 258 calculated using the appropriate hash algorithm. When | 259 the H-MD5 algorithm is used, the hash calculation is | 260 described in [7] and [9]. 262 (8) The digest is written into the Cryptographic Digest field 263 of the INTEGRITY object, overlaying the Authentication 264 Key. 266 In the sender, Authentication Key selection is based on the * 267 interface through which the message is sent, there being a key 268 configured per interface. While administrations may configure 269 all the routers and hosts on a subnet (or for that matter, in 270 their network) with the same key, implementations should 271 assume that each sender may send with a different key on each 273 Draft RSVP Cryptographic Authentication May 1997 275 numbered interface, and that they keys are simplex - the key 276 that a system uses to sign its messages need he same key that 277 its recievers use to sign theirs. Implementations SHOULD | 278 maintain a separate key per ip address that they sign with. 280 This restriction to numbered interfaces is intentional; if an 281 RSVP system peers with another through a set of non-RSVP 282 routers, and it might be able to reach systems through that 283 domain from either a numbered interface or an unnumbered 284 interface using the same address as a router id, the choice of 285 key would otherwise be ambiguous. Therefore, on unnumbered 286 interfaces, an RSVP router must use the same key as it uses on 287 the related numbered interface. User interfaces SHOULD 288 provide convenient ways to configure these keys. * 290 3.2. Message Reception 292 When the message is received, the process is reversed: 294 (1) The RSVP checksum is not calculated. 296 (2) The Cryptographic Digest field of the INTEGRITY object is 297 set aside. 299 (3) The Key Identifer field and Sending System Address are 300 used to determine the Authentication Key and the hash 301 algorithm to be used. Implementations SHOULD maintain a 302 key per neighboring RSVP system address or CIDR prefix, 303 as the keys used by neighbors to sign their messages need 304 not be the same key that the recieving system uses. 306 (4) If the received sequence number is less than the last 307 sequence number received from the sending system with 308 that key identifier, the message is discarded 309 unprocessed. 311 (5) The Cryptographic Digest field of the INTEGRITY object is 312 overlaid with the Authentication Key. 314 (6) The message header and trailer are reconstructed. | 316 (7) A new digest is calculated using the indicated algorithm. | 318 (8) If the calculated digest does not match the received 319 digest, the message is discarded without further | 320 processing. 322 Draft RSVP Cryptographic Authentication May 1997 324 If a system detects the loss of a neighbor or interface, or 325 the RSVP process is restarted on a system, the system should 326 start with a new key if possible. In this way, the sequence 327 number may be reset without exposure to a replay attack. In 328 the event that no other key is available, the sequence number 329 should be stored in non-volatile memory around failures, so | 330 that it may continue without decreasing, or (if the NTP | 331 timestamp is being used as a sequence number), RSVP | 332 resynchronization should await NTP synchronization. 334 4. Key Management 336 It is likely that the IETF will define a standard key * 337 management protocol. It is strongly desirable to use that key 338 management protocol to distribute RSVP Authentication Keys 339 among communicating RSVP implementations. Such a protocol 340 would provide scalability and significantly reduce the human 341 administrative burden. The Key ID can be used as a hook 342 between RSVP and such a future protocol. Key management 343 protocols have a long history of subtle flaws that are often 344 discovered long after the protocol was first described in 345 public. To avoid having to change all RSVP implementations 346 should such a flaw be discovered, integrated key management 347 protocol techniques were deliberately omitted from this 348 specification. 350 4.1. Key Management Procedures 352 Each key has a lifetime associated with it. No key is ever 353 used outside its lifetime. If more than one key is currently 354 alive, then the youngest key (the key whose lifetime most 355 recently started) should be sent, and all "live" keys should | 356 be tested upon message receipt. 358 Possible mechanisms for managing key lifetime include: the use | 359 of the Network Time Protocol, hardware time-of-day clocks, or 360 waiting some time before emitting the first message to 361 determine what key other systems are signing with. The matter 362 is left for the implementor. Note that the concept of a "key 363 lifetime" does not require a hardware time-of-day clock or the 364 use of NTP, although one or the other is advised; it merely 365 requires that the earliest and latest times that the key is 366 valid must be programmable in a way the system understands. 368 To maintain security, it is advisable to change the RSVP | 369 Authentication Key on a regular basis. It should be possible | 371 Draft RSVP Cryptographic Authentication May 1997 373 to switch the RSVP Authentication Key without loss of RSVP 374 state or denial of reservation service, and without requiring 375 people to change all the keys at once. This requires the RSVP 376 implementation to support the storage and use of more than one 377 RSVP Authentication Key on a given interface at the same time. 379 For each key there will be a locally-stored Key Identifier. 380 The combination of the Key Identifier and the interface 381 associated with the message uniquely identifies the 382 cryptographic algorithm and Authentication Key in use by RSVP. 383 As noted above, the party creating the RSVP message will 384 select a valid key from the set of valid keys for that 385 interface. The receiver will use the Key Identifier and 386 interface to determine which key to use for authentication of 387 the received message. More than one key may be associated 388 with an interface at the same time. 390 To ensure a smooth switch-over, each communicating RSVP system 391 must be updated with the new key before the current key will | 392 expire and before the new key lifetime begins. The new key 393 should have a lifetime that starts several minutes before the 394 old key expires. This gives time for each system to learn of 395 the new RSVP Authentication Key before that key will be used. 396 It also ensures that the new key will begin being used and the 397 current key will go out of use before the current key's 398 lifetime expires. For the duration of the overlap in key 399 lifetimes, a system may receive messages using either key and 400 authenticate the message. 402 There are four important times for each key: 404 + KeyStartReceive: the time the system starts accepting 405 received packets signed with the key. 407 + KeyStartSign: the time the system starts signing packets 408 with the key. 410 + KeyStopSign: the time the system stops signing packets 411 with the key, which implies that it starts signing with 412 the next key, if any. 414 + KeyStopReceive: the time the system stops accepting 415 received packets signed with the key. 417 The times in the order listed SHOULD form a non-decreasing 418 sequence. There needs to be some distance between start times 419 and stop times, to achieve a seamless transition. Each system 421 Draft RSVP Cryptographic Authentication May 1997 423 sends using the key with the most recent "start" time and 424 makes its first attempt at validation of incoming traffic with 425 this same key. If this validation fails and another (older) 426 key is also active, the system should attempt to validate with 427 any other active keys it may possess. * 429 4.2. Key Management Requirements 431 Requirements on an implementation are as follows. * 433 (1) It is strongly desirable that a hypothetical security 434 breach in one Internet protocol not automatically 435 compromise other Internet protocols. The Authentication 436 Key of this specification SHOULD NOT be stored using 437 protocols or algorithms that have known flaws. 439 (2) An implementation MUST support the storage of more than 440 one key at the same time, although normally only one key 441 will be active on an interface. 443 (3) An implementation MUST associate a specific lifetime 444 (i.e., KeyStartSign and KeyStopSign) with each key and 445 corresponding Key Identifier. 447 (4) An implementation MUST support manual key distribution 448 (e.g., the privileged user manually typing in the key, 449 key lifetime, and key identifier on the console). The 450 lifetime may be infinite. 452 (5) If more than one algorithm is supported, then the 453 implementation MUST require that the algorithm be 454 specified for each key at the time the other key 455 information is entered. 457 (6) Keys that are out of date MAY be deleted at will by the 458 implementation without requiring human intervention. 460 (7) Manual deletion of active keys SHOULD also be supported. 462 (8) Key storage SHOULD persist across a system restart, warm 463 or cold, to avoid operational issues, and an acceptable | 464 sequence number SHOULD be derivable either from non- | 465 volatile memory or a procedure such as NTP. 467 Draft RSVP Cryptographic Authentication May 1997 469 4.3. Pathological Cases 471 An implementation of this document must handle two 472 pathological cases. Both of these should be exceedingly rare. 474 (1) During key switch-over, devices may exist which have not 475 yet been successfully configured with the new key. 477 Therefore, systems MAY implement (and would be well 478 advised to implement) an algorithm that detects the set 479 of keys being used by its neighbors, and transmits its 480 messages using both the new and old keys until all the 481 neighbors are using the new key or the lifetime of the 482 old key expires. Under normal circumstances, this 483 elevated transmission rate will exist for a single 484 refresh interval. 486 (2) It is possible that the last key associated with an 487 interface may expire. 489 When this happens, it is unacceptable to revert to an 490 unauthenticated condition, and not advisable to disrupt 491 current reservations. Therefore, the system should send 492 a "last authentication key expiration" notification to 493 the network manager and treat the key as having an 494 infinite lifetime until the lifetime is extended, the key 495 is deleted by network management, or a new key is 496 configured. * 498 5. Conformance Requirements 500 To conform to this specification, an implementation MUST 501 support all of its aspects. The H-MD5 authentication | 502 algorithm defined in [7] and [9] MUST be implemented by all 503 conforming implementations. A conforming implementation MAY 504 also support other authentication algorithms such as NIST's 505 Secure Hash Algorithm (SHA). Manual key distribution as 506 described above MUST be supported by all conforming 507 implementations. All implementations MUST support the smooth 508 key rollover described under "Key Change Procedures." 510 The user documentation provided with the implementation MUST 511 contain clear instructions on how to ensure that smooth key 512 rollover occurs. 514 Implementations SHOULD support a standard key management 515 protocol for secure distribution of RSVP Authentication Keys 517 Draft RSVP Cryptographic Authentication May 1997 519 once such a key management protocol is standardized by the 520 IETF. | 522 6. Acknowledgments | 524 This document is derived directly from similar work done for 525 OSPF and RIP Version II, jointly by Ran Atkinson and Fred | 526 Baker. Significant editing was sone by Bob Braden, resulting | 527 in increased clarity. (if you think this document was hard to | 528 read, think about what Bob read). Signifiant comments were | 529 submitted by Steve Bellovin, who actually understands this | 530 stuff. 532 7. References 534 [1] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and 535 S. Jamin, "Resource ReSerVation Protocol (RSVP) -- 536 Version 1 Functional Specificationq. Internet Draft | 537 draft-ietf-rsvp-spec-14.ps, January 1997. 539 [2] S. Bellovin, "Security Problems in the TCP/IP Protocol * 540 Suite", ACM Computer Communications Review, Volume 19, 541 Number 2, pp.32-48, April 1989. | 543 [3] N. Haller, R. Atkinson, "Internet Authentication 544 Guidelines", Request for Comments 1704, October 1994. | 546 [4] R. Braden, D. Clark, S. Crocker, & C. Huitema, 547 "Report of IAB Workshop on Security in the Internet 548 Architecture", Request for Comments 1636, June 1994. | 550 [5] R. Atkinson, "IP Authentication Header", Request for | 551 Comments 1826, August 1995. | 553 [6] R. Atkinson, "IP Encapsulating Security Payload", | 554 Request for Comments 1827, August 1995. | 556 [7] P. Metzger, W. Simpson, "IP Authentication using H- | 557 MD5", Request for Comments 1828, August 1995. | 559 [8] S. Herzog, 561 "RSVP Extensions for Policy Control", draft-ietf-rsvp- | 562 policy-ext-02.txt, March 1997. | 564 Draft RSVP Cryptographic Authentication May 1997 566 [9] Krawczyk, Bellare, and Canetti, | 568 "HMAC: Keyed-Hashing for Message Authentication", Request | 569 for Comments 2104, March 1996. 571 Draft RSVP Cryptographic Authentication May 1997 573 8. Security Considerations 575 This entire memo describes and specifies an authentication 576 mechanism for RSVP that is believed to be secure against 577 active and passive attacks. Passive attacks are widespread in | 578 the Internet at present. Protection against active attacks is 579 also needed even though such attacks are not as widespread. | 581 Users need to understand that the quality of the security 582 provided by this mechanism depends completely on the strength 583 of the implemented authentication algorithms, the strength of 584 the key being used, and the correct implementation of the 585 security mechanism in all communicating RSVP implementations. 586 This mechanism also depends on the RSVP Authentication Keys 587 being kept confidential by all parties. If any of these | 588 assumptions are incorrect or procedures are insufficiently | 589 secure, then no real security will be provided to the users of | 590 this mechanism. 592 Confidentiality is not provided by this mechanism; if this is | 593 required, IPSEC ESP may be the best approach, although it is | 594 subject to the same criticisms as IPSEC Authetication, and | 595 therefore would be applicable only in specific environments. 596 Protection against traffic analysis is also not provided. 597 Mechanisms such as bulk link encryption might be used when 598 protection against traffic analysis is required. * 600 9. Author's Address 602 Fred Baker 603 Cisco Systems 604 519 Lado Drive 605 Santa Barbara, 606 California 93111 607 Phone: (408) 526-4257 608 Email: fred@cisco.com 610 Draft RSVP Cryptographic Authentication May 1997 612 Table of Contents 614 1 Introduction .......................................... 2 615 1.1 Why not use the Standard IPSEC Authentication 616 Header? ........................................... 3 617 2 Data Structures ....................................... 3 618 2.1 INTEGRITY Object Format ............................. 3 619 2.2 H-MD5 Message Header and Trailer .................... 5 620 3 Message Processing Rules .............................. 6 621 3.1 Message Generation .................................. 6 622 3.2 Message Reception ................................... 7 623 4 Key Management ........................................ 8 624 4.1 Key Management Procedures ........................... 8 625 4.2 Key Management Requirements ......................... 10 626 4.3 Pathological Cases .................................. 11 627 5 Conformance Requirements .............................. 11 628 6 Acknowledgments ....................................... 12 629 7 References ............................................ 12 630 8 Security Considerations ............................... 14 631 9 Author's Address ...................................... 14