[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 2747

          Draft         RSVP Cryptographic Authentication    August 1997
                        RSVP Cryptographic Authentication                 |
                            draft-ietf-rsvp-md5-05.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
          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".
          Comments should be made on the list rsvp@isi.edu.
          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: February 1998           [Page 1]

          Draft         RSVP Cryptographic Authentication    August 1997
          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
          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-Hashing for Message Authentication using H-MD5 [8] for
          this purpose.  As noted in [8], there exist stronger hashes,
          such as H-SHA-1; where warranted, implementations will do well
          to make them available.  However, in the general case, [8]
          suggests that H-MD5 is adequate to the purpose at hand and has
          preferable performance characteristics.  [8] also offers
          source code and test vectors for this algorithm, a boon to
          those who would test for interoperability.  The author
          therefore suggests that H-MD5 should be the baseline,
          universally implemented by RSVP implementations implementing
          cryptographic authentication, with other proposals optional.
          The cost of computing an H-MD5 message digest far exceeds the
          cost of computing an RSVP checksum; therefore the RSVP
          checksum should be disabled (set to zero) if H-MD5              |
          authentication is used, as the H-MD5 digest is a much stronger
          integrity check.
          Fred Baker        Expiration: February 1998           [Page 2]

          Draft         RSVP Cryptographic Authentication    August 1997
          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] [7].         |
          1.1.  Conventions used in this document                         |
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL   |
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and        |
          "OPTIONAL" in this document are to be interpreted as described  |
          in [9].                                                         |
          1.2.  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.  In addition, it
          was noted that neighbor relationships between RSVP systems are
          not limited to those which face one another across a
          communication channel; RSVP relationships across non-RSVP
          clouds, such as those described in section 2.8 of [1], are not
          necessarily visible to the sending system, suggesting that key
          management based on the source address may be a simpler key
          management strategy.
          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 traffic may
          otherwise not follow exactly the same IP path as data traffic.
          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 non-
          RSVP cloud 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.
          Fred Baker        Expiration: February 1998           [Page 3]

          Draft         RSVP Cryptographic Authentication    August 1997
          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:
                 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               +
               |                                                       |
               +                                                       +
               |                                                       |
          Fred Baker        Expiration: February 1998           [Page 4]

          Draft         RSVP Cryptographic Authentication    August 1997
               |                                                       |
               +                                                       +
               |                                                       |
               +              Keyed Message Digest                     +
               |                                                       |
               +                                                       +
               |                                                       |
          (1)  Key Identifier
                  An unsigned 32-bit number that acts as a key selector.
                  With the key, the system stores an algorithm for its
          (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
                  unsigned 32-bit monotonically increasing sequence       |
                  Any monotonically increasing sequence of numbers may    |
                  be used as Sequence Number values.  For example, a      |
                  time stamp on the message's creation or a simple
                  message counter might be used.
                  This sequence number is reset to zero upon any key
                  Note that when procedures such as the Network Time
                  Protocol [10] are in use to synchronize clocks, it is
                  feasible and advisable to use the current time as a
                  sequence number.  Doing this obviates the need to
                  store sequence numbers in memory that survives a
                  system or process failure.
          (4)  Keyed Message Digest
                  The digest must be a multiple of 4 octets long.  For
                  H-MD5, it will be 16 bytes long.
          Fred Baker        Expiration: February 1998           [Page 5]

          Draft         RSVP Cryptographic Authentication    August 1997
          2.2.  H-MD5 Message Header and Trailer
          The H-MD5 algorithm requires affixing a header and trailer to
          the message to be sent before the hash is computed.  This
          extra information is not transmitted, since the receiver can
          reconstruct it knowing the message length and hash algorithm.
          The content of this trailer is specified by [8].
          3.  Message Processing Rules
          3.1.  Message Generation
          An RSVP message is created as specified in [1], with these
          (1)  The RSVP checksum is not calculated, but is 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 incremented and placed in   |
               the Sequence Number field of the INTEGRITY object.  If an  |
               NTP timestamp is being used, it must at this point be      |
               updated or incremented, whichever will result in a unique  |
          (4)  The appropriate Authentication Key is selected and placed
               in the Keyed Message Digest field of the INTEGRITY
          (5)  The Key Identifier is placed into the INTEGRITY object.
          (6)  The H-MD5 message header and trailer are placed in memory
               as described in [8].
          (7)  A Keyed Message Digest of the augmented message is
               calculated using the appropriate hash algorithm.  When
               the H-MD5 algorithm is used, the hash calculation is
               described in [8].
          (8)  The digest is written into the Cryptographic Digest field
               of the INTEGRITY object, overlaying the Authentication
          Fred Baker        Expiration: February 1998           [Page 6]

          Draft         RSVP Cryptographic Authentication    August 1997
          In the sender, Authentication Key selection is based on the
          interface through which the message is sent, there being a key
          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 the keys are simplex - the key     |
          that a system uses to sign its messages need not be same key    |
          that its receivers use to sign theirs.  Implementations SHOULD  |
          maintain a separate key per IP address 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 Identifier 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 receiving system uses.
          (4)  The sequence number is validated to prevent replay         |
               attacks, and invalid sequence numbers are ignored by the   |
               receiver.                                                  |
               If several messages were sent simultaneously (for          |
               example, in a periodic refresh generated by a router, or   |
               as a result of a tear down function), a reordering         |
               problem may arise either due to the use of CBQ/WFQ         |
               queuing algorithms in the sender, or due to reordering in  |
               an intervening non-RSVP cloud.  Therefore, the sequence    |
          Fred Baker        Expiration: February 1998           [Page 7]

          Draft         RSVP Cryptographic Authentication    August 1997
               number may not be exactly the next incremental number.     |
               It is recommended that receivers implement a rotating bit  |
               mask or list structure which identifies sequence numbers   |
               recently apparently skipped by the sender.  Such a data    |
               structure should permit later reception of the message,    |
               but the time skew should not exceed one minute, as we are  |
               dealing with network re-ordering, not retransmission       |
               issues.                                                    |
               When validating a received sequence number, it is valid    |
               if (a) it is the next number in sequence, (b) a past       |
               sequence number that is listed as recently missed, or (c)  |
               a future sequence number within the range of sequence      |
               numbers that the receiver is willing to remember having    |
               skipped.  Such a range is an implementation decision, but  |
               is expected to be on the order of 64 such numbers.         |
               Acceptance of a future sequence number implies adding the  |
               number skipped to the list; Acceptance of a skipped        |
               sequence number implies removing it from the list.
          (5)  The Cryptographic Digest field of the INTEGRITY object is
               overlaid with the Authentication Key.
          (6)  The message header and trailer are reconstructed.
          (7)  A new digest is calculated using the indicated algorithm.
          (8)  If the calculated digest does not match the received
               digest, the message is discarded without further
          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, or (if the NTP time    |
          stamp is being used as a sequence number), RSVP re-             |
          synchronization should await NTP synchronization.
          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
          Fred Baker        Expiration: February 1998           [Page 8]

          Draft         RSVP Cryptographic Authentication    August 1997
          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
          4.1.  Key Management Procedures
          Each key has a lifetime associated with it.  In general, no     |
          key is ever used outside its lifetime (but see section 4.2.4).
          If more than one key is currently alive, then the youngest key
          (the key whose lifetime most recently started) should be sent,
          and all "live" keys should be tested upon message receipt.
          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.
          To maintain security, it is advisable to change the RSVP
          Authentication Key on a regular basis.  It should 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
          Fred Baker        Expiration: February 1998           [Page 9]

          Draft         RSVP Cryptographic Authentication    August 1997
          with an interface at the same time.
          To ensure a smooth switch-over, each communicating RSVP system
          must be updated with the new key before the current key will
          expire and 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 at the time that the current key's         |
          lifetime has expired, all systems have prepared to send and     |
          receive data using the new key.  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:
            o KeyStartReceive: the time the system starts accepting
               received packets signed with the key.
            o KeyStartSign: the time the system starts signing packets
               with the key.
            o KeyStopSign: the time the system stops signing packets
               with the key, which implies that it starts signing with
               the next key, if any.
            o KeyStopReceive: the time the system stops accepting
               received packets signed with the key.
          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.               *
          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.
          Fred Baker        Expiration: February 1998          [Page 10]

          Draft         RSVP Cryptographic Authentication    August 1997
          (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 an acceptable
               sequence number SHOULD be derivable either from non-
               volatile memory or a procedure such as NTP.
          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
          Fred Baker        Expiration: February 1998          [Page 11]

          Draft         RSVP Cryptographic Authentication    August 1997
               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
          5.  Conformance Requirements
          To conform to this specification, an implementation MUST
          support all of its aspects.  The H-MD5 authentication
          algorithm defined in [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 roll over           |
          described under "Key Change Procedures."
          The user documentation provided with the implementation MUST
          contain clear instructions on how to ensure that smooth key     |
          roll over occurs.
          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
          6.  Acknowledgments
          This document is derived directly from similar work done for
          OSPF and RIP Version II, jointly by Ran Atkinson and Fred
          Baker.  Significant editing was done by Bob Braden, resulting   |
          in increased clarity.  (if you think this document was hard to
          read, think about what Bob read).  Significant comments were    |
          submitted by Steve Bellovin, who actually understands this
          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-14.ps, January 1997.
          [2]  S.  Bellovin, "Security Problems in the TCP/IP Protocol
               Suite", ACM Computer Communications Review, Volume 19,
          Fred Baker        Expiration: February 1998          [Page 12]

          Draft         RSVP Cryptographic Authentication    August 1997
               Number 2, pp.32-48, April 1989.
          [3]  N.  Haller, R.  Atkinson, "Internet Authentication
               Guidelines", Request for Comments 1704, October 1994.
          [4]  R.  Braden, D.  Clark, S.  Crocker, & C.  Huitema,
               "Report of IAB Workshop on Security in the Internet
               Architecture", Request for Comments 1636, June 1994.
          [5]  R.  Atkinson, "IP Authentication Header", Request for
               Comments 1826, August 1995.
          [6]  R.  Atkinson, "IP Encapsulating Security Payload",
               Request for Comments 1827, August 1995.
          [7]  S.  Herzog, "RSVP Extensions for Policy Control", draft-
               ietf-rsvp-policy-ext-02.txt, March 1997.
          [8]  Krawczyk, Bellare, and Canetti, "HMAC: Keyed-Hashing for
               Message Authentication", Request for Comments 2104, March
               1996.                                                      |
          [9]  [RFC-2119], Bradner, S., "Key words for use in RFCs to     |
               Indicate Requirement Levels", RFC 2119, Harvard            |
               University, March 1997.                                    |
          Fred Baker        Expiration: February 1998          [Page 13]

          Draft         RSVP Cryptographic Authentication    August 1997
          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 widespread in
          the Internet at present.  Protection against active attacks is
          also needed even though such attacks are not as 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
          assumptions are incorrect or procedures are insufficiently
          secure, then no real security will be provided to the users of
          this mechanism.
          Confidentiality is not provided by this mechanism; if this is
          required, IPSEC ESP may be the best approach, although it is    |
          subject to the same criticisms as IPSEC Authentication, and
          therefore would be applicable only in specific environments.
          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: February 1998          [Page 14]

          Draft         RSVP Cryptographic Authentication    August 1997
          Table of Contents
          1 Introduction ..........................................    2
          1.1 Conventions used in this document ...................    3
          1.2 Why not  use  the  Standard  IPSEC  Authentication
               Header?  ...........................................    3
          2 Data Structures .......................................    4
          2.1 INTEGRITY Object Format .............................    4
          2.2 H-MD5 Message Header and Trailer ....................    6
          3 Message Processing Rules ..............................    6
          3.1 Message Generation ..................................    6
          3.2 Message Reception ...................................    7
          4 Key Management ........................................    8
          4.1 Key Management Procedures ...........................    9
          4.2 Key Management Requirements .........................   10
          4.3 Pathological Cases ..................................   11
          5 Conformance Requirements ..............................   12
          6 Acknowledgments .......................................   12
          7 References ............................................   12
          8 Security Considerations ...............................   14
          9 Author's Address ......................................   14
          Fred Baker        Expiration: February 1998          [Page 15]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/