HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:29:34 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 10 Jun 1996 22:20:00 GMT ETag: "2f51df-7c2c-31bc9f90" Accept-Ranges: bytes Content-Length: 31788 Connection: close Content-Type: text/plain Draft RSVP Cryptographic Authentication June 1996 RSVP Cryptographic Authentication | draft-ietf-rsvp-md5-02.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Abstract This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. Fred Baker Expiration: December 1996 [Page 1] Draft RSVP Cryptographic Authentication June 1996 1. Introduction The Resource ReSerVation Protocol RSVP [1] is a protocol for setting up distributed state in routers and hosts, and in particular for reserving resources to implement integrated service. RSVP allows particular users to obtain preferential access to network resources, under the control of an admission control mechanism. Permission to make a reservation will depend both upon the availability of the requested resources along the path of the data, and upon satisfaction of policy rules. To protect the integrity of this admission control mechanism, RSVP requires the ability to protect its messages against corruption and spoofing. This document proposes a mechanism to protect RSVP message integrity hop-by-hop. The proposed scheme transmits the result of applying a cryptographic algorithm to a one-way function or ``digest'' of the message together with a secret Authentication Key. This scheme affords protection against forgery or message modification, but not replays. It is possible to replay a message until the sequence number changes, but the sequence number makes replays less of an issue. The proposed mechanism does not afford confidentiality, since messages stay in the clear; however, the mechanism is also exportable from most countries, which would be impossible were a privacy algorithm to be used. The proposed mechanism is independent of a specific cryptographic algorithm, but the document describes the use of Keyed MD5 [2] for this purpose. The cost of computing a Keyed MD5 message digest far exceeds the cost of computing an RSVP checksum; therefore the RSVP | checksum should be disabled (set to zero) if MD5 | authentication is used, as the MD5 digest is a much stronger integrity check. Two uses are envisioned: authentication of RSVP messages or | message fragments (should a fragmentation procedure be defined | in the future), and authentication of sessions. The INTEGRITY | object used in both is the same, and is defined in this | document. The use of the INTEGRITY object for those purposes | is defined in other more appropriate documents [1] [9]. Fred Baker Expiration: December 1996 [Page 2] Draft RSVP Cryptographic Authentication June 1996 1.1. Why not use the Standard IPSEC Authentication Header? | One obvious question is why, since there exists a standard | mechanism for authentication, we would choose to not use it. This was discussed at length in the working group, and was rejected due to the operational impact of manually opening a new security association among the routers that a flow traverses for each flow making reservations. | It is also not clear that RSVP messages are well defined for the security associations, as a router must forward PATH and PATH TEAR messages using the same source address as the sender listed in the SENDER TEMPLATE, as in RSVP tunnels traffic may not follow exactly the same IP path otherwise. These matters are simplified if a secure key management | protocol exists which can be used to open and key the security | associations; should such a protocol come into existence, it | may be worthwhile reviewing this decision. However, the | addressing considerations conspire against using the same | solution as one which would work for IPSEC. Therefore, this | consideration cannot be understood as a promise that this | procedure will go away. 2. Data Structures 2.1. INTEGRITY Object Format The RSVP Message consists of a sequence of "objects," which are type-length-value encoded fields having specific purposes. The information required for hop-by-hop integrity checking is carried in an INTEGRITY object. The contents of INTEGRITY object are defined as a "Keyed Message Digest" structure, with one of the following formats: | Fred Baker Expiration: December 1996 [Page 3] Draft RSVP Cryptographic Authentication June 1996 IP4 Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1| +-------------+-------------+-------------+-------------+ | Key Identifier | +-------------+-------------+-------------+-------------+ | Sequence Number | | +-------------+-------------+-------------+-------------+ | Sending System IP4 Address | | +-------------+-------------+-------------+-------------+ | | | | + + | | | | + Keyed Message Digest | | | | | + + | | | | +-------------+-------------+-------------+-------------+ | IP6 Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 2| +-------------+-------------+-------------+-------------+ | | Key Identifier | | +-------------+-------------+-------------+-------------+ | | Sequence Number | +-------------+-------------+-------------+-------------+ | | + + | | + Sending System IP6 Address + | | | + + | | +-------------+-------------+-------------+-------------+ | | | + + | | | | + Keyed Message Digest + | | | | + + | | | | +-------------+-------------+-------------+-------------+ | Fred Baker Expiration: December 1996 [Page 4] Draft RSVP Cryptographic Authentication June 1996 (1) Key Indentifier An unsigned 32-bit number that acts as a key selector. | With the key, the system stores an algorithm for its | application. (2) Sending System Address This is the same address as would be carried in the Next Hop or Previous Hop object, the address of the | interface of the RSVP system that sent this message. (3) Sequence Number An unsigned 32-bit non-decreasing sequence number. Any non-decreasing sequence of numbers may be used as Sequence Number values. For example, a timestamp on the message's creation or a simple message counter might be used. This sequence number is reset to zero upon any key change. (4) Keyed Message Digest | The digest must be a multiple of 4 octets long. For MD5, it will be 16 bytes long. 2.2. Keyed MD5 Message Trailer The Keyed MD5 algorithm requires appending the following message trailer to the message to be sent, before the hash is computed. However, this trailer is not transmitted, since the receiver can reconstruct it knowing the message length and hash algorithm. The trailer consists of bytes to pad the length appropriately followed by the a 64-bit unsigned integer equal to the length of the RSVP message without the trailer. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more pad bytes (defined by [2] or[8] when MD5 is used)|| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 bit message length MSW | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fred Baker Expiration: December 1996 [Page 5] Draft RSVP Cryptographic Authentication June 1996 | 64 bit message length LSW | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Message Processing Rules 3.1. Message Generation An RSVP message is created as usual, with these exceptions: (1) The RSVP checksum is not calculated, but it set to zero. (2) The INTEGRITY object is inserted in the appropriate place, and its location in the message is remembered for later use. (3) The current sequence number is placed in the Sequence Number field of the INTEGRITY object. If several messages are being created simultaneously (for example, in a periodic refresh generated by a router), the messages should all use the same sequence number. This is to assure that message reordering between RSVP | peers (in non-FIFO queues or in an RSVP tunnel) does not | cause authentication to fail for some of them. (4) The appropriate Authentication Key is selected and placed in the Keyed Message Digest field of the INTEGRITY | object. (5) The Key Identifier is placed into the INTEGRITY object. | (6) The Keyed MD5 message trailer is appended to the end of the message in memory. (7) A Keyed Message Digest of the augmented message is | calculated using the appropriate hash algorithm. When the Keyed MD5 algorithm is used, the hash calculation is | described in [2] and [8]. (8) The digest is written into the Cryptographic Digest field of the INTEGRITY object, overlaying the Authentication Key. In the sender, Authentication Key selection is based on the | interface through which the message is sent, there being a key | Fred Baker Expiration: December 1996 [Page 6] Draft RSVP Cryptographic Authentication June 1996 configured per interface. While administrations may configure | all the routers and hosts on a subnet (or for that matter, in | their network) with the same key, implementations should | assume that each sender may send with a different key on each | numbered interface, and that they keys are simplex - the key | that a system uses to sign its messages need he same key that | its recievers use to sign theirs. Implementations SHOULD | maintain a separate key per interface that they sign with. This restriction to numbered interfaces is intentional; if an | RSVP system peers with another through a set of non-RSVP | routers, and it might be able to reach systems through that | domain from either a numbered interface or an unnumbered | interface using the same address as a router id, the choice of | key would otherwise be ambiguous. Therefore, on unnumbered | interfaces, an RSVP router must use the same key as it uses on | the related numbered interface. User interfaces SHOULD | provide convenient ways to configure these keys. | 3.2. Message Reception When the message is received, the process is reversed: (1) The RSVP checksum is not calculated. (2) The Cryptographic Digest field of the INTEGRITY object is set aside. (3) The Key Identifer field and Sending System Address are used to determine the Authentication Key and the hash algorithm to be used. Implementations SHOULD maintain a | key per neighboring RSVP system address or CIDR prefix, | as the keys used by neighbors to sign their messages need | not be the same key that the recieving system uses. (4) If the received sequence number is less than the last | sequence number received from the sending system with | that key identifier, the message is discarded | unprocessed. | (5) The Cryptographic Digest field of the INTEGRITY object is overlaid with the Authentication Key. (6) The Keyed MD5 message trailer is reconstructed at the end of the message. Fred Baker Expiration: December 1996 [Page 7] Draft RSVP Cryptographic Authentication June 1996 (7) A new digest calculated using the indicated algorithm. (8) If the calculated digest does not match the received digest, the message is discarded unprocessed. | If a system detects the loss of a neighbor or interface, or | the RSVP process is restarted on a system, the system should | start with a new key if possible. In this way, the sequence | number may be reset without exposure to a replay attack. In | the event that no other key is available, the sequence number | should be stored in non-volatile memory around failures, so | that it may continue without decreasing. 4. Key Management It is likely that the IETF will define a standard key management protocol. It is strongly desirable to use that key management protocol to distribute RSVP Authentication Keys among communicating RSVP implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key ID can be used as a hook between RSVP and such a future protocol. Key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public. To avoid having to change all RSVP implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification. 4.1. Key Management Procedures Each key has a lifetime associated with it. No key is ever used outside its lifetime. If more than one key is currently alive, then the youngest key (the key whose lifetime most recently started) should be used. Possible mechanisms for managing key lifetime include: the use of the Network Time Protocol, hardware time-of-day clocks, or waiting some time before emitting the first message to determine what key other systems are signing with. The matter is left for the implementor. Note that the concept of a "key lifetime" does not require a hardware time-of-day clock or the use of NTP, although one or the other is advised; it merely requires that the earliest and latest times that the key is valid must be programmable in a way the system understands. Fred Baker Expiration: December 1996 [Page 8] Draft RSVP Cryptographic Authentication June 1996 To maintain security, it is necessary to change the RSVP Authentication Key on a regular basis. It must be possible to switch the RSVP Authentication Key without loss of RSVP state or denial of reservation service, and without requiring people to change all the keys at once. This requires the RSVP implementation to support the storage and use of more than one RSVP Authentication Key on a given interface at the same time. For each key there will be a locally-stored Key Identifier. The combination of the Key Identifier and the interface associated with the message uniquely identifies the cryptographic algorithm and Authentication Key in use by RSVP. As noted above, the party creating the RSVP message will select a valid key from the set of valid keys for that interface. The receiver will use the Key Identifier and interface to determine which key to use for authentication of the received message. More than one key may be associated with an interface at the same time. To ensure a smooth switch-over, each communicating RSVP system must be updated with the new key several minutes before the current key will expire and several minutes before the new key lifetime begins. The new key should have a lifetime that starts several minutes before the old key expires. This gives time for each system to learn of the new RSVP Authentication Key before that key will be used. It also ensures that the new key will begin being used and the current key will go out of use before the current key's lifetime expires. For the duration of the overlap in key lifetimes, a system may receive messages using either key and authenticate the message. There are four important times for each key: + KeyStartReceive: the time the system starts accepting received packets signed with the key. + KeyStartSign: the time the system starts signing packets with the key. + KeyStopSign: the time the system stops signing packets with the key, which implies that it starts signing with the next key, if any. + KeyStopReceive: the time the system stops accepting received packets signed with the key. Fred Baker Expiration: December 1996 [Page 9] Draft RSVP Cryptographic Authentication June 1996 The times in the order listed SHOULD form a non-decreasing sequence. There needs to be some distance between start times and stop times, to achieve a seamless transition. Each system sends using the key with the most recent "start" time and makes its first attempt at validation of incoming traffic with this same key. If this validation fails and another (older) key is also active, the system should attempt to validate with any other active keys it may possess. 4.2. Key Management Requirements Requirements on an implementation are as follows. (1) It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be stored using protocols or algorithms that have known flaws. (2) An implementation MUST support the storage of more than one key at the same time, although normally only one key will be active on an interface. (3) An implementation MUST associate a specific lifetime (i.e., KeyStartSign and KeyStopSign) with each key and corresponding Key Identifier. (4) An implementation MUST support manual key distribution (e.g., the privileged user manually typing in the key, key lifetime, and key identifier on the console). The lifetime may be infinite. (5) If more than one algorithm is supported, then the implementation MUST require that the algorithm be specified for each key at the time the other key information is entered. (6) Keys that are out of date MAY be deleted at will by the implementation without requiring human intervention. (7) Manual deletion of active keys SHOULD also be supported. (8) Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues, and the sequence number in use SHOULD be stored with it. Implementations should note, however, that systems with no non-volatile Fred Baker Expiration: December 1996 [Page 10] Draft RSVP Cryptographic Authentication June 1996 storage may reset the sequence number to zero when restarted. 4.3. Pathological Cases An implementation of this document must handle two pathological cases. Both of these should be exceedingly rare. (1) During key switch-over, devices may exist which have not yet been successfully configured with the new key. Therefore, systems MAY implement (and would be well advised to implement) an algorithm that detects the set of keys being used by its neighbors, and transmits its messages using both the new and old keys until all the neighbors are using the new key or the lifetime of the old key expires. Under normal circumstances, this elevated transmission rate will exist for a single refresh interval. (2) It is possible that the last key associated with an interface may expire. When this happens, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt current reservations. Therefore, the system should send a "last authentication key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured. 5. Conformance Requirements To conform to this specification, an implementation MUST support all of its aspects. The MD5 authentication algorithm | defined in [2] and [8] MUST be implemented by all conforming implementations. A conforming implementation MAY also support other authentication algorithms such as NIST's Secure Hash Algorithm (SHA). Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the smooth key rollover described under "Key Change Procedures." The user documentation provided with the implementation MUST contain clear instructions on how to ensure that smooth key rollover occurs. Fred Baker Expiration: December 1996 [Page 11] Draft RSVP Cryptographic Authentication June 1996 Implementations SHOULD support a standard key management protocol for secure distribution of RSVP Authentication Keys once such a key management protocol is standardized by the IETF. 6. Acknowledgment This document is derived directly from similar work done for OSPF and RIP Version II, jointly by Ran Atkinson and Fred Baker, with modifications by Dino Farinacci for IDMR. 7. References [1] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specificationq. Internet Draft | draft-ietf-rsvp-spec-12.ps, May 1996. [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [3] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp.32-48, April 1989. [4] N. Haller, R. Atkinson, "Internet Authentication Guidelines", RFC-1704, October 1994. [5] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, June 1994. [6] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. [7] R. Atkinson, "IP Encapsulating Security Payload", RFC- 1827, August 1995. [8] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC-1828, August 1995. | [9] S. Herzog, "Building Blocks for Accounting and Access | Control", draft-ietf-rsvp-lpm-arch-00.ps, March 1996. Fred Baker Expiration: December 1996 [Page 12] Draft RSVP Cryptographic Authentication June 1996 8. Security Considerations This entire memo describes and specifies an authentication mechanism for RSVP that is believed to be secure against active and passive attacks. Passive attacks are clearly widespread in the Internet at present. Protection against active attacks is also needed even though such attacks are not currently widespread. Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating RSVP implementations. This mechanism also depends on the RSVP Authentication Keys being kept confidential by all parties. If any of these are | incorrect or insufficiently secure, then no real security will | be provided to the users of this mechanism. Confidentiality is not provided by this mechanism. Work is underway within the IETF to specify a standard mechanism for IP-layer encryption. That mechanism might be used to provide confidentiality for RSVP in the future. Protection against traffic analysis is also not provided. Mechanisms such as bulk link encryption might be used when protection against traffic analysis is required. 9. Author's Address Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: (408) 526-4257 Email: fred@cisco.com Fred Baker Expiration: December 1996 [Page 13] Draft RSVP Cryptographic Authentication June 1996 Table of Contents 1 Introduction .......................................... 2 1.1 Why not use the Standard IPSEC Authentication Header? ........................................... 3 2 Data Structures ....................................... 3 2.1 INTEGRITY Object Format ............................. 3 2.2 Keyed MD5 Message Trailer ........................... 5 3 Message Processing Rules .............................. 6 3.1 Message Generation .................................. 6 3.2 Message Reception ................................... 7 4 Key Management ........................................ 8 4.1 Key Management Procedures ........................... 8 4.2 Key Management Requirements ......................... 10 4.3 Pathological Cases .................................. 11 5 Conformance Requirements .............................. 11 6 Acknowledgment ........................................ 12 7 References ............................................ 12 8 Security Considerations ............................... 13 9 Author's Address ...................................... 13 Fred Baker Expiration: December 1996 [Page 14]