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

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

          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
                        RSVP Cryptographic Authentication
                            draft-ietf-rsvp-md5-01.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.
          
          
          
          Table of Contents
          
          
          1 Introduction ..........................................    2
          2 Data Structures .......................................    2
          2.1 INTEGRITY Object Format .............................    2
          2.2 Keyed MD5 Message Trailer ...........................    3
          3 Message Processing Rules ..............................    4
          3.1 Message Generation ..................................    4
          3.2 Message Reception ...................................    5
          4 Key Management ........................................    6
          4.1 Key Management Procedures ...........................    6
          4.2 Key Management Requirements .........................    8
          4.3 Pathological Cases ..................................    8
          5 Conformance Requirements ..............................    9
          6 Acknowledgment ........................................   10
          7 References ............................................   10
          8 Security Considerations ...............................   11
          9 Author's Address ......................................   11
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 1]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          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; we propose that the
          RSVP checksum be disabled if MD5 authentication is used, as
          the MD5 digest is a much stronger integrity check.
          
          
          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
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 2]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          Message Digest" structure, with the following format:
          
          
               INTEGRITY Object: Class = 4, C-Type = 1
          
          
               +-------------+-------------+-------------+-------------+
               |                    Key Identifier                     |
               +-------------+-------------+-------------+-------------+
               |                    Sequence Number                    |
               +-------------+-------------+-------------+-------------+
               |                                                       |
               +                                                       +
               |                                                       |
               +              Cryptographic Digest                     |
               |                                                       |
               +                                                       +
               |                                                       |
               +-------------+-------------+-------------+-------------+
          
          
          (1)  Key Indentifier
          
                  An unsigned 32-bit number defined in IPSEC documents.
          
          (2)  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.
          
          (3)  Cryptographic 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.
          
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 3]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          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 RFC 1321 when MD5 is used) |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                        64 bit message length MSW              |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                        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 does not cause authentication to fail.
          
          (4)  The appropriate Authentication Key is selected and placed
               in the Cryptographic Digest field of the INTEGRITY
               object.
          
          (5)  The Key Identifier is placed in the INTEGRITY object.
               This value (together with the interface) identifies both
               the key and the digest algorithm in use.
          
          (6)  The Keyed MD5 message trailer is appended to the end of
               the message in memory.
          
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 4]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          (7)  A cryptographic 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 RFC 1321.
          
          (8)  The digest is written into the Cryptographic Digest field
               of the INTEGRITY object, overlaying the Authentication
               Key.
          
          Authentication Key selection is normally based on the
          interface through which the message is sent or received.  Note
          that when a PATH or PATH_TEAR message is multicast, the
          INTEGRITY object in each copy will use the key appropriate for
          the interface out which it is sent.  However, a problem arises
          when a PATH or PATH_TEAR message takes a non-RSVP hop; in
          order to verify a received INTEGRITY object in this case, the
          next RSVP hop will generally need to select a key based upon
          the previous RSVP hop, not upon the incoming interface.  A
          similar issue arises for RESV and RESV_TEAR objects.  Key
          management in the presence of non-RSVP clouds appears painful.
          
          
          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, together with the arriving
               interface, is used to determine the Authentication Key
               and the hash algorithm to be used.
          
          (4)  The Cryptographic Digest field of the INTEGRITY object is
               overlaid with the Authentication Key.
          
          (5)  The Keyed MD5 message trailer is reconstructed at the end
               of the message.
          
          (6)  A new digest calculated using the indicated algorithm.
          
          (7)  If the calculated digest does not match the received
               digest, the message is discarded unprocessed.  If the
               received sequence number is less than the last sequence
               number received, the message is also discarded.
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 5]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          Ideally, the sending sequence number is stored in non-volatile
          memory, so that it survives resets.  However, if a device has
          not validly spoken for some time and starts with a low
          sequence number, it would be advisable to accept its view of
          the world.
          
          
          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.
          
          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
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 6]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          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.
          
          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
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 7]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          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.
          
          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.
          
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 8]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
               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 RFC-1321 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.
          
          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.
          
          
          
          
          
          
          
          
          
          
          
          Fred Baker           Expiration: May 1996             [Page 9]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          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-08.ps, November 1995.
          
          [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-XXXX (already submitted to RFC Editor),
               September 1994.
          
          [5]  N.  Haller, R.  Atkinson, "On Internet Authentication",
               Request for Comments 1704, DDN Network Information
               Center,
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Fred Baker           Expiration: May 1996            [Page 10]


          Internet Draft    RSVP Crypto Authentication     November 1995
          
          
          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
          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: May 1996            [Page 11]
          

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