rfc2747.txt

RFC 的详细文档！

   The "Integrity Response" message is accepted by the receiver
   (challenger) only if the returned CHALLENGE object matches the one
   sent in the "Integrity Challenge" message.  This prevents replay of
   old "Integrity Response" messages.  If the match is successful, the
   receiver saves the Sequence Number from the INTEGRITY object as the
   latest sequence number received with the key identifier included in
   the CHALLENGE.

   If a response is not received within a given period of time, the
   challenge is repeated.  When the integrity handshake successfully
   completes, the receiver begins accepting normal RSVP signaling
   messages from that sender and ignores any other "Integrity Response"
   messages.

   The Handshake Flag (HF) is used to allow implementations the
   flexibility of not including the integrity handshake mechanism.  By
   setting this flag to 1, message senders that implement the integrity
   handshake distinguish themselves from those that do not.  Receivers
   SHOULD NOT attempt to handshake with senders whose INTEGRITY object
   has HF = 0.






Baker, et al.               Standards Track                    [Page 11]

RFC 2747           RSVP Cryptographic Authentication       January 2000


   An integrity handshake may not be necessary in all environments.  A
   common use of RSVP integrity will be between peering domain routers,
   which are likely to be processing a steady stream of RSVP messages
   due to aggregation effects.  When a router restarts after a crash,
   valid RSVP messages from peering senders will probably arrive within
   a short time.  Assuming that replay messages are injected into the
   stream of valid RSVP messages, there may be only a small window of
   opportunity for a replay attack before a valid message is processed.
   This valid message will set the largest sequence number seen to a
   value greater than any number that had been stored prior to the
   crash, preventing any further replays.

   On the other hand, not using an integrity handshake could allow
   exposure to replay attacks if there is a long period of silence from
   a given sender following a restart of a receiver.  Hence, it SHOULD
   be an administrative decision whether or not the receiver performs an
   integrity handshake with senders that are willing to respond to
   "Integrity Challenge" messages, and whether it accepts any messages
   from senders that refuse to do so.  These decisions will be based on
   assumptions related to a particular network environment.

5.  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
   Identifier 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.

5.1.  Key Management Procedures

   Each key has a lifetime associated with it that is recorded in all
   systems (sender and receivers) configured with that key.  The concept
   of a "key lifetime" merely requires that the earliest (KeyStartValid)
   and latest (KeyEndValid) times that the key is valid be programmable
   in a way the system understands.  Certain key generation mechanisms,
   such as Kerberos or some public key schemes, may directly produce
   ephemeral keys.  In this case, the lifetime of the key is implicitly
   defined as part of the key.





Baker, et al.               Standards Track                    [Page 12]

RFC 2747           RSVP Cryptographic Authentication       January 2000


   In general, no key is ever used outside its lifetime (but see Section
   5.3).  Possible mechanisms for managing key lifetime include the
   Network Time Protocol and hardware time-of-day clocks.

   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 an RSVP implementation to
   support the storage and use of more than one active RSVP
   Authentication Key at the same time.  Hence both the sender and
   receivers might have multiple active keys for a given security
   association.

   Since keys are shared between a sender and (possibly) multiple
   receivers, there is a region of uncertainty around the time of key
   switch-over during which some systems may still be using the old key
   and others might have switched to the new key.  The size of this
   uncertainty region is related to clock synchrony of the systems.
   Administrators should configure the overlap between the expiration
   time of the old key (KeyEndValid) and the validity of the new key
   (KeyStartValid) to be at least twice the size of this uncertainty
   interval.  This will allow the sender to make the key switch-over at
   the midpoint of this interval and be confident that all receivers are
   now accepting the new key.  For the duration of the overlap in key
   lifetimes, a receiver must be prepared to authenticate messages using
   either key.

   During a key switch-over, it will be necessary for each receiver to
   handshake with the sender using the new key.  As stated before, a
   receiver has the choice of initiating a handshake during the
   switchover or postponing the handshake until the receipt of a message
   using that key.

5.2.  Key Management Requirements

   Requirements on an implementation are as follows:

     o    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.

     o    An implementation MUST support the storage and use of more
          than one key at the same time, for both sending and receiving
          systems.




Baker, et al.               Standards Track                    [Page 13]

RFC 2747           RSVP Cryptographic Authentication       January 2000


     o    An implementation MUST associate a specific lifetime (i.e.,
          KeyStartValid and KeyEndValid) with each key and the
          corresponding Key Identifier.

     o    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.

     o    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.

     o    Keys that are out of date MAY be automatically deleted by the
          implementation.

     o    Manual deletion of active keys MUST also be supported.

     o    Key storage SHOULD persist across a system restart, warm or
          cold, to ease operational usage.

5.3.  Pathological Case

   It is possible that the last key for a given security association has
   expired.  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.

6.  Conformance Requirements

   To conform to this specification, an implementation MUST support all
   of its aspects.  The HMAC-MD5 authentication algorithm defined in [7]
   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 Management Procedures."

   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.





Baker, et al.               Standards Track                    [Page 14]

RFC 2747           RSVP Cryptographic Authentication       January 2000


7.  Kerberos generation of RSVP Authentication Keys

   Kerberos[10] MAY be used to generate the RSVP Authentication key used
   in generating a signature in the Integrity Object sent from a RSVP
   sender to a receiver.   Kerberos key generation avoids the use of
   shared keys between RSVP senders and receivers such as hosts and
   routers.  Kerberos allows for the use of trusted third party keying
   relationships between security principals (RSVP sender and receivers)
   where the Kerberos key distribution center(KDC) establishes an
   ephemeral session key that is subsequently shared between RSVP sender
   and receivers.  In the multicast case all receivers of a multicast
   RSVP message MUST share a single key with the KDC (e.g. the receivers
   are in effect the same security principal with respect to Kerberos).

   The Key information determined by the sender MAY specify the use of
   Kerberos in place of configured shared keys as the mechanism for
   establishing a key between the sender and receiver.  The Kerberos
   identity of the receiver is established as part of the sender's
   interface configuration or it can be established through other
   mechanisms.  When generating the first RSVP message for a specific
   key identifier the sender requests a Kerberos service ticket and gets
   back an ephemeral session key and a Kerberos ticket from the KDC.
   The sender encapsulates the ticket and the identity of the sender in
   an Identity Policy Object[2]. The sender includes the Policy Object
   in the RSVP message.  The session key is then used by the sender as
   the RSVP Authentication key in section 4.1 step (3) and is stored as
   Key information associated with the key identifier.

   Upon RSVP Message reception, the receiver retrieves the Kerberos
   Ticket from the Identity Policy Object, decrypts the ticket and
   retrieves the session key from the ticket.  The session key is the
   same key as used by the sender and is used as the key in section 4.2
   step (3).  The receiver stores the key for use in processing
   subsequent RSVP messages.

   Kerberos tickets have lifetimes and the sender MUST NOT use tickets
   that have expired.  A new ticket MUST be requested and used by the
   sender for the receiver prior to the ticket expiring.

7.1.  Optimization when using Kerberos Based Authentication

   Kerberos tickets are relatively long (> 500 bytes) and it is not
   necessary to send a ticket in every RSVP message.  The ephemeral
   session key can be cached by the sender and receiver and can be used
   for the lifetime of the Kerberos ticket.  In this case, the sender
   only needs to include the Kerberos ticket in the first Message
   generated.  Subsequent RSVP messages use the key identifier to




Baker, et al.               Standards Track                    [Page 15]

RFC 2747           RSVP Cryptographic Authentication       January 2000


   retrieve the cached key (and optionally other identity information)
   instead of passing tickets from sender to receiver in each RSVP
   message.

   A receiver may not have cached key state with an associated Key
   Identifier due to reboot or route changes.  If the receiver's policy
   indicates the use of Kerberos keys for integrity checking, the
   receiver can send an integrity Challenge message back to the sender.
   Upon receiving an integrity Challenge message a sender MUST send an
   Identity object that includes the Kerberos ticket in the integrity
   Response message, thereby allowing the receiver to retrieve and store
   the session key from the Kerberos ticket for subsequent Integrity
   checking.

8.  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.
   Significant comments were submitted by Steve Bellovin, who actually
   understands this stuff.  Matt Crawford and Dan Harkins helped revise
   the document.

9.  References

   [1]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification", RFC 2205, September 1997.

   [2]  Yadav, S., et al., "Identity Representation for RSVP", RFC 2752,
        January 2000.

   [3]  Atkinson, R. and S. Kent, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [4]  Maughan, D., Schertler, M., Schneider, M. and J. Turner,
        "Internet Security Association and Key Management Protocol
        (ISAKMP)", RFC 2408, November 1998.