rfc2747.txt

RFC 的详细文档！

   [5]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
        November 1998.

   [6]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", RFC 2406, November 1998.

   [7]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
        for Message Authentication", RFC 2104, March 1996.




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


   [8]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [9]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [10] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
        Service (V5)", RFC 1510, September 1993.

10.  Security Considerations

   This entire memo describes and specifies an authentication mechanism
   for RSVP that is believed to be secure against active and passive
   attacks.

   The quality of the security provided by this mechanism depends 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.

   While the handshake "Integrity Response" message is integrity-
   checked, the handshake "Integrity Challenge" message is not.  This
   was done intentionally to avoid the case when both peering routers do
   not have a starting sequence number for each other's key.
   Consequently, they will each keep sending handshake "Integrity
   Challenge" messages that will be dropped by the other end.  Moreover,
   requiring only the response to be integrity-checked eliminates a
   dependency on an security association in the opposite direction.

   This, however, lets an intruder generate fake handshaking challenges
   with a certain challenge cookie.  It could then save the response and
   attempt to play it against a receiver that is in recovery.  If it was
   lucky enough to have guessed the challenge cookie used by the
   receiver at recovery time it could use the saved response.  This
   response would be accepted, since it is properly signed, and would
   have a smaller sequence number for the sender because it was an old
   message.  This opens the receiver up to replays. Still, it seems very
   difficult to exploit.  It requires not only guessing the challenge
   cookie (which is based on a locally known secret) in advance, but
   also being able to masquerade as the receiver to generate a handshake
   "Integrity Challenge" with the proper IP address and not being
   caught.





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


   Confidentiality is not provided by this mechanism.  If
   confidentiality is required, IPSEC ESP [6] 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.

11.  Authors' Addresses

   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, CA 93111

   Phone: [phone]
   EMail: [e-mail]


   Bob Lindell
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: [phone]
   EMail: [e-mail]


   Mohit Talwar
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052

   Phone: [phone]
   EMail: [e-mail]
















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


12.  Appendix 1: Key Management Interface

   This appendix describes a generic interface to Key Management.  This
   description is at an abstract level realizing that implementations
   may need to introduce small variations to the actual interface.

   At the start of execution, RSVP would use this interface to obtain
   the current set of relevant keys for sending and receiving messages.
   During execution, RSVP can query for specific keys given a Key
   Identifier and Source Address, discover newly created keys, and be
   informed of those keys that have been deleted.  The interface
   provides both a polling and asynchronous upcall style for wider
   applicability.

12.1.  Data Structures

   Information about keys is returned using the following KeyInfo data
   structure:

     KeyInfo {
             Key Type (Send or Receive)
             KeyIdentifier
             Key
             Authentication Algorithm Type and Mode
             KeyStartValid
             KeyEndValid
             Status (Active or Deleted)
             Outgoing Interface (for Send only)
             Other Outgoing Security Association Selection Criteria
                     (for Send only, optional)
             Sending System Address (for Receive Only)
     }

12.2.  Default Key Table

   This function returns a list of KeyInfo data structures corresponding
   to all of the keys that are configured for sending and receiving RSVP
   messages and have an Active Status.  This function is usually called
   at the start of execution but there is no limit on the number of
   times that it may be called.

     KM_DefaultKeyTable() -> KeyInfoList









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


12.3.  Querying for Unknown Receive Keys

   When a message arrives with an unknown Key Identifier and Sending
   System Address pair, RSVP can use this function to query the Key
   Management System for the appropriate key.  The status of the element
   returned, if any, must be Active.

     KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo

12.4.  Polling for Updates

   This function returns a list of KeyInfo data structures corresponding
   to any incremental changes that have been made to the default key
   table or requested keys since the last call to either
   KM_KeyTablePoll, KM_DefaultKeyTable, or KM_GetRecvKey.  The status of
   some elements in the returned list may be set to Deleted.

      KM_KeyTablePoll() -> KeyInfoList

12.5.  Asynchronous Upcall Interface

   Rather than repeatedly calling the KM_KeyTablePoll(), an
   implementation may choose to use an asynchronous event model.  This
   function registers interest to key changes for a given Key Identifier
   or for all keys if no Key Identifier is specified.  The upcall
   function is called each time a change is made to a key.

     KM_KeyUpdate ( Function [, KeyIdentifier ] )

   where the upcall function is parameterized as follows:

     Function ( KeyInfo )



















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


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Baker, et al.               Standards Track                    [Page 21]