idnits 2.17.1 draft-ietf-rsvp-md5-05.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-25) 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 Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 513 instances of lines with control characters in the document. ** 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 279: '...ign theirs. Implementations SHOULD |...' RFC 2119 keyword, line 289: '...red interface. User interfaces SHOULD...' RFC 2119 keyword, line 303: '...ed. Implementations SHOULD maintain a...' RFC 2119 keyword, line 448: '...the order listed SHOULD form a non-dec...' RFC 2119 keyword, line 459: '...is specification SHOULD NOT be stored ...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 638 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 (August 1997) is 9750 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 557 looks like a reference -- Missing reference section? '8' on line 585 looks like a reference -- Missing reference section? '7' on line 582 looks like a reference -- Missing reference section? '9' on line 589 looks like a reference -- Missing reference section? '10' on line 210 looks like a reference -- Missing reference section? '2' on line 562 looks like a reference -- Missing reference section? '3' on line 569 looks like a reference -- Missing reference section? '4' on line 572 looks like a reference -- Missing reference section? '5' on line 576 looks like a reference -- Missing reference section? '6' on line 579 looks like a reference -- Missing reference section? 'RFC-2119' on line 589 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft RSVP Cryptographic Authentication August 1997 4 RSVP Cryptographic Authentication | 5 draft-ietf-rsvp-md5-05.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 August 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 [8] for 59 this purpose. As noted in [8], there exist stronger hashes, 60 such as H-SHA-1; where warranted, implementations will do well 61 to make them available. However, in the general case, [8] 62 suggests that H-MD5 is adequate to the purpose at hand and has 63 preferable performance characteristics. [8] 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) if H-MD5 | 73 authentication is used, as the H-MD5 digest is a much stronger 74 integrity check. 76 Draft RSVP Cryptographic Authentication August 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] [7]. | 85 1.1. Conventions used in this document | 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | 88 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | 89 "OPTIONAL" in this document are to be interpreted as described | 90 in [9]. | 92 1.2. Why not use the Standard IPSEC Authentication Header? 94 One obvious question is why, since there exists a standard 95 mechanism for authentication, we would choose to not use it. 96 This was discussed at length in the working group, and was 97 rejected due to the operational impact of manually opening a 98 new security association among the routers that a flow 99 traverses for each flow making reservations. In addition, it 100 was noted that neighbor relationships between RSVP systems are 101 not limited to those which face one another across a 102 communication channel; RSVP relationships across non-RSVP 103 clouds, such as those described in section 2.8 of [1], are not 104 necessarily visible to the sending system, suggesting that key 105 management based on the source address may be a simpler key 106 management strategy. 108 It is also not clear that RSVP messages are well defined for 109 the security associations, as a router must forward PATH and 110 PATH TEAR messages using the same source address as the sender 111 listed in the SENDER TEMPLATE, as in RSVP traffic may 112 otherwise not follow exactly the same IP path as data traffic. 114 These matters are simplified if a secure key management 115 protocol exists which can be used to open and key the security 116 associations; should such a protocol come into existence, it 117 may be worthwhile reviewing this decision. However, the non- 118 RSVP cloud considerations conspire against using the same 119 solution as one which would work for IPSEC. Therefore, this 120 consideration cannot be understood as a promise that this 121 procedure will go away. 123 Draft RSVP Cryptographic Authentication August 1997 125 2. Data Structures 127 2.1. INTEGRITY Object Format 129 The RSVP Message consists of a sequence of "objects," which 130 are type-length-value encoded fields having specific purposes. 131 The information required for hop-by-hop integrity checking is 132 carried in an INTEGRITY object. 134 The contents of INTEGRITY object are defined as a "Keyed 135 Message Digest" structure, with one of the following formats: 137 IP4 Keyed Message Digest INTEGRITY Object: Class = 4, 138 C-Type = 1 140 +-------------+-------------+-------------+-------------+ 141 | Key Identifier | 142 +-------------+-------------+-------------+-------------+ 143 | Sequence Number | 144 +-------------+-------------+-------------+-------------+ 145 | Sending System IP4 Address | 146 +-------------+-------------+-------------+-------------+ 147 | | 148 + + 149 | | 150 + Keyed Message Digest | 151 | | 152 + + 153 | | 154 +-------------+-------------+-------------+-------------+ 156 IP6 Keyed Message Digest INTEGRITY Object: Class = 4, 157 C-Type = 2 159 +-------------+-------------+-------------+-------------+ 160 | Key Identifier | 161 +-------------+-------------+-------------+-------------+ 162 | Sequence Number | 163 +-------------+-------------+-------------+-------------+ 164 | | 165 + + 166 | | 167 + Sending System IP6 Address + 168 | | 169 + + 170 | | 171 +-------------+-------------+-------------+-------------+ 173 Draft RSVP Cryptographic Authentication August 1997 175 | | 176 + + 177 | | 178 + Keyed Message Digest + 179 | | 180 + + 181 | | 182 +-------------+-------------+-------------+-------------+ 184 (1) Key Identifier 186 An unsigned 32-bit number that acts as a key selector. 187 With the key, the system stores an algorithm for its 188 application. 190 (2) Sending System Address 192 This is the same address as would be carried in the 193 Next Hop or Previous Hop object, the address of the 194 interface of the RSVP system that sent this message. 196 (3) Sequence Number 198 unsigned 32-bit monotonically increasing sequence | 199 number. 201 Any monotonically increasing sequence of numbers may | 202 be used as Sequence Number values. For example, a | 203 time stamp on the message's creation or a simple 204 message counter might be used. 206 This sequence number is reset to zero upon any key 207 change. 209 Note that when procedures such as the Network Time 210 Protocol [10] are in use to synchronize clocks, it is 211 feasible and advisable to use the current time as a 212 sequence number. Doing this obviates the need to 213 store sequence numbers in memory that survives a 214 system or process failure. 216 (4) Keyed Message Digest 218 The digest must be a multiple of 4 octets long. For 219 H-MD5, it will be 16 bytes long. 221 Draft RSVP Cryptographic Authentication August 1997 223 2.2. H-MD5 Message Header and Trailer 225 The H-MD5 algorithm requires affixing a header and trailer to 226 the message to be sent before the hash is computed. This 227 extra information is not transmitted, since the receiver can 228 reconstruct it knowing the message length and hash algorithm. 230 The content of this trailer is specified by [8]. 232 3. Message Processing Rules 234 3.1. Message Generation 236 An RSVP message is created as specified in [1], with these 237 exceptions: 239 (1) The RSVP checksum is not calculated, but is set to zero. 241 (2) The INTEGRITY object is inserted in the appropriate 242 place, and its location in the message is remembered for 243 later use. 245 (3) The current sequence number is incremented and placed in | 246 the Sequence Number field of the INTEGRITY object. If an | 247 NTP timestamp is being used, it must at this point be | 248 updated or incremented, whichever will result in a unique | 249 number. 251 (4) The appropriate Authentication Key is selected and placed 252 in the Keyed Message Digest field of the INTEGRITY 253 object. 255 (5) The Key Identifier is placed into the INTEGRITY object. 257 (6) The H-MD5 message header and trailer are placed in memory 258 as described in [8]. 260 (7) A Keyed Message Digest of the augmented message is 261 calculated using the appropriate hash algorithm. When 262 the H-MD5 algorithm is used, the hash calculation is 263 described in [8]. 265 (8) The digest is written into the Cryptographic Digest field 266 of the INTEGRITY object, overlaying the Authentication 267 Key. 269 Draft RSVP Cryptographic Authentication August 1997 271 In the sender, Authentication Key selection is based on the 272 interface through which the message is sent, there being a key 273 configured per interface. While administrations may configure 274 all the routers and hosts on a subnet (or for that matter, in 275 their network) with the same key, implementations should 276 assume that each sender may send with a different key on each 277 numbered interface, and that the keys are simplex - the key | 278 that a system uses to sign its messages need not be same key | 279 that its receivers use to sign theirs. Implementations SHOULD | 280 maintain a separate key per IP address that they sign with. 282 This restriction to numbered interfaces is intentional; if an 283 RSVP system peers with another through a set of non-RSVP 284 routers, and it might be able to reach systems through that 285 domain from either a numbered interface or an unnumbered 286 interface using the same address as a router id, the choice of 287 key would otherwise be ambiguous. Therefore, on unnumbered 288 interfaces, an RSVP router must use the same key as it uses on 289 the related numbered interface. User interfaces SHOULD 290 provide convenient ways to configure these keys. 292 3.2. Message Reception 294 When the message is received, the process is reversed: 296 (1) The RSVP checksum is not calculated. 298 (2) The Cryptographic Digest field of the INTEGRITY object is 299 set aside. 301 (3) The Key Identifier field and Sending System Address are | 302 used to determine the Authentication Key and the hash 303 algorithm to be used. Implementations SHOULD maintain a 304 key per neighboring RSVP system address or CIDR prefix, | 305 as the keys used by neighbors to sign their messages need | 306 not be the same key that the receiving system uses. 308 (4) The sequence number is validated to prevent replay | 309 attacks, and invalid sequence numbers are ignored by the | 310 receiver. | 312 If several messages were sent simultaneously (for | 313 example, in a periodic refresh generated by a router, or | 314 as a result of a tear down function), a reordering | 315 problem may arise either due to the use of CBQ/WFQ | 316 queuing algorithms in the sender, or due to reordering in | 317 an intervening non-RSVP cloud. Therefore, the sequence | 319 Draft RSVP Cryptographic Authentication August 1997 321 number may not be exactly the next incremental number. | 322 It is recommended that receivers implement a rotating bit | 323 mask or list structure which identifies sequence numbers | 324 recently apparently skipped by the sender. Such a data | 325 structure should permit later reception of the message, | 326 but the time skew should not exceed one minute, as we are | 327 dealing with network re-ordering, not retransmission | 328 issues. | 330 When validating a received sequence number, it is valid | 331 if (a) it is the next number in sequence, (b) a past | 332 sequence number that is listed as recently missed, or (c) | 333 a future sequence number within the range of sequence | 334 numbers that the receiver is willing to remember having | 335 skipped. Such a range is an implementation decision, but | 336 is expected to be on the order of 64 such numbers. | 337 Acceptance of a future sequence number implies adding the | 338 number skipped to the list; Acceptance of a skipped | 339 sequence number implies removing it from the list. 341 (5) The Cryptographic Digest field of the INTEGRITY object is 342 overlaid with the Authentication Key. 344 (6) The message header and trailer are reconstructed. 346 (7) A new digest is calculated using the indicated algorithm. 348 (8) If the calculated digest does not match the received 349 digest, the message is discarded without further 350 processing. 352 If a system detects the loss of a neighbor or interface, or 353 the RSVP process is restarted on a system, the system should 354 start with a new key if possible. In this way, the sequence 355 number may be reset without exposure to a replay attack. In 356 the event that no other key is available, the sequence number 357 should be stored in non-volatile memory around failures, so 358 that it may continue without decreasing, or (if the NTP time | 359 stamp is being used as a sequence number), RSVP re- | 360 synchronization should await NTP synchronization. 362 4. Key Management 364 It is likely that the IETF will define a standard key 365 management protocol. It is strongly desirable to use that key 366 management protocol to distribute RSVP Authentication Keys 368 Draft RSVP Cryptographic Authentication August 1997 370 among communicating RSVP implementations. Such a protocol 371 would provide scalability and significantly reduce the human 372 administrative burden. The Key ID can be used as a hook 373 between RSVP and such a future protocol. Key management 374 protocols have a long history of subtle flaws that are often 375 discovered long after the protocol was first described in 376 public. To avoid having to change all RSVP implementations 377 should such a flaw be discovered, integrated key management 378 protocol techniques were deliberately omitted from this 379 specification. 381 4.1. Key Management Procedures 383 Each key has a lifetime associated with it. In general, no | 384 key is ever used outside its lifetime (but see section 4.2.4). 385 If more than one key is currently alive, then the youngest key 386 (the key whose lifetime most recently started) should be sent, 387 and all "live" keys should be tested upon message receipt. 389 Possible mechanisms for managing key lifetime include: the use 390 of the Network Time Protocol, hardware time-of-day clocks, or 391 waiting some time before emitting the first message to 392 determine what key other systems are signing with. The matter 393 is left for the implementor. Note that the concept of a "key 394 lifetime" does not require a hardware time-of-day clock or the 395 use of NTP, although one or the other is advised; it merely 396 requires that the earliest and latest times that the key is 397 valid must be programmable in a way the system understands. 399 To maintain security, it is advisable to change the RSVP 400 Authentication Key on a regular basis. It should be possible 401 to switch the RSVP Authentication Key without loss of RSVP 402 state or denial of reservation service, and without requiring 403 people to change all the keys at once. This requires the RSVP 404 implementation to support the storage and use of more than one 405 RSVP Authentication Key on a given interface at the same time. 407 For each key there will be a locally-stored Key Identifier. 408 The combination of the Key Identifier and the interface 409 associated with the message uniquely identifies the 410 cryptographic algorithm and Authentication Key in use by RSVP. 411 As noted above, the party creating the RSVP message will 412 select a valid key from the set of valid keys for that 413 interface. The receiver will use the Key Identifier and 414 interface to determine which key to use for authentication of 415 the received message. More than one key may be associated 417 Draft RSVP Cryptographic Authentication August 1997 419 with an interface at the same time. 421 To ensure a smooth switch-over, each communicating RSVP system 422 must be updated with the new key before the current key will 423 expire and before the new key lifetime begins. The new key 424 should have a lifetime that starts several minutes before the 425 old key expires. This gives time for each system to learn of 426 the new RSVP Authentication Key before that key will be used. | 427 It also ensures that at the time that the current key's | 428 lifetime has expired, all systems have prepared to send and | 429 receive data using the new key. For the duration of the 430 overlap in key lifetimes, a system may receive messages using 431 either key and authenticate the message. 433 There are four important times for each key: 435 o KeyStartReceive: the time the system starts accepting 436 received packets signed with the key. 438 o KeyStartSign: the time the system starts signing packets 439 with the key. 441 o KeyStopSign: the time the system stops signing packets 442 with the key, which implies that it starts signing with 443 the next key, if any. 445 o KeyStopReceive: the time the system stops accepting 446 received packets signed with the key. 448 The times in the order listed SHOULD form a non-decreasing 449 sequence. There needs to be some distance between start times 450 and stop times, to achieve a seamless transition. * 452 4.2. Key Management Requirements 454 Requirements on an implementation are as follows. 456 (1) It is strongly desirable that a hypothetical security 457 breach in one Internet protocol not automatically 458 compromise other Internet protocols. The Authentication 459 Key of this specification SHOULD NOT be stored using 460 protocols or algorithms that have known flaws. 462 (2) An implementation MUST support the storage of more than 463 one key at the same time, although normally only one key 464 will be active on an interface. 466 Draft RSVP Cryptographic Authentication August 1997 468 (3) An implementation MUST associate a specific lifetime 469 (i.e., KeyStartSign and KeyStopSign) with each key and 470 corresponding Key Identifier. 472 (4) An implementation MUST support manual key distribution 473 (e.g., the privileged user manually typing in the key, 474 key lifetime, and key identifier on the console). The 475 lifetime may be infinite. 477 (5) If more than one algorithm is supported, then the 478 implementation MUST require that the algorithm be 479 specified for each key at the time the other key 480 information is entered. 482 (6) Keys that are out of date MAY be deleted at will by the 483 implementation without requiring human intervention. 485 (7) Manual deletion of active keys SHOULD also be supported. 487 (8) Key storage SHOULD persist across a system restart, warm 488 or cold, to avoid operational issues, and an acceptable 489 sequence number SHOULD be derivable either from non- 490 volatile memory or a procedure such as NTP. 492 4.3. Pathological Cases 494 An implementation of this document must handle two 495 pathological cases. Both of these should be exceedingly rare. 497 (1) During key switch-over, devices may exist which have not 498 yet been successfully configured with the new key. 500 Therefore, systems MAY implement (and would be well 501 advised to implement) an algorithm that detects the set 502 of keys being used by its neighbors, and transmits its 503 messages using both the new and old keys until all the 504 neighbors are using the new key or the lifetime of the 505 old key expires. Under normal circumstances, this 506 elevated transmission rate will exist for a single 507 refresh interval. 509 (2) It is possible that the last key associated with an 510 interface may expire. 512 When this happens, it is unacceptable to revert to an 513 unauthenticated condition, and not advisable to disrupt 514 current reservations. Therefore, the system should send 516 Draft RSVP Cryptographic Authentication August 1997 518 a "last authentication key expiration" notification to 519 the network manager and treat the key as having an 520 infinite lifetime until the lifetime is extended, the key 521 is deleted by network management, or a new key is 522 configured. 524 5. Conformance Requirements 526 To conform to this specification, an implementation MUST 527 support all of its aspects. The H-MD5 authentication 528 algorithm defined in [8] MUST be implemented by all conforming 529 implementations. A conforming implementation MAY also support 530 other authentication algorithms such as NIST's Secure Hash 531 Algorithm (SHA). Manual key distribution as described above 532 MUST be supported by all conforming implementations. All | 533 implementations MUST support the smooth key roll over | 534 described under "Key Change Procedures." 536 The user documentation provided with the implementation MUST 537 contain clear instructions on how to ensure that smooth key | 538 roll over occurs. 540 Implementations SHOULD support a standard key management 541 protocol for secure distribution of RSVP Authentication Keys 542 once such a key management protocol is standardized by the 543 IETF. 545 6. Acknowledgments 547 This document is derived directly from similar work done for 548 OSPF and RIP Version II, jointly by Ran Atkinson and Fred 549 Baker. Significant editing was done by Bob Braden, resulting | 550 in increased clarity. (if you think this document was hard to 551 read, think about what Bob read). Significant comments were | 552 submitted by Steve Bellovin, who actually understands this 553 stuff. 555 7. References 557 [1] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and 558 S. Jamin, "Resource ReSerVation Protocol (RSVP) -- 559 Version 1 Functional Specificationq. Internet Draft 560 draft-ietf-rsvp-spec-14.ps, January 1997. 562 [2] S. Bellovin, "Security Problems in the TCP/IP Protocol 563 Suite", ACM Computer Communications Review, Volume 19, 565 Draft RSVP Cryptographic Authentication August 1997 567 Number 2, pp.32-48, April 1989. 569 [3] N. Haller, R. Atkinson, "Internet Authentication 570 Guidelines", Request for Comments 1704, October 1994. 572 [4] R. Braden, D. Clark, S. Crocker, & C. Huitema, 573 "Report of IAB Workshop on Security in the Internet 574 Architecture", Request for Comments 1636, June 1994. 576 [5] R. Atkinson, "IP Authentication Header", Request for 577 Comments 1826, August 1995. 579 [6] R. Atkinson, "IP Encapsulating Security Payload", 580 Request for Comments 1827, August 1995. 582 [7] S. Herzog, "RSVP Extensions for Policy Control", draft- 583 ietf-rsvp-policy-ext-02.txt, March 1997. 585 [8] Krawczyk, Bellare, and Canetti, "HMAC: Keyed-Hashing for 586 Message Authentication", Request for Comments 2104, March 587 1996. | 589 [9] [RFC-2119], Bradner, S., "Key words for use in RFCs to | 590 Indicate Requirement Levels", RFC 2119, Harvard | 591 University, March 1997. | 593 Draft RSVP Cryptographic Authentication August 1997 595 8. Security Considerations 597 This entire memo describes and specifies an authentication 598 mechanism for RSVP that is believed to be secure against 599 active and passive attacks. Passive attacks are widespread in 600 the Internet at present. Protection against active attacks is 601 also needed even though such attacks are not as widespread. 603 Users need to understand that the quality of the security 604 provided by this mechanism depends completely on the strength 605 of the implemented authentication algorithms, the strength of 606 the key being used, and the correct implementation of the 607 security mechanism in all communicating RSVP implementations. 608 This mechanism also depends on the RSVP Authentication Keys 609 being kept confidential by all parties. If any of these 610 assumptions are incorrect or procedures are insufficiently 611 secure, then no real security will be provided to the users of 612 this mechanism. 614 Confidentiality is not provided by this mechanism; if this is 615 required, IPSEC ESP may be the best approach, although it is | 616 subject to the same criticisms as IPSEC Authentication, and 617 therefore would be applicable only in specific environments. 618 Protection against traffic analysis is also not provided. 619 Mechanisms such as bulk link encryption might be used when 620 protection against traffic analysis is required. 622 9. Author's Address 624 Fred Baker 625 Cisco Systems 626 519 Lado Drive 627 Santa Barbara, 628 California 93111 629 Phone: (408) 526-4257 630 Email: fred@cisco.com 632 Draft RSVP Cryptographic Authentication August 1997 634 Table of Contents 636 1 Introduction .......................................... 2 637 1.1 Conventions used in this document ................... 3 638 1.2 Why not use the Standard IPSEC Authentication 639 Header? ........................................... 3 640 2 Data Structures ....................................... 4 641 2.1 INTEGRITY Object Format ............................. 4 642 2.2 H-MD5 Message Header and Trailer .................... 6 643 3 Message Processing Rules .............................. 6 644 3.1 Message Generation .................................. 6 645 3.2 Message Reception ................................... 7 646 4 Key Management ........................................ 8 647 4.1 Key Management Procedures ........................... 9 648 4.2 Key Management Requirements ......................... 10 649 4.3 Pathological Cases .................................. 11 650 5 Conformance Requirements .............................. 12 651 6 Acknowledgments ....................................... 12 652 7 References ............................................ 12 653 8 Security Considerations ............................... 14 654 9 Author's Address ...................................... 14