doc: Add RFC documents

1 files changed, 2691 insertions, 0 deletions

diff --git a/doc/rfc/rfc4230.txt b/doc/rfc/rfc4230.txt
new file mode 100644
index 0000000..6337efc
--- /dev/null
+++ b/doc/rfc/rfc4230.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Network Working Group                                      H. Tschofenig
+Request for Comments: 4230                                       Siemens
+Category: Informational                                      R. Graveman
+                                                            RFG Security
+                                                           December 2005
+
+
+                        RSVP Security Properties
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document summarizes the security properties of RSVP.  The goal
+   of this analysis is to benefit from previous work done on RSVP and to
+   capture knowledge about past activities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                      [Page 1]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Terminology and Architectural Assumptions  . . . . . . . . .   3
+   3.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+        3.1.  The RSVP INTEGRITY Object  . . . . . . . . . . . . . .   5
+        3.2.  Security Associations  . . . . . . . . . . . . . . . .   8
+        3.3.  RSVP Key Management Assumptions  . . . . . . . . . . .   8
+        3.4.  Identity Representation  . . . . . . . . . . . . . . .   9
+        3.5.  RSVP Integrity Handshake   . . . . . . . . . . . . . .  13
+   4.   Detailed Security Property Discussion  . . . . . . . . . . .  15
+        4.1.  Network Topology   . . . . . . . . . . . . . . . . . .  15
+        4.2.  Host/Router  . . . . . . . . . . . . . . . . . . . . .  15
+        4.3.  User to PEP/PDP  . . . . . . . . . . . . . . . . . . .  19
+        4.4.  Communication between RSVP-Aware Routers . . . . . . .  28
+   5.   Miscellaneous Issues . . . . . . . . . . . . . . . . . . . .  29
+        5.1.  First-Hop Issue  . . . . . . . . . . . . . . . . . . .  30
+        5.2.  Next-Hop Problem . . . . . . . . . . . . . . . . . . .  30
+        5.3.  Last-Hop Issue   . . . . . . . . . . . . . . . . . . .  33
+        5.4.  RSVP- and IPsec-protected data traffic . . . . . . . .  34
+        5.5.  End-to-End Security Issues and RSVP  . . . . . . . . .  36
+        5.6.  IPsec protection of RSVP signaling messages  . . . . .  36
+        5.7.  Authorization  . . . . . . . . . . . . . . . . . . . .  37
+   6.   Conclusions  . . . . . . . . . . . . . . . . . . . . . . . .  38
+   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  40
+   8.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  40
+   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  40
+        9.1.  Normative References . . . . . . . . . . . . . . . . .  40
+        9.2.  Informative References . . . . . . . . . . . . . . . .  41
+   A.   Dictionary Attacks and Kerberos  . . . . . . . . . . . . . .  45
+   B.   Example of User-to-PDP Authentication  . . . . . . . . . . .  45
+   C.   Literature on RSVP Security  . . . . . . . . . . . . . . . .  46
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                      [Page 2]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+1.  Introduction
+
+   As the work of the NSIS working group began, concerns about security
+   and its implications for the design of a signaling protocol were
+   raised.  In order to understand the security properties and available
+   options of RSVP, a number of documents have to be read.  This
+   document summarizes the security properties of RSVP and is part of
+   the overall process of analyzing other signaling protocols and
+   learning from their design considerations.  This document should also
+   provide a starting point for further discussions.
+
+   The content of this document is organized as follows.  Section 2
+   introduces the terminology used throughout the document.  Section 3
+   provides an overview of the security mechanisms provided by RSVP
+   including the INTEGRITY object, a description of the identity
+   representation within the POLICY_DATA object (i.e., user
+   authentication), and the RSVP Integrity Handshake mechanism.  Section
+   4 provides a more detailed discussion of the mechanisms used and
+   tries to describe in detail the mechanisms provided.  Several
+   miscellaneous issues are covered in Section 5.
+
+   RSVP also supports multicast, but this document does not address
+   security aspects for supporting multicast QoS signaling.  Multicast
+   is currently outside the scope of the NSIS working group.
+
+   Although a variation of RSVP, namely RSVP-TE, is used in the context
+   of MPLS to distribute labels for a label switched path, its usage is
+   different from the usage scenarios envisioned for NSIS.  Hence, this
+   document does not address RSVP-TE or its security properties.
+
+2.  Terminology and Architectural Assumptions
+
+   This section describes some important terms and explains some
+   architectural assumptions.
+
+   o  Chain-of-Trust:
+
+      The security mechanisms supported by RSVP [1] heavily rely on
+      optional hop-by-hop protection, using the built-in INTEGRITY
+      object.  Hop-by-hop security with the INTEGRITY object inside the
+      RSVP message thereby refers to the protection between RSVP-
+      supporting network elements.  Additionally, there is the notion of
+      policy-aware nodes that understand the POLICY_DATA element within
+      the RSVP message.  Because this element also includes an INTEGRITY
+      object, there is an additional hop-by-hop security mechanism that
+      provides security between policy-aware nodes.  Policy-ignorant
+      nodes are not affected by the inclusion of this object in the
+      POLICY_DATA element, because they do not try to interpret it.
+
+
+
+Tschofenig & Graveman        Informational                      [Page 3]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+      To protect signaling messages that are possibly modified by each
+      RSVP router along the path, it must be assumed that each incoming
+      request is authenticated, integrity protected, and replay
+      protected.  This provides protection against bogus messages
+      injected by unauthorized nodes.  Furthermore, each RSVP-aware
+      router is assumed to behave in the expected manner.  Outgoing
+      messages transmitted to the next-hop network element receive new
+      protection according to RSVP security processing.
+
+      Using the mechanisms described above, a chain-of-trust is created
+      whereby a signaling message that is transmitted by router A via
+      router B and received by router C is supposed to be secure if
+      routers A and B and routers B and C share security associations
+      and all routers behave as expected.  Hence, router C trusts router
+      A although router C does not have a direct security association
+      with router A.  We can therefore conclude that the protection
+      achieved with this hop-by-hop security for the chain-of-trust is
+      no better than the weakest link in the chain.
+
+      If one router is malicious (for example, because an adversary has
+      control over this router), then it can arbitrarily modify
+      messages, cause unexpected behavior, and mount a number of attacks
+      that are not limited to QoS signaling.  Additionally, it must be
+      mentioned that some protocols demand more protection than others
+      (which depends, in part, on which nodes are executing these
+      protocols).  For example, edge devices, where end-users are
+      attached, may be more likely to be attacked in comparison with the
+      more secure core network of a service provider.  In some cases, a
+      network service provider may choose not to use the RSVP-provided
+      security mechanisms inside the core network because a different
+      security protection is deployed.
+
+      Section 6 of [2] mentions the term chain-of-trust in the context
+      of RSVP integrity protection.  In Section 6 of [14] the same term
+      is used in the context of user authentication with the INTEGRITY
+      object inside the POLICY_DATA element.  Unfortunately, the term is
+      not explained in detail and the assumptions behind it are not
+      clearly specified.
+
+   o  Host and User Authentication:
+
+      The presence of RSVP protection and a separate user identity
+      representation leads to the fact that both user-identity and host-
+      identity are used for RSVP protection.  Therefore, user-based
+      security and host-based security are covered separately, because
+      of the different authentication mechanisms provided.  To avoid
+      confusion about the different concepts, Section 3.4 describes the
+      concept of user authentication in more detail.
+
+
+
+Tschofenig & Graveman        Informational                      [Page 4]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   o  Key Management:
+
+      It is assumed that most of the security associations required for
+      the protection of RSVP signaling messages are already available,
+      and hence key management was done in advance.  There is, however,
+      an exception with respect to support for Kerberos.  Using
+      Kerberos, an entity is able to distribute a session key used for
+      RSVP signaling protection.
+
+   o  RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
+
+      RSVP uses an INTEGRITY object in two places in a message.  The
+      first is in the RSVP message itself and covers the entire RSVP
+      message as defined in [1].  The second is included in the
+      POLICY_DATA object and defined in [2].  To differentiate the two
+      objects by their scope of protection, the two terms RSVP INTEGRITY
+      and POLICY_DATA INTEGRITY object are used, respectively.  The data
+      structure of the two objects, however, is the same.
+
+   o  Hop versus Peer:
+
+      In the past, the terminology for nodes addressed by RSVP has been
+      discussed considerably.  In particular, two favorite terms have
+      been used: hop and peer.  This document uses the term hop, which
+      is different from an IP hop.  Two neighboring RSVP nodes
+      communicating with each other are not necessarily neighboring IP
+      nodes (i.e., they may be more than one IP hop away).
+
+3.  Overview
+
+   This section describes the security mechanisms provided by RSVP.
+   Although use of IPsec is mentioned in Section 10 of [1], the other
+   security mechanisms primarily envisioned for RSVP are described.
+
+3.1.  The RSVP INTEGRITY Object
+
+   The RSVP INTEGRITY object is the major component of RSVP security
+   protection.  This object is used to provide integrity and replay
+   protection for the content of the signaling message between two RSVP
+   participating routers or between an RSVP router and host.
+   Furthermore, the RSVP INTEGRITY object provides data origin
+   authentication.  The attributes of the object are briefly described:
+
+   o  Flags field:
+
+       The Handshake Flag is the only defined flag.  It is used to
+       synchronize sequence numbers if the communication gets out of
+       sync (e.g., it allows a restarting host to recover the most
+
+
+
+Tschofenig & Graveman        Informational                      [Page 5]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       recent sequence number).  Setting this flag to one indicates that
+       the sender is willing to respond to an Integrity Challenge
+       message.  This flag can therefore be seen as a negotiation
+       capability transmitted within each INTEGRITY object.
+
+   o  Key Identifier:
+
+       The Key Identifier selects the key used for verification of the
+       Keyed Message Digest field and, hence, must be unique for the
+       sender.  It has a fixed 48-bit length.  The generation of this
+       Key Identifier field is mostly a decision of the local host. [1]
+       describes this field as a combination of an address, sending
+       interface, and key number.  We assume that the Key Identifier is
+       simply a (keyed) hash value computed over a number of fields,
+       with the requirement to be unique if more than one security
+       association is used in parallel between two hosts (e.g., as is
+       the case with security associations having overlapping
+       lifetimes).  A receiving system uniquely identifies a security
+       association based on the Key Identifier and the sender's IP
+       address.  The sender's IP address may be obtained from the
+       RSVP_HOP object or from the source IP address of the packet if
+       the RSVP_HOP object is not present.  The sender uses the outgoing
+       interface to determine which security association to use.  The
+       term "outgoing interface" may be confusing.  The sender selects
+       the security association based on the receiver's IP address
+       (i.e., the address of the next RSVP-capable router).  The process
+       of determining which node is the next RSVP-capable router is not
+       further specified and is likely to be statically configured.
+
+   o  Sequence Number:
+
+       The sequence number used by the INTEGRITY object is 64 bits in
+       length, and the starting value can be selected arbitrarily.  The
+       length of the sequence number field was chosen to avoid
+       exhaustion during the lifetime of a security association as
+       stated in Section 3 of [1].  In order for the receiver to
+       distinguish between a new and a replayed message, the sequence
+       number must be monotonically incremented (modulo 2^64) for each
+       message.  We assume that the first sequence number seen (i.e.,
+       the starting sequence number) is stored somewhere.  The modulo-
+       operation is required because the starting sequence number may be
+       an arbitrary number.  The receiver therefore only accepts packets
+       with a sequence number larger (modulo 2^64) than the previous
+       packet.  As explained in [1] this process is started by
+       handshaking and agreeing on an initial sequence number.  If no
+       such handshaking is available then the initial sequence number
+       must be part of the establishment of the security association.
+
+
+
+
+Tschofenig & Graveman        Informational                      [Page 6]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       The generation and storage of sequence numbers is an important
+       step in preventing replay attacks and is largely determined by
+       the capabilities of the system in the presence of system crashes,
+       failures, and restarts.  Section 3 of [1] explains some of the
+       most important considerations.  However, the description of how
+       the receiver distinguishes proper from improper sequence numbers
+       is incomplete: it implicitly assumes that gaps large enough to
+       cause the sequence number to wrap around cannot occur.
+
+       If delivery in order were guaranteed, the following procedure
+       would work: the receiver keeps track of the first sequence number
+       received, INIT-SEQ, and the most recent sequence number received,
+       LAST-SEQ, for each key identifier in a security association.
+       When the first message is received, set INIT-SEQ = LAST-SEQ =
+       value received and accept.  When a subsequent message is
+       received, if its sequence number is strictly between LAST-SEQ and
+       INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the
+       value just received.  If it is between INIT-SEQ and LAST-SEQ,
+       inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ
+       unchanged.  Because delivery in order is not guaranteed, the
+       above rules need to be combined with a method of allowing a fixed
+       sized window in the neighborhood of LAST-SEQ for out-of-order
+       delivery, for example, as described in Appendix C of [3].
+
+   o  Keyed Message Digest:
+
+       The Keyed Message Digest is a security mechanism built into RSVP
+       that used to provide integrity protection of a signaling message
+       (including its sequence number).  Prior to computing the value
+       for the Keyed Message Digest field, the Keyed Message Digest
+       field itself must be set to zero and a keyed hash computed over
+       the entire RSVP packet.  The Keyed Message Digest field is
+       variable in length but must be a multiple of four octets.  If
+       HMAC-MD5 is used, then the output value is 16 bytes long.  The
+       keyed hash function HMAC-MD5 [4] is required for an RSVP
+       implementation, as noted in Section 1 of [1].  Hash algorithms
+       other than MD5 [5], like SHA-1 [15], may also be supported.
+
+       The key used for computing this Keyed Message Digest may be
+       obtained from the pre-shared secret, which is either manually
+       distributed or the result of a key management protocol.  No key
+       management protocol, however, is specified to create the desired
+       security associations.  Also, no guidelines for key length are
+       given.  It should be recommended that HMAC-MD5 keys be 128 bits
+       and SHA-1 keys 160 bits, as in IPsec AH [16] and ESP [17].
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                      [Page 7]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+3.2.  Security Associations
+
+   Different attributes are stored for security associations of sending
+   and receiving systems (i.e., unidirectional security associations).
+   The sending system needs to maintain the following attributes in such
+   a security association [1]:
+
+      o  Authentication algorithm and algorithm mode
+
+      o  Key
+
+      o  Key Lifetime
+
+      o  Sending Interface
+
+      o  Latest sequence number (received with this key identifier)
+
+   The receiving system has to store the following fields:
+
+      o  Authentication algorithm and algorithm mode
+
+      o  Key
+
+      o  Key Lifetime
+
+      o  Source address of the sending system
+
+      o  List of last n sequence numbers (received with this key
+         identifier)
+
+   Note that the security associations need to have additional fields to
+   indicate their state.  It is necessary to have overlapping lifetimes
+   of security associations to avoid interrupting an ongoing
+   communication because of expired security associations.  During such
+   a period of overlapping lifetime it is necessary to authenticate with
+   either one or both active keys.  As mentioned in [1], a sender and a
+   receiver may have multiple active keys simultaneously.  If more than
+   one algorithm is supported, then the algorithm used must be specified
+   for a security association.
+
+3.3.  RSVP Key Management Assumptions
+
+   RFC 2205 [6] assumes that security associations are already
+   available.  An implementation must support manual key distribution as
+   noted in Section 5.2 of [1].  Manual key distribution, however, has
+   different requirements for key storage; a simple plaintext ASCII file
+   may be sufficient in some cases.  If multiple security associations
+   with different lifetimes need to be supported at the same time, then
+
+
+
+Tschofenig & Graveman        Informational                      [Page 8]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   a key engine would be more appropriate.  Further security
+   requirements listed in Section 5.2 of [1] are the following:
+
+   o  The manual deletion of security associations must be supported.
+
+   o  The key storage should persist during a system restart.
+
+   o  Each key must be assigned a specific lifetime and a specific Key
+      Identifier.
+
+3.4.  Identity Representation
+
+   In addition to host-based authentication with the INTEGRITY object
+   inside the RSVP message, user-based authentication is available as
+   introduced in [2].  Section 2 of [7] states that "Providing policy
+   based admission control mechanism based on user identities or
+   application is one of the prime requirements."  To identify the user
+   or the application, a policy element called AUTH_DATA, which is
+   contained in the POLICY_DATA object, is created by the RSVP daemon at
+   the user's host and transmitted inside the RSVP message.  The
+   structure of the POLICY_DATA element is described in [2].  Network
+   nodes acting as policy decision points (PDPs) then use the
+   information contained in the AUTH_DATA element to authenticate the
+   user and to allow policy-based admission control to be executed.  As
+   mentioned in [7], the policy element is processed and the PDP
+   replaces the old element with a new one for forwarding to the next
+   hop router.
+
+   A detailed description of the POLICY_DATA element can be found in
+   [2].  The attributes contained in the authentication data policy
+   element AUTH_DATA, which is defined in [7], are briefly explained in
+   this Section.  Figure 1 shows the abstract structure of the RSVP
+   message with its security-relevant objects and the scope of
+   protection.  The RSVP INTEGRITY object (outer object) covers the
+   entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
+   covers objects within the POLICY_DATA element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                      [Page 9]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   +--------------------------------------------------------+
+   | RSVP Message                                           |
+   +--------------------------------------------------------+
+   | Object    |POLICY_DATA Object                         ||
+   |           +-------------------------------------------+|
+   |           | INTEGRITY +------------------------------+||
+   |           | Object    | AUTH_DATA Object             |||
+   |           |           +------------------------------+||
+   |           |           | Various Authentication       |||
+   |           |           | Attributes                   |||
+   |           |           +------------------------------+||
+   |           +-------------------------------------------+|
+   +--------------------------------------------------------+
+
+               Figure 1: Security Relevant Objects and Elements
+                         within the RSVP Message.
+
+   The AUTH_DATA object contains information for identifying users and
+   applications together with credentials for those identities.  The
+   main purpose of these identities seems to be usage for policy-based
+   admission control and not authentication and key management.  As
+   noted in Section 6.1 of [7], an RSVP message may contain more than
+   one POLICY_DATA object and each of them may contain more than one
+   AUTH_DATA object.  As indicated in Figure 1 and in [7], one AUTH_DATA
+   object may contain more than one authentication attribute.  A typical
+   configuration for Kerberos-based user authentication includes at
+   least the Policy Locator and an attribute containing the Kerberos
+   session ticket.
+
+   Successful user authentication is the basis for executing policy-
+   based admission control.  Additionally, other information such as
+   time-of-day, application type, location information, group
+   membership, etc. may be relevant to the implementation of an access
+   control policy.
+
+   The following attributes are defined for use in the AUTH_DATA object:
+
+      o  Policy Locator
+
+         *  ASCII_DN
+
+         *  UNICODE_DN
+
+         *  ASCII_DN_ENCRYPT
+
+         *  UNICODE_DN_ENCRYPT
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 10]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+         The policy locator string is an X.500 distinguished name (DN)
+         used to locate user or application-specific policy information.
+         The four types of X.500 DNs are listed above.  The first two
+         types are the ASCII and the Unicode representation of the user
+         or application DN identity.  The two "encrypted" distinguished
+         name types are either encrypted with the Kerberos session key
+         or with the private key of the user's digital certificate
+         (i.e., digitally signed).  The term "encrypted together with a
+         digital signature" is easy to misconceive.  If user identity
+         confidentiality is provided, then the policy locator has to be
+         encrypted with the public key of the recipient.  How to obtain
+         this public key is not described in the document.  This detail
+         may be specified in a concrete architecture in which RSVP is
+         used.
+
+      o  Credentials
+
+         Two cryptographic credentials are currently defined for a user:
+         authentication with Kerberos V5 [8], and authentication with
+         the help of digital signatures based on X.509 [18] and PGP
+         [19].  The following list contains all defined credential types
+         currently available and defined in [7]:
+
+         +--------------+--------------------------------+
+         | Credential   |  Description                   |
+         |    Type      |                                |
+         +===============================================|
+         | ASCII_ID     |  User or application identity  |
+         |              |  encoded as an ASCII string    |
+         +--------------+--------------------------------+
+         | UNICODE_ID   |  User or application identity  |
+         |              |  encoded as a Unicode string   |
+         +--------------+--------------------------------+
+         | KERBEROS_TKT |  Kerberos V5 session ticket    |
+         +--------------+--------------------------------+
+         | X509_V3_CERT |  X.509 V3 certificate          |
+         +--------------+--------------------------------+
+         | PGP_CERT     |  PGP certificate               |
+         +--------------+--------------------------------+
+
+                    Figure 2: Credentials Supported in RSVP.
+
+         The first two credentials contain only a plaintext string, and
+         therefore they do not provide cryptographic user
+         authentication.  These plaintext strings may be used to
+         identify applications, that are included for policy-based
+         admission control.  Note that these plain-text identifiers may,
+         however, be protected if either the RSVP INTEGRITY or the
+
+
+
+Tschofenig & Graveman        Informational                     [Page 11]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+         INTEGRITY object of the POLICY_DATA element is present.  Note
+         that the two INTEGRITY objects can terminate at different
+         entities depending on the network structure.  The digital
+         signature may also provide protection of application
+         identifiers.  A protected application identity (and the entire
+         content of the POLICY_DATA element) cannot be modified as long
+         as no policy-ignorant nodes are encountered in between.
+
+         A Kerberos session ticket, as previously mentioned, is the
+         ticket of a Kerberos AP_REQ message [8] without the
+         Authenticator.  Normally, the AP_REQ message is used by a
+         client to authenticate to a server.  The INTEGRITY object
+         (e.g., of the POLICY_DATA element) provides the functionality
+         of the Kerberos Authenticator, namely protecting against replay
+         and showing that the user was able to retrieve the session key
+         following the Kerberos protocol.  This is, however, only the
+         case if the Kerberos session was used for the keyed message
+         digest field of the INTEGRITY object.  Section 7 of [1]
+         discusses some issues for establishment of keys for the
+         INTEGRITY object.  The establishment of the security
+         association for the RSVP INTEGRITY object with the inclusion of
+         the Kerberos Ticket within the AUTH_DATA element may be
+         complicated by the fact that the ticket can be decrypted by
+         node B, whereas the RSVP INTEGRITY object terminates at a
+         different host C.
+
+         The Kerberos session ticket contains, among many other fields,
+         the session key.  The Policy Locator may also be encrypted with
+         the same session key.  The protocol steps that need to be
+         executed to obtain such a Kerberos service ticket are not
+         described in [7] and may involve several roundtrips, depending
+         on many Kerberos-related factors.  As an optimization, the
+         Kerberos ticket does not need to be included in every RSVP
+         message, as described in Section 7.1 of [1].  Thus, the
+         receiver must store the received service ticket.  If the
+         lifetime of the ticket has expired, then a new service ticket
+         must be sent.  If the receiver lost its state information
+         (because of a crash or restart) then it may transmit an
+         Integrity Challenge message to force the sender to re-transmit
+         a new service ticket.
+
+         If either the X.509 V3 or the PGP certificate is included in
+         the policy element, then a digital signature must be added.
+         The digital signature computed over the entire AUTH_DATA object
+         provides authentication and integrity protection.  The SubType
+         of the digital signature authentication attribute is set to
+         zero before computing the digital signature.  Whether or not a
+         guarantee of freshness with replay protection (either
+
+
+
+Tschofenig & Graveman        Informational                     [Page 12]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+         timestamps or sequence numbers) is provided by the digital
+         signature is an open issue as discussed in Section 4.3.
+
+      o  Digital Signature
+
+         The digital signature computed over the contents of the
+         AUTH_DATA object must be the last attribute.  The algorithm
+         used to compute the digital signature depends on the
+         authentication mode listed in the credential.  This is only
+         partially true, because, for example, PGP again allows
+         different algorithms to be used for computing a digital
+         signature.  The algorithm identifier used for computing the
+         digital signature is not included in the certificate itself.
+         The algorithm identifier included in the certificate only
+         serves the purpose of allowing the verification of the
+         signature computed by the certificate authority (except for the
+         case of self-signed certificates).
+
+      o  Policy Error Object
+
+         The Policy Error Object is used in the case of a failure of
+         policy-based admission control or other credential
+         verification.  Currently available error messages allow
+         notification if the credentials are expired
+         (EXPIRED_CREDENTIALS), if the authorization process disallowed
+         the resource request (INSUFFICIENT_PRIVILEGES), or if the given
+         set of credentials is not supported
+         (UNSUPPORTED_CREDENTIAL_TYPE).  The last error message returned
+         by the network allows the user's host to discover the type of
+         credentials supported.  Particularly for mobile environments
+         this might be quite inefficient.  Furthermore, it is unlikely
+         that a user supports different types of credentials.  The
+         purpose of the error message IDENTITY_CHANGED is unclear.
+         Also, the protection of the error message is not discussed in
+         [7].
+
+3.5.  RSVP Integrity Handshake
+
+   The Integrity Handshake protocol was designed to allow a crashed or
+   restarted host to obtain the latest valid challenge value stored at
+   the receiving host.  Due to the absence of key management, it must be
+   guaranteed that two messages do not use the same sequence number with
+   the same key.  A host stores the latest sequence number of a
+   cryptographically verified message.  An adversary can replay
+   eavesdropped packets if the crashed host has lost its sequence
+   numbers.  A signaling message from the real sender with a new
+   sequence number would therefore allow the crashed host to update the
+   sequence number field and prevent further replays.  Hence, if there
+
+
+
+Tschofenig & Graveman        Informational                     [Page 13]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   is a steady flow of RSVP-protected messages between the two hosts, an
+   attacker may find it difficult to inject old messages, because new,
+   authenticated messages with higher sequence numbers arrive and get
+   stored immediately.
+
+   The following description explains the details of an RSVP Integrity
+   Handshake that is started by Node A after recovering from a
+   synchronization failure:
+
+                     Integrity Challenge
+
+                  (1) Message (including
+    +----------+      a Cookie)            +----------+
+    |          |-------------------------->|          |
+    |  Node A  |                           |  Node B  |
+    |          |<--------------------------|          |
+    +----------+      Integrity Response   +----------+
+                  (2) Message (including
+                      the Cookie and the
+                      INTEGRITY object)
+
+                    Figure 3: RSVP Integrity Handshake.
+
+   The details of the messages are as follows:
+
+      CHALLENGE:=(Key Identifier, Challenge Cookie)
+
+      Integrity Challenge Message:=(Common Header, CHALLENGE)
+
+      Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
+
+   The "Challenge Cookie" is suggested to be a MD5 hash of a local
+   secret and a timestamp [1].
+
+   The Integrity Challenge message is not protected with an INTEGRITY
+   object as shown in the protocol flow above.  As explained in Section
+   10 of [1] this was done to avoid problems in situations where both
+   communicating parties do not have a valid starting sequence number.
+
+   Using the RSVP Integrity Handshake protocol is recommended although
+   it is not mandatory (because it may not be needed in all network
+   environments).
+
+
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 14]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+4.  Detailed Security Property Discussion
+
+   This section describes the protection of the RSVP-provided mechanisms
+   for authentication, authorization, integrity and replay protection
+   individually, user identity confidentiality, and confidentiality of
+   the signaling messages,
+
+4.1.  Network Topology
+
+   This paragraph shows the basic interfaces in a simple RSVP network
+   architecture.  The architecture below assumes that there is only a
+   single domain and that the two routers are RSVP- and policy-aware.
+   These assumptions are relaxed in the individual paragraphs, as
+   necessary.  Layer 2 devices between the clients and their
+   corresponding first-hop routers are not shown.  Other network
+   elements like a Kerberos Key Distribution Center and, for example, an
+   LDAP server from which the PDP retrieves its policies are also
+   omitted.  The security of various interfaces to the individual
+   servers (KDC, PDP, etc.) depends very much on the security policy of
+   a specific network service provider.
+
+                            +--------+
+                            | Policy |
+                       +----|Decision|
+                       |    | Point  +---+
+                       |    +--------+   |
+                       |                 |
+                       |                 |
+     +------+       +-+----+        +---+--+          +------+
+     |Client|       |Router|        |Router|          |Client|
+     |  A   +-------+  1   +--------+  2   +----------+  B   |
+     +------+       +------+        +------+          +------+
+
+                     Figure 4: Simple RSVP Architecture.
+
+4.2.  Host/Router
+
+   When considering authentication in RSVP, it is important to make a
+   distinction between user and host authentication of the signaling
+   messages.  The host is authenticated using the RSVP INTEGRITY object,
+   whereas credentials inside the AUTH_DATA object can be used to
+   authenticate the user.  In this section, the focus is on host
+   authentication, whereas the next section covers user authentication.
+
+   (1) Authentication
+
+       The term "host authentication" is used above, because the
+       selection of the security association is bound to the host's IP
+
+
+
+Tschofenig & Graveman        Informational                     [Page 15]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       address, as mentioned in Section 3.1 and Section 3.2.  Depending
+       on the key management protocol used to create this security
+       association and the identity used, it is also possible to bind a
+       user identity to this security association.  Because the key
+       management protocol is not specified, it is difficult to evaluate
+       this part, and hence we speak about data-origin authentication
+       based on the host's identity for RSVP INTEGRITY objects.  The
+       fact that the host identity is used for selecting the security
+       association has already been described in Section 3.1.
+
+       Data-origin authentication is provided with a keyed hash value
+       computed over the entire RSVP message, excluding the keyed
+       message digest field itself.  The security association used
+       between the user's host and the first-hop router is, as
+       previously mentioned, not established by RSVP, and it must
+       therefore be available before signaling is started.
+
+       *  Kerberos for the RSVP INTEGRITY object
+
+          As described in Section 7 of [1], Kerberos may be used to
+          create the key for the RSVP INTEGRITY object.  How to learn
+          the principal name (and realm information) of the other node
+          is outside the scope of [1]. [20] describes a way to
+          distribute principal and realm information via DNS, which can
+          be used for this purpose (assuming that the FQDN or the IP
+          address of the other node for which this information is
+          desired is known).  All that is required is to encapsulate the
+          Kerberos ticket inside the policy element.  It is furthermore
+          mentioned that Kerberos tickets with expired lifetime must not
+          be used, and the initiator is responsible for requesting and
+          exchanging a new service ticket before expiration.
+
+          RSVP multicast processing in combination with Kerberos
+          involves additional considerations.  Section 7 of [1] states
+          that in the multicast case all receivers must share a single
+          key with the Kerberos Authentication Server (i.e., a single
+          principal used for all receivers).  From a personal discussion
+          with Rodney Hess, it seems that there is currently no other
+          solution available in the context of Kerberos.  Multicast
+          handling therefore leaves some open questions in this context.
+
+          In the case where one entity crashed, the established security
+          association is lost and therefore the other node must
+          retransmit the service ticket.  The crashed entity can use an
+          Integrity Challenge message to request a new Kerberos ticket
+          to be retransmitted by the other node.  If a node receives
+          such a request, then a reply message must be returned.
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 16]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   (2) Integrity protection
+
+       Integrity protection between the user's host and the first-hop
+       router is based on the RSVP INTEGRITY object.  HMAC-MD5 is
+       preferred, although other keyed hash functions may also be used
+       within the RSVP INTEGRITY object.  In any case, both
+       communicating entities must have a security association that
+       indicates the algorithm to use.  This may, however, be difficult,
+       because no negotiation protocol is defined to agree on a specific
+       algorithm.  Hence, if RSVP is used in a mobile environment, it is
+       likely that HMAC-MD5 is the only usable algorithm for the RSVP
+       INTEGRITY object.  Only in local environments may it be useful to
+       switch to a different keyed hash algorithm.  The other possible
+       alternative is that every implementation support the most
+       important keyed hash algorithms. e.g., MD5, SHA-1, RIPEMD-160,
+       etc.  HMAC-MD5 was chosen mainly because of its performance
+       characteristics.  The weaknesses of MD5 [21] are known and were
+       initially described in [22].  Other algorithms like SHA-1 [15]
+       and RIPEMD-160 [21] have stronger security properties.
+
+   (3) Replay Protection
+
+       The main mechanism used for replay protection in RSVP is based on
+       sequence numbers, whereby the sequence number is included in the
+       RSVP INTEGRITY object.  The properties of this sequence number
+       mechanism are described in Section 3.1 of [1].  The fact that the
+       receiver stores a list of sequence numbers is an indicator for a
+       window mechanism.  This somehow conflicts with the requirement
+       that the receiver only has to store the highest number given in
+       Section 3 of [1].  We assume that this is an oversight.  Section
+       4.2 of [1] gives a few comments about the out-of-order delivery
+       and the ability of an implementation to specify the replay
+       window.  Appendix C of [3] describes a window mechanism for
+       handling out-of-sequence delivery.
+
+   (4) Integrity Handshake
+
+       The mechanism of the Integrity Handshake is explained in Section
+       3.5.  The Cookie value is suggested to be a hash of a local
+       secret and a timestamp.  The Cookie value is not verified by the
+       receiver.  The mechanism used by the Integrity Handshake is a
+       simple Challenge/Response message, which assumes that the key
+       shared between the two hosts survives the crash.  If, however,
+       the security association is dynamically created, then this
+       assumption may not be true.
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 17]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       In Section 10 of [1], the authors note that an adversary can
+       create a faked Integrity Handshake message that includes
+       challenge cookies.  Subsequently, it could store the received
+       response and later try to replay these responses while a
+       responder recovers from a crash or restart.  If this replayed
+       Integrity Response value is valid and has a lower sequence number
+       than actually used, then this value is stored at the recovering
+       host.  In order for this attack to be successful, the adversary
+       must either have collected a large number of challenge/response
+       value pairs or have "discovered" the cookie generation mechanism
+       (for example by knowing the local secret).  The collection of
+       Challenge/Response pairs is even more difficult, because they
+       depend on the Cookie value, the sequence number included in the
+       response message, and the shared key used by the INTEGRITY
+       object.
+
+   (5) Confidentiality
+
+       Confidentiality is not considered to be a security requirement
+       for RSVP.  Hence, it is not supported by RSVP, except as
+       described in paragraph d) of Section 4.3.  This assumption may
+       not hold, however, for enterprises or carriers who want to
+       protect billing data, network usage patterns, or network
+       configurations, in addition to users' identities, from
+       eavesdropping and traffic analysis.  Confidentiality may also
+       help make certain other attacks more difficult.  For example, the
+       PathErr attack described in Section 5.2 is harder to carry out if
+       the attacker cannot observe the Path message to which the PathErr
+       corresponds.
+
+   (6) Authorization
+
+       The task of authorization consists of two subcategories: network
+       access authorization and RSVP request authorization.  Access
+       authorization is provided when a node is authenticated to the
+       network, e.g., using EAP [23] in combination with AAA protocols
+       (for example, RADIUS [24] or DIAMETER [9]).  Issues related to
+       network access authentication and authorization are outside the
+       scope of RSVP.
+
+       The second authorization refers to RSVP itself.  Depending on the
+       network configuration:
+
+       *  the router either forwards the received RSVP request to the
+          policy decision point (e.g., using COPS [10] and [11]) to
+          request that an admission control procedure be executed, or
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 18]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       *  the router supports the functionality of a PDP and, therefore,
+          there is no need to forward the request, or
+
+       *  the router may already be configured with the appropriate
+          policy information to decide locally whether to grant this
+          request.
+
+       Based on the result of the admission control, the request may be
+       granted or rejected.  Information about the resource-requesting
+       entity must be available to provide policy-based admission
+       control.
+
+   (7) Performance
+
+       The computation of the keyed message digest for an RSVP INTEGRITY
+       object does not represent a performance problem.  The protection
+       of signaling messages is usually not a problem, because these
+       messages are transmitted at a low rate.  Even a high volume of
+       messages does not cause performance problems for an RSVP router
+       due to the efficiency of the keyed message digest routine.
+
+       Dynamic key management, which is computationally more demanding,
+       is more important for scalability.  Because RSVP does not specify
+       a particular key exchange protocol, it is difficult to estimate
+       the effort needed to create the required security associations.
+       Furthermore, the number of key exchanges to be triggered depends
+       on security policy issues like lifetime of a security
+       association, required security properties of the key exchange
+       protocol, authentication mode used by the key exchange protocol,
+       etc.  In a stationary environment with a single administrative
+       domain, manual security association establishment may be
+       acceptable and may provide the best performance characteristics.
+       In a mobile environment, asymmetric authentication methods are
+       likely to be used with a key exchange protocol, and some sort of
+       public key or certificate verification needs to be supported.
+
+4.3.  User to PEP/PDP
+
+   As noted in the previous section, RSVP supports both user-based and
+   host-based authentication.  Using RSVP, a user may authenticate to
+   the first hop router or to the PDP as specified in [1], depending on
+   the infrastructure provided by the network domain or the architecture
+   used (e.g., the integration of RSVP and Kerberos V5 into the Windows
+   2000 Operating System [25]).  Another architecture in which RSVP is
+   tightly integrated is the one specified by the PacketCable
+   organization.  The interested reader is referred to [26] for a
+   discussion of their security architecture.
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 19]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   (1) Authentication
+
+       When a user sends an RSVP PATH or RESV message, this message may
+       include some information to authenticate the user. [7] describes
+       how user and application information is embedded into the RSVP
+       message (AUTH_DATA object) and how to protect it.  A router
+       receiving such a message can use this information to authenticate
+       the client and forward the user or application information to the
+       policy decision point (PDP).  Optionally, the PDP itself can
+       authenticate the user, which is described in the next section.
+       To be able to authenticate the user, to verify the integrity, and
+       to check for replays, the entire POLICY_DATA element has to be
+       forwarded from the router to the PDP (e.g., by including the
+       element into a COPS message).  It is assumed, although not
+       clearly specified in [7], that the INTEGRITY object within the
+       POLICY_DATA element is sent to the PDP along with all other
+       attributes.
+
+       *  Certificate Verification
+
+          Using the policy element as described in [7], it is not
+          possible to provide a certificate revocation list or other
+          information to prove the validity of the certificate inside
+          the policy element.  A specific mechanism for certificate
+          verification is not discussed in [7] and hence a number of
+          them can be used for this purpose.  For certificate
+          verification, the network element (a router or the policy
+          decision point) that has to authenticate the user could
+          frequently download certificate revocation lists or use a
+          protocol like the Online Certificate Status Protocol (OCSP)
+          [27] and the Simple Certificate Validation Protocol (SCVP)
+          [28] to determine the current status of a digital certificate.
+
+       *  User Authentication to the PDP
+
+          This alternative authentication procedure uses the PDP to
+          authenticate the user instead of the first-hop router.  In
+          Section 4.2.1 of [7], the choice is given for the user to
+          obtain a session ticket either for the next hop router or for
+          the PDP.  As noted in the same section, the identity of the
+          PDP or the next hop router is statically configured or
+          dynamically retrieved.  Subsequently, user authentication to
+          the PDP is considered.
+
+       *  Kerberos-based Authentication to the PDP
+
+          If Kerberos is used to authenticate the user, then a session
+          ticket for the PDP must be requested first.  A user who roams
+
+
+
+Tschofenig & Graveman        Informational                     [Page 20]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+          between different routers in the same administrative domain
+          does not need to request a new service ticket, because the
+          same PDP is likely to be used by most or all first-hop routers
+          within the same administrative domain.  This is different from
+          the case in which a session ticket for a router has to be
+          obtained and authentication to a router is required.  The
+          router therefore plays a passive role of simply forwarding the
+          request to the PDP and executing the policy decision returned
+          by the PDP.  Appendix B describes one example of user-to-PDP
+          authentication.
+
+          User authentication with the policy element provides only
+          unilateral authentication, whereby the client authenticates to
+          the router or to the PDP.  If an RSVP message is sent to the
+          user's host and public-key-based authentication is not used,
+          then the message does not contain a certificate and digital
+          signature.  Hence, no mutual authentication can be assumed.
+          In case of Kerberos, mutual authentication may be accomplished
+          if the PDP or the router transmits a policy element with an
+          INTEGRITY object computed with the session key retrieved from
+          the Kerberos ticket, or if the Kerberos ticket included in the
+          policy element is also used for the RSVP INTEGRITY object as
+          described in Section 4.2.  This procedure only works if a
+          previous message was transmitted from the end host to the
+          network and such key is already established.  Reference [7]
+          does not discuss this issue, and therefore there is no
+          particular requirement for transmitting network-specific
+          credentials back to the end-user's host.
+
+   (2) Integrity Protection
+
+          Integrity protection is applied separately to the RSVP message
+          and the POLICY_DATA element, as shown in Figure 1.  In case of
+          a policy-ignorant node along the path, the RSVP INTEGRITY
+          object and the INTEGRITY object inside the policy element
+          terminate at different nodes.  Basically, the same is true for
+          the user credentials if they are verified at the policy
+          decision point instead of the first hop router.
+
+       *  Kerberos
+
+          If Kerberos is used to authenticate the user to the first hop
+          router, then the session key included in the Kerberos ticket
+          may be used to compute the INTEGRITY object of the policy
+          element.  It is the keyed message digest that provides the
+          authentication.  The existence of the Kerberos service ticket
+          inside the AUTH_DATA object does not provide authentication or
+          a guarantee of freshness for the receiving host.
+
+
+
+Tschofenig & Graveman        Informational                     [Page 21]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+          Authentication and guarantee of freshness are provided by the
+          keyed hash value of the INTEGRITY object inside the
+          POLICY_DATA element.  This shows that the user actively
+          participated in the Kerberos protocol and was able to obtain
+          the session key to compute the keyed message digest.  The
+          Authenticator used in the Kerberos V5 protocol provides
+          similar functionality, but replay protection is based on
+          timestamps (or on a sequence number if the optional seq-number
+          field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
+          messages as described in Section 5.3.2 of [8]).
+
+       *  Digital Signature
+
+          If public-key-based authentication is provided, then user
+          authentication is accomplished with a digital signature.  As
+          explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE
+          attribute must be the last attribute in the AUTH_DATA object,
+          and the digital signature covers the entire AUTH_DATA object.
+          In the case of PGP, which hash algorithm and public key
+          algorithm are used for the digital signature computation is
+          described in [19].  In the case of X.509 credentials, the
+          situation is more complex because different mechanisms like
+          CMS [29] or PKCS#7 [30] may be used for digitally signing the
+          message element.  X.509 only provides the standard for the
+          certificate layout, which seems to provide insufficient
+          information for this purpose.  Therefore, X.509 certificates
+          are supported, for example, by CMS or PKCS#7. [7], however,
+          does not make any statements about the usage of CMS or PKCS#7.
+          Currently, there is no support for CMS or for PKCS#7 [7],
+          which provides more than just public-key-based authentication
+          (e.g., CRL distribution, key transport, key agreement, etc.).
+          Furthermore, the use of PGP in RSVP is vaguely defined,
+          because there are different versions of PGP (including OpenPGP
+          [19]), and no indication is given as to which should be used.
+
+          Supporting public-key-based mechanisms in RSVP might increase
+          the risks of denial-of-service attacks.  The large processing,
+          memory, and bandwidth requirements should also be considered.
+          Fragmentation might also be an issue here.
+
+          If the INTEGRITY object is not included in the POLICY_DATA
+          element or not sent to the PDP, then we have to make the
+          following observations:
+
+             For the digital signature case, only the replay protection
+             provided by the digital signature algorithm can be used.
+             It is not clear, however, whether this usage was
+             anticipated or not.  Hence, we might assume that replay
+
+
+
+Tschofenig & Graveman        Informational                     [Page 22]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+             protection is based on the availability of the RSVP
+             INTEGRITY object used with a security association that is
+             established by other means.
+
+             Including only the Kerberos session ticket is insufficient,
+             because freshness is not provided (because the Kerberos
+             Authenticator is missing).  Obviously there is no guarantee
+             that the user actually followed the Kerberos protocol and
+             was able to decrypt the received TGS_REP (or, in rare
+             cases, the AS_REP if a session ticket is requested with the
+             initial AS_REQ).
+
+   (3) Replay Protection
+
+       Figure 5 shows the interfaces relevant for replay protection of
+       signaling messages in a more complicated architecture.  In this
+       case, the client uses the policy data element with PEP2, because
+       PEP1 is not policy-aware.  The interfaces between the client and
+       PEP1 and between PEP1 and PEP2 are protected with the RSVP
+       INTEGRITY object.  The link between the PEP2 and the PDP is
+       protected, for example, by using the COPS built-in INTEGRITY
+       object.  The dotted line between the Client and the PDP indicates
+       the protection provided by the AUTH_DATA element, which has no
+       RSVP INTEGRITY object included.
+
+                        AUTH_DATA                         +----+
+      +---------------------------------------------------+PDP +-+
+      |                                                   +----+ |
+      |                                                          |
+      |                                                          |
+      |                                                 COPS     |
+      |                                                 INTEGRITY|
+      |                                                          |
+      |                                                          |
+      |                                                          |
+   +--+---+   RSVP INTEGRITY  +----+    RSVP INTEGRITY    +----+ |
+   |Client+-------------------+PEP1+----------------------+PEP2+-+
+   +--+---+                   +----+                      +-+--+
+      |                                                     |
+      +-----------------------------------------------------+
+                       POLICY_DATA INTEGRITY
+
+                       Figure 5: Replay Protection.
+
+       Host authentication with the RSVP INTEGRITY object and user
+       authentication with the INTEGRITY object inside the POLICY_DATA
+       element both use the same anti-replay mechanism.  The length of
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 23]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       the Sequence Number field, sequence number rollover, and the
+       Integrity Handshake have already been explained in Section 3.1.
+
+       Section 9 of [7] states: "RSVP INTEGRITY object is used to
+       protect the policy object containing user identity information
+       from security (replay) attacks."  When using public-key-based
+       authentication, RSVP-based replay protection is not supported,
+       because the digital signature does not cover the POLICY_DATA
+       INTEGRITY object with its Sequence Number field.  The digital
+       signature covers only the entire AUTH_DATA object.
+
+       The use of public key cryptography within the AUTH_DATA object
+       complicates replay protection.  Digital signature computation
+       with PGP is described in [31] and in [19].  The data structure
+       preceding the signed message digest includes information about
+       the message digest algorithm used and a 32-bit timestamp of when
+       the signature was created ("Signature creation time").  The
+       timestamp is included in the computation of the message digest.
+       The IETF standardized version of OpenPGP [19] contains more
+       information and describes the different hash algorithms (MD2,
+       MD5, SHA-1, RIPEMD-160) supported. [7] does not make any
+       statements as to whether the "Signature creation time" field is
+       used for replay protection.  Using timestamps for replay
+       protection requires different synchronization mechanisms in the
+       case of clock-skew.  Traditionally, these cases assume "loosely
+       synchronized" clocks but also require specifying a replay window.
+
+       If the "Signature creation time" is not used for replay
+       protection, then a malicious, policy-ignorant node can use this
+       weakness to replace the AUTH_DATA object without destroying the
+       digital signature.  If this was not simply an oversight, it is
+       therefore assumed that replay protection of the user credentials
+       was not considered an important security requirement, because the
+       hop-by-hop processing of the RSVP message protects the message
+       against modification by an adversary between two communicating
+       nodes.
+
+       The lifetime of the Kerberos ticket is based on the fields
+       starttime and endtime of the EncTicketPart structure in the
+       ticket, as described in Section 5.3.1 of [8].  Because the ticket
+       is created by the KDC located at the network of the verifying
+       entity, it is not difficult to have the clocks roughly
+       synchronized for the purpose of lifetime verification.
+       Additional information about clock-synchronization and Kerberos
+       can be found in [32].
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 24]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       If the lifetime of the Kerberos ticket expires, then a new ticket
+       must be requested and used.  Rekeying is implemented with this
+       procedure.
+
+   (4) (User Identity) Confidentiality
+
+       This section discusses privacy protection of identity information
+       transmitted inside the policy element.  User identity
+       confidentiality is of particular interest because there is no
+       built-in RSVP mechanism for encrypting the POLICY_DATA object or
+       the AUTH_DATA elements.  Encryption of one of the attributes
+       inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
+       discussed.
+
+       To protect the user's privacy, it is important not to reveal the
+       user's identity to an adversary located between the user's host
+       and the first-hop router (e.g., on a wireless link).
+       Furthermore, user identities should not be transmitted outside
+       the domain of the visited network provider.  That is, the user
+       identity information inside the policy data element should be
+       removed or modified by the PDP to prevent revealing its contents
+       to other (unauthorized) entities along the signaling path.  It is
+       not possible (with the offered mechanisms) to hide the user's
+       identity in such a way that it is not visible to the first
+       policy-aware RSVP node (or to the attached network in general).
+
+       The ASCII or Unicode distinguished name of the user or
+       application inside the POLICY_LOCATOR attribute of the AUTH_DATA
+       element may be encrypted as specified in Section 3.3.1 of [7].
+       The user (or application) identity is then encrypted with either
+       the Kerberos session key or with the private key in case of
+       public-key-based authentication.  When the private key is used,
+       we usually speak of a digital signature that can be verified by
+       everyone possessing the public key.  Because the certificate with
+       the public key is included in the message itself, decryption is
+       no obstacle.  Furthermore, the included certificate together with
+       the additional (unencrypted) information in the RSVP message
+       provides enough identity information for an eavesdropper.  Hence,
+       the possibility of encrypting the policy locator in case of
+       public-key-based authentication is problematic.  To encrypt the
+       identities using asymmetric cryptography, the user's host must be
+       able somehow to retrieve the public key of the entity verifying
+       the policy element (i.e., the first policy-aware router or the
+       PDP).  Then, this public key could be used to encrypt a symmetric
+       key, which in turn encrypts the user's identity and certificate,
+       as is done, e.g., by PGP.  Currently, no such mechanism is
+       defined in [7].
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 25]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       The algorithm used to encrypt the POLICY_LOCATOR with the
+       Kerberos session key is assumed to be the same as the one used
+       for encrypting the service ticket.  The information about the
+       algorithm used is available in the etype field of the
+       EncryptedData ASN.1 encoded message part.  Section 6.3 of [8]
+       lists the supported algorithms. [33] defines newer encryption
+       algorithms (Rijndael, Serpent, and Twofish).
+
+       Evaluating user identity confidentiality also requires looking at
+       protocols executed outside of RSVP (for example, the Kerberos
+       protocol).  The ticket included in the CREDENTIAL attribute may
+       provide user identity protection by not including the optional
+       cname attribute inside the unencrypted part of the Ticket.
+       Because the Authenticator is not transmitted with the RSVP
+       message, the cname and the crealm of the unencrypted part of the
+       Authenticator are not revealed.  In order for the user to request
+       the Kerberos session ticket for inclusion in the CREDENTIAL
+       attribute, the Kerberos protocol exchange must be executed.  Then
+       the Authenticator sent with the TGS_REQ reveals the identity of
+       the user.  The AS_REQ must also include the user's identity to
+       allow the Kerberos Authentication Server to respond with an
+       AS_REP message that is encrypted with the user's secret key.
+       Using Kerberos, it is therefore only possible to hide the content
+       of the encrypted policy locator, which is only useful if this
+       value differs from the Kerberos principal name.  Hence, using
+       Kerberos it is not "entirely" possible to provide user identity
+       confidentiality.
+
+       It is important to note that information stored in the policy
+       element may be changed by a policy-aware router or by the policy
+       decision point.  Which parts are changed depends upon whether
+       multicast or unicast is used, how the policy server reacts, where
+       the user is authenticated, whether the user needs to be re-
+       authenticated in other network nodes, etc.  Hence, user-specific
+       and application-specific information can leak after the messages
+       leave the first hop within the network where the user's host is
+       attached.  As mentioned at the beginning of this section, this
+       information leakage is assumed to be intentional.
+
+   (5) Authorization
+
+       In addition to the description of the authorization steps of the
+       Host-to-Router interface, user-based authorization is performed
+       with the policy element providing user credentials.  The
+       inclusion of user and application specific information enables
+       policy-based admission control with special user policies that
+       are likely to be stored at a dedicated server.  Hence, a Policy
+       Decision Point can query, for example, an LDAP server for a
+
+
+
+Tschofenig & Graveman        Informational                     [Page 26]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       service level agreement that states the amount of resources a
+       certain user is allowed to request.  In addition to the user
+       identity information, group membership and other non-security-
+       related information may contribute to the evaluation of the final
+       policy decision.  If the user is not registered to the currently
+       attached domain, then there is the question of how much
+       information the home domain of the user is willing to exchange.
+       This also impacts the user's privacy policy.
+
+       In general, the user may not want to distribute much of this
+       policy information.  Furthermore, the lack of a standardized
+       authorization data format may create interoperability problems
+       when exchanging policy information.  Hence, we can assume that
+       the policy decision point may use information from an initial
+       authentication and key agreement protocol (which may have already
+       required cross-realm communication with the user's home domain,
+       if only to show that the home domain knows the user and that the
+       user is entitled to roam), to forward accounting messages to this
+       domain.  This represents the traditional subscriber-based
+       accounting scenario.  Non-traditional or alternative means of
+       access might be deployed in the near future that do not require
+       any type of inter-domain communication.
+
+       Additional discussions are required to determine the expected
+       authorization procedures. [34] and [35] discuss authorization
+       issues for QoS signaling protocols.  Furthermore, a number of
+       mobility implications for policy handling in RSVP are described
+       in [36].
+
+   (6) Performance
+
+       If Kerberos is used for user authentication, then a Kerberos
+       ticket must be included in the CREDENTIAL Section of the
+       AUTH_DATA element.  The Kerberos ticket has a size larger than
+       500 bytes, but it only needs to be sent once because a
+       performance optimization allows the session key to be cached as
+       noted in Section 7.1 of [1].  It is assumed that subsequent RSVP
+       messages only include the POLICY_DATA INTEGRITY object with a
+       keyed message digest that uses the Kerberos session key.
+       However, this assumes that the security association required for
+       the POLICY_DATA INTEGRITY object is created (or modified) to
+       allow the selection of the correct key.  Otherwise, it difficult
+       to say which identifier is used to index the security
+       association.
+
+       If Kerberos is used as an authentication system then, from a
+       performance perspective, the message exchange to obtain the
+       session key needs to be considered, although the exchange only
+
+
+
+Tschofenig & Graveman        Informational                     [Page 27]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+       needs to be done once in the lifetime of the session ticket.
+       This is particularly true in a mobile environment with a fast
+       roaming user's host.
+
+       Public-key-based authentication usually provides the best
+       scalability characteristics for key distribution, but the
+       protocols are performance demanding.  A major disadvantage of the
+       public-key-based user authentication in RSVP is the lack of a
+       method to derive a session key.  Hence, every RSVP PATH or RESV
+       message includes the certificate and a digital signature, which
+       is a huge performance and bandwidth penalty.  For a mobile
+       environment with low power devices, high latency, channel noise,
+       and low-bandwidth links, this seems to be less encouraging.  Note
+       that a public key infrastructure is required to allow the PDP (or
+       the first-hop router) to verify the digital signature and the
+       certificate.  To check for revoked certificates, certificate
+       revocation lists or protocols like the Online Certificate Status
+       Protocol [27] and the Simple Certificate Validation Protocol [28]
+       are needed.  Then the integrity of the AUTH_DATA object can be
+       verified via the digital signature.
+
+4.4.  Communication between RSVP-Aware Routers
+
+   (1) Authentication
+
+       RSVP signaling messages have data origin authentication and are
+       protected against modification and replay with the RSVP INTEGRITY
+       object.  The RSVP message flow between routers is protected based
+       on the chain of trust, and hence each router needs only a
+       security association with its neighboring routers.  This
+       assumption was made because of performance advantages and because
+       of special security characteristics of the core network to which
+       no user hosts are directly attached.  In the core network the
+       network structure does not change frequently and the manual
+       distribution of shared secrets for the RSVP INTEGRITY object may
+       be acceptable.  The shared secrets may be either manually
+       configured or distributed by using appropriately secured network
+       management protocols like SNMPv3.
+
+       Independent of the key distribution mechanism, host
+       authentication with built-in RSVP mechanisms is accomplished
+       using the keyed message digest in the RSVP INTEGRITY object,
+       computed using the previously exchanged symmetric key.
+
+   (2) Integrity Protection
+
+       Integrity protection is accomplished with the RSVP INTEGRITY
+       object with the variable length Keyed Message Digest field.
+
+
+
+Tschofenig & Graveman        Informational                     [Page 28]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   (3) Replay Protection
+
+       Replay protection with the RSVP INTEGRITY object is extensively
+       described in previous sections.  To enable crashed hosts to learn
+       the latest sequence number used, the Integrity Handshake
+       mechanism is provided in RSVP.
+
+   (4) Confidentiality
+
+       Confidentiality is not provided by RSVP.
+
+   (5) Authorization
+
+       Depending on the RSVP network, QoS resource authorization at
+       different routers may need to contact the PDP again.  Because the
+       PDP is allowed to modify the policy element, a token may be added
+       to the policy element to increase the efficiency of the re-
+       authorization procedure.  This token is used to refer to an
+       already computed policy decision.  The communications interface
+       from the PEP to the PDP must be properly secured.
+
+   (6) Performance
+
+       The performance characteristics for the protection of the RSVP
+       signaling messages is largely determined by the key exchange
+       protocol, because the RSVP INTEGRITY object is only used to
+       compute a keyed message digest of the transmitted signaling
+       messages.
+
+       The security associations within the core network, that is,
+       between individual routers (in comparison with the security
+       association between the user's host and the first-hop router or
+       with the attached network in general), can be established more
+       easily because of the normally strong trust assumptions.
+       Furthermore, it is possible to use security associations with an
+       increased lifetime to avoid frequent rekeying.  Hence, there is
+       less impact on the performance compared with the user-to-network
+       interface.  The security association storage requirements are
+       also less problematic.
+
+5.  Miscellaneous Issues
+
+   This section describes a number of issues that illustrate some of the
+   shortcomings of RSVP with respect to security.
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 29]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+5.1.  First-Hop Issue
+
+   In case of end-to-end signaling, an end host starts signaling to its
+   attached network.  The first-hop communication is often more
+   difficult to secure because of the different requirements and a
+   missing trust relationship.  An end host must therefore obtain some
+   information to start RSVP signaling:
+
+       o  Does this network support RSVP signaling?
+
+       o  Which node supports RSVP signaling?
+
+       o  To which node is authentication required?
+
+       o  Which security mechanisms are used for authentication?
+
+       o  Which algorithms are required?
+
+       o  Where should the keys and security associations come from?
+
+       o  Should a security association be established?
+
+   RSVP, as specified today, is used as a building block.  Hence, these
+   questions have to be answered as part of overall architectural
+   considerations.  Without answers to these questions, ad hoc RSVP
+   communication by an end host roaming to an unknown network is not
+   possible.  A negotiation of security mechanisms and algorithms is not
+   supported for RSVP.
+
+5.2.  Next-Hop Problem
+
+   Throughout the document it was assumed that the next RSVP node along
+   the path is always known.  Knowing the next hop is important to be
+   able to select the correct key for the RSVP Integrity object and to
+   apply the proper protection.  In the case in which an RSVP node
+   assumes it knows which node is the next hop, the following protocol
+   exchange can occur:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 30]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+                      Integrity
+                          (A<->C)               +------+
+                                      (3)       | RSVP |
+                                 +------------->+ Node |
+                                 |              |  B   |
+                    Integrity    |              +--+---+
+                     (A<->C)     |                 |
+          +------+    (2)     +--+----+            |
+     (1)  | RSVP +----------->+Router |            |  Error
+    ----->| Node |            | or    +<-----------+ (I am B)
+          |  A   +<-----------+Network|       (4)
+          +------+    (5)     +--+----+
+                     Error       .
+                    (I am B)     .              +------+
+                                 .              | RSVP |
+                                 ...............+ Node |
+                                                |  C   |
+                                                +------+
+
+                         Figure 6: Next-Hop Issue.
+
+   When RSVP node A in Figure 6 receives an incoming RSVP Path message,
+   standard RSVP message processing takes place.  Node A then has to
+   decide which key to select to protect the signaling message.  We
+   assume that some unspecified mechanism is used to make this decision.
+   In this example, node A assumes that the message will travel to RSVP
+   node C.  However, for some reasons (e.g., a route change, inability
+   to learn the next RSVP hop along the path, etc.) the message travels
+   to node B via a non-RSVP supporting router that cannot verify the
+   integrity of the message (or cannot decrypt the Kerberos service
+   ticket).  The processing failure causes a PathErr message to be
+   returned to the originating sender of the Path message.  This error
+   message also contains information about the node that recognized the
+   error.  In many cases, a security association might not be available.
+   Node A receiving the PathErr message might use the information
+   returned with the PathErr message to select a different security
+   association (or to establish one).
+
+   Figure 6 describes a behavior that might help node A learn that an
+   error occurred.  However, the description in Section 4.2 of [1]
+   states in step (5) that a signaling message is silently discarded if
+   the receiving host cannot properly verify the message: "If the
+   calculated digest does not match the received digest, the message is
+   discarded without further processing."  For RSVP Path and similar
+   messages, this functionality is not really helpful.
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 31]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   The RSVP Path message therefore provides a number of functions: path
+   discovery, detecting route changes, discovery of QoS capabilities
+   along the path using the Adspec object (with some interpretation),
+   next-hop discovery, and possibly security association establishment
+   (for example, in the case of Kerberos).
+
+   From a security point of view, there are conflicts between:
+
+   o  Idempotent message delivery and efficiency
+
+      The RSVP Path message especially performs a number of functions.
+      Supporting idempotent message delivery somehow contradicts with
+      security association establishment, efficient message delivery,
+      and message size.  For example, a "real" idempotent signaling
+      message would contain enough information to perform security
+      processing without depending on a previously executed message
+      exchange.  Adding a Kerberos ticket with every signaling message
+      is, however, inefficient.  Using public-key-based mechanisms is
+      even more inefficient when included in every signaling message.
+      With public-key-based protection for idempotent messages, there is
+      the additional risk of introducing denial-of-service attacks.
+
+   o  RSVP Path message functionality and next-hop discovery
+
+      To protect an RSVP signaling message (and an RSVP Path message in
+      particular) it is necessary to know the identity of the next
+      RSVP-aware node (and some other parameters).  Without a mechanism
+      for next-hop discovery, an RSVP Path message is also responsible
+      for this task.  Without knowing the identity of the next hop, the
+      Kerberos principal name is also unknown.  The so-called Kerberos
+      user-to-user authentication mechanism, which would allow the
+      receiver to trigger the process of establishing Kerberos
+      authentication, is not supported.  This issue will again be
+      discussed in relationship with the last-hop problem.
+
+      It is fair to assume that an RSVP-supporting node might not have
+      security associations with all immediately neighboring RSVP nodes.
+      Especially for inter-domain signaling, IntServ over DiffServ, or
+      some new applications such as firewall signaling, the next RSVP-
+      aware node might not be known in advance.  The number of next RSVP
+      nodes might be considerably large if they are separated by a large
+      number of non-RSVP aware nodes.  Hence, a node transmitting an
+      RSVP Path message might experience difficulties in properly
+      protecting the message if it serves as a mechanism to detect both
+      the next RSVP node (i.e., Router Alert Option added to the
+      signaling message and addressed to the destination address) and to
+      detect route changes.  It is fair to note that, in the intra-
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 32]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+      domain case with a dense distribution of RSVP nodes, protection
+      might be possible with manual configuration.
+
+      Nothing prevents an adversary from continuously flooding an RSVP
+      node with bogus PathErr messages, although it might be possible to
+      protect the PathErr message with an existing, available security
+      association.  A legitimate RSVP node would believe that a change
+      in the path took place.  Hence, this node might try to select a
+      different security association or try to create one with the
+      indicated node.  If an adversary is located somewhere along the
+      path, and either authentication or authorization is not performed
+      with the necessary strength and accuracy, then it might also be
+      possible to act as a man-in-the-middle.  One method of reducing
+      susceptibility to this attack is as follows: when a PathErr
+      message is received from a node with which no security association
+      exists, attempt to establish a security association and then
+      repeat the action that led to the PathErr message.
+
+5.3.  Last-Hop Issue
+
+   This section tries to address practical difficulties when
+   authentication and key establishment are accomplished with a two-
+   party protocol that shows some asymmetry in message processing.
+   Kerberos is such a protocol and also the only supported protocol that
+   provides dynamic session key establishment for RSVP.  For first-hop
+   communication, authentication is typically done between a user and
+   some router (for example the access router).  Especially in a mobile
+   environment, it is not feasible to authenticate end hosts based on
+   their IP or MAC address.  To illustrate this problem, the typical
+   processing steps for Kerberos are shown for first-hop communication:
+
+   (1) The end host A learns the identity (i.e., Kerberos principal
+       name) of some entity B.  This entity B is either the next RSVP
+       node, a PDP, or the next policy-aware RSVP node.
+
+   (2) Entity A then requests a ticket granting ticket for the network
+       domain.  This assumes that the identity of the network domain is
+       known.
+
+   (3) Entity A then requests a service ticket for entity B, whose name
+       was learned in step (1).
+
+   (4) Entity A includes the service ticket with the RSVP signaling
+       message (inside the policy object).  The Kerberos session key is
+       used to protect the integrity of the entire RSVP signaling
+       message.
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 33]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   For last-hop communication, this processing theoretically has to be
+   reversed: entity A is then a node in the network (for example, the
+   access router) and entity B is the other end host (under the
+   assumption that RSVP signaling is accomplished between two end hosts
+   and not between an end host and an application server).  However, the
+   access router in step (1) might not be able to learn the user's
+   principal name because this information might not be available.
+   Entity A could reverse the process by triggering an IAKERB exchange.
+   This would cause entity B to request a service ticket for A as
+   described above.  However, IAKERB is not supported in RSVP.
+
+5.4.  RSVP- and IPsec-Protected Data Traffic
+
+   QoS signaling requires flow information to be established at routers
+   along a path.  This flow identifier installed at each device tells
+   the router which data packets should receive QoS treatment.  RSVP
+   typically establishes a flow identifier based on the 5-tuple (source
+   IP address, destination IP address, transport protocol type, source
+   port, and destination port).  If this 5-tuple information is not
+   available, then other identifiers have to be used.  ESP-encrypted
+   data traffic is such an example where the transport protocol and the
+   port numbers are not accessible.  Hence, the IPsec SPI is used as a
+   substitute for them. [12] considers these IPsec implications for RSVP
+   and is based on three assumptions:
+
+   (1) An end host that initiates the RSVP signaling message exchange
+       has to be able to retrieve the SPI for a given flow.  This
+       requires some interaction with the IPsec security association
+       database (SAD) and security policy database (SPD) [3].  An
+       application usually does not know the SPI of the protected flow
+       and cannot provide the desired values.  It can provide the
+       signaling protocol daemon with flow identifiers.  The signaling
+       daemon would then need to query the SAD by providing the flow
+       identifiers as input parameters and receiving the SPI as an
+       output parameter.
+
+   (2) [12] assumes end-to-end IPsec protection of the data traffic.  If
+       IPsec is applied in a nested fashion, then parts of the path do
+       not experience QoS treatment.  This can be treated as a problem
+       of tunneling that is initiated by the end host.  The following
+       figure better illustrates the problem in the case of enforcing
+       secure network access:
+
+
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 34]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+    +------+          +---------------+      +--------+          +-----+
+    | Host |          | Security      |      | Router |          | Host|
+    |  A   |          | Gateway (SGW) |      |   Rx   |          |  B  |
+    +--+---+          +-------+-------+      +----+---+          +--+--+
+       |                      |                   |                 |
+       |IPsec-Data(           |                   |                 |
+       | OuterSrc=A,          |                   |                 |
+       | OuterDst=SGW,        |                   |                 |
+       | SPI=SPI1,            |                   |                 |
+       | InnerSrc=A,          |                   |                 |
+       | InnerDst=B,          |                   |                 |
+       | Protocol=X,          |IPsec-Data(        |                 |
+       | SrcPort=Y,           | SrcIP=A,          |                 |
+       | DstPort=Z)           | DstIP=B,          |                 |
+       |=====================>| Protocol=X,       |IPsec-Data(      |
+       |                      | SrcPort=Y,        | SrcIP=A,        |
+       | --IPsec protected->  | DstPort=Z)        | DstIP=B,        |
+       |    data traffic      |------------------>| Protocol=X,     |
+       |                      |                   | SrcPort=Y,      |
+       |                      |                   | DstPort=Z)      |
+       |                      |                   |---------------->|
+       |                      |                   |                 |
+       |                      |     --Unprotected data traffic--->  |
+       |                      |                   |                 |
+
+              Figure 7: RSVP and IPsec protected data traffic.
+
+       Host A, transmitting data traffic, would either indicate a 3-
+       tuple <A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>.  In any case,
+       it is not possible to make a QoS reservation for the entire path.
+       Two similar examples are remote access using a VPN and protection
+       of data traffic between a home agent (or a security gateway in
+       the home network) and a mobile node.  The same problem occurs
+       with a nested application of IPsec (for example, IPsec between A
+       and SGW and between A and B).
+
+       One possible solution to this problem is to change the flow
+       identifier along the path to capture the new flow identifier
+       after an IPsec endpoint.
+
+       IPsec tunnels that neither start nor terminate at one of the
+       signaling end points (for example between two networks) should be
+       addressed differently by recursively applying an RSVP signaling
+       exchange for the IPsec tunnel.  RSVP signaling within tunnels is
+       addressed in [13].
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 35]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   (3) It is assumed that SPIs do not change during the lifetime of the
+       established QoS reservation.  If a new IPsec SA is created, then
+
+       a new SPI is allocated for the security association.  To reflect
+       this change, either a new reservation has to be established or
+       the flow identifier of the existing reservation has to be
+       updated.  Because IPsec SAs usually have a longer lifetime, this
+       does not seem to be a major issue.  IPsec protection of SCTP data
+       traffic might more often require an IPsec SA (and SPI) change to
+       reflect added and removed IP addresses from an SCTP association.
+
+5.5.   End-to-End Security Issues and RSVP
+
+   End-to-end security for RSVP has not been discussed throughout the
+   document.  In this context, end-to-end security refers to credentials
+   transmitted between the two end hosts using RSVP.  It is obvious that
+   care must be taken to ensure that routers along the path are able to
+   process and modify the signaling messages according to prescribed
+   processing procedures.  However, some objects or mechanisms could be
+   used for end-to-end protection.  The main question, however, is the
+   benefit of such end-to-end security.  First, there is the question of
+   how to establish the required security association.  Between two
+   arbitrary hosts on the Internet, this might turn out to be quite
+   difficult.  Second, the usefulness of end-to-end security depends on
+   the architecture in which RSVP is deployed.  If RSVP is used only to
+   signal QoS information into the network, and other protocols have to
+   be executed beforehand to negotiate the parameters and to decide
+   which entity is charged for the QoS reservation, then no end-to-end
+   security is likely to be required.  Introducing end-to-end security
+   to RSVP would then cause problems with extensions like RSVP proxy
+   [37], Localized RSVP [38], and others that terminate RSVP signaling
+   somewhere along the path without reaching the destination end host.
+   Such a behavior could then be interpreted as a man-in-the-middle
+   attack.
+
+5.6.  IPsec Protection of RSVP Signaling Messages
+
+   It is assumed throughout that RSVP signaling messages can also be
+   protected by IPsec [3] in a hop-by-hop fashion between two adjacent
+   RSVP nodes.  RSVP, however, uses special processing of signaling
+   messages, which complicates IPsec protection.  As explained in this
+   section, IPsec should only be used for protection of RSVP signaling
+   messages in a point-to-point communication environment (i.e., an RSVP
+   message can only reach one RSVP router and not possibly more than
+   one).  This restriction is caused by the combination of signaling
+   message delivery and discovery into a single message.  Furthermore,
+   end-to-end addressing complicates IPsec handling considerably.  This
+   section describes at least some of these complications.
+
+
+
+Tschofenig & Graveman        Informational                     [Page 36]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   RSVP messages are transmitted as raw IP packets with protocol number
+   46.  It might be possible to encapsulate them in UDP as described in
+   Appendix C of [6].  Some RSVP messages (Path, PathTear, and ResvConf)
+   must have the Router Alert IP Option set in the IP header.  These
+   messages are addressed to the (unicast or multicast) destination
+   address and not to the next RSVP node along the path.  Hence, an
+   IPsec traffic selector can only use these fields for IPsec SA
+   selection.  If there is only a single path (and possibly all traffic
+   along it is protected) then there is no problem for IPsec protection
+   of signaling messages.  This type of protection is not common and
+   might only be used to secure network access between an end host and
+   its first-hop router.  Because the described RSVP messages are
+   addressed to the destination address instead of the next RSVP node,
+   it is not possible to use IPsec ESP [17] or AH [16] in transport
+   mode--only IPsec in tunnel mode is possible.
+
+   If an RSVP message can taket more than one possible path, then the
+   IPsec engine will experience difficulties protecting the message.
+   Even if the RSVP daemon installs a traffic selector with the
+   destination IP address, still, no distinguishing element allows
+   selection of the correct security association for one of the possible
+   RSVP nodes along the path.  Even if it possible to apply IPsec
+   protection (in tunnel mode) for RSVP signaling messages by
+   incorporating some additional information, there is still the
+   possibility that the tunneled messages do not recognize a path change
+   in a non-RSVP router.  In this case the signaling messages would
+   simply follow a different path than the data.
+
+   RSVP messages like RESV can be protected by IPsec, because they
+   contain enough information to create IPsec traffic selectors that
+   allow differentiation between various next RSVP nodes.  The traffic
+   selector would then contain the protocol number and the source and
+   destination address pair of the two communicating RSVP nodes.
+
+   One benefit of using IPsec is the availability of key management
+   using either IKE [39], KINK [40] or IKEv2 [41].
+
+5.7.  Authorization
+
+   [34] describes two trust models (NJ Turnpike and NJ Parkway) and two
+   authorization models (per-session and per-channel financial
+   settlement).  The NJ Turnpike model gives a justification for hop-by-
+   hop security protection.  RSVP focuses on the NJ Turnpike model,
+   although the different trust models are not described in detail.
+   RSVP supports the NJ Parkway model and per-channel financial
+   settlement only to a certain extent.  Authentication of the user (or
+   end host) can be provided with the user identity representation
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 37]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   mechanism, but authentication might, in many cases, be insufficient
+   for authorization.  The communication procedures defined for policy
+
+   objects [42] can be improved to support the more efficient per-
+   channel financial settlement model by avoiding policy handling
+   between inter-domain networks at a signaling message granularity.
+   Additional information about expected behavior of policy handling in
+   RSVP can also be obtained from [43].
+
+   [35] and [36] provide additional information on authorization.  No
+   good and agreed mechanism for dealing with authorization of QoS
+   reservations in roaming environments is provided.  Price distribution
+   mechanisms are only described in papers and never made their way
+   through standardization.  RSVP focuses on receiver-initiated
+   reservations with authorization for the QoS reservation by the data
+   receiver, which introduces a fair amount of complexity for mobility
+   handling as described, for example, in [36].
+
+6.  Conclusions
+
+   RSVP was the first QoS signaling protocol that provided some security
+   protection.  Whether RSVP provides appropriate security protection
+   heavily depends on the environment where it is deployed.  RSVP as
+   specified today should be viewed as a building block that has to be
+   adapted to a given architecture.
+
+   This document aims to provide more insight into the security of RSVP.
+   It cannot be interpreted as a pass or fail evaluation of the security
+   provided by RSVP.
+
+   Certainly this document is not a complete description of all security
+   issues related to RSVP.  Some issues that require further
+   consideration are RSVP extensions (for example [12]), multicast
+   issues, and other security properties like traffic analysis.
+   Additionally, the interaction with mobility protocols (micro- and
+   macro-mobility) demands further investigation from a security point
+   of view.
+
+   What can be learned from practical protocol experience and from the
+   increased awareness regarding security is that some of the available
+   credential types have received more acceptance than others.  Kerberos
+   is a system that is integrated into many IETF protocols today.
+   Public-key-based authentication techniques are, however, still
+   considered to be too heavy-weight (computationally and from a
+   bandwidth perspective) to be used for per-flow signaling.  The
+   increased focus on denial of service attacks puts additional demands
+   on the design of public-key-based authentication.
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 38]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   The following list briefly summarizes a few security or architectural
+   issues that deserve improvement:
+
+   o  Discovery and signaling message delivery should be separated.
+
+   o  For some applications and scenarios, it cannot be assumed that
+      neighboring RSVP-aware nodes know each other.  Hence, some in-path
+      discovery mechanism should be provided.
+
+   o  Addressing for signaling messages should be done in a hop-by-hop
+      fashion.
+
+   o  Standard security protocols (IPsec, TLS, or CMS) should be used
+      whenever possible.  Authentication and key exchange should be
+      separated from signaling message protection.  In general, it is
+      necessary to provide key management to establish security
+      associations dynamically for signaling message protection.
+      Relying on manually configured keys between neighboring RSVP nodes
+      is insufficient.  A separate, less frequently executed key
+      management and security association establishment protocol is a
+      good place to perform entity authentication, security service
+      negotiation and selection, and agreement on mechanisms,
+      transforms, and options.
+
+   o  The use of public key cryptography in authorization tokens,
+      identity representations, selective object protection, etc. is
+      likely to cause fragmentation, the need to protect against denial
+      of service attacks, and other problems.
+
+   o  Public key authentication and user identity confidentiality
+      provided with RSVP require some improvement.
+
+   o  Public-key-based user authentication only provides entity
+      authentication.  An additional security association is required to
+      protect signaling messages.
+
+   o  Data origin authentication should not be provided by non-RSVP
+      nodes (such as the PDP).  Such a procedure could be accomplished
+      by entity authentication during the authentication and key
+      exchange phase.
+
+   o  Authorization and charging should be better integrated into the
+      base protocol.
+
+   o  Selective message protection should be provided.  A protected
+      message should be recognizable from a flag in the header.
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 39]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   o  Confidentiality protection is missing and should therefore be
+      added to the protocol.  The general principle is that protocol
+      designers can seldom foresee all of the environments in which
+      protocols will be run, so they should allow users to select from a
+      full range of security services, as the needs of different user
+      communities vary.
+
+   o  Parameter and mechanism negotiation should be provided.
+
+7.  Security Considerations
+
+   This document discusses security properties of RSVP and, as such, it
+   is concerned entirely with security.
+
+8.  Acknowledgements
+
+   We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu,
+   Guenther Schaefer, Marc De Vuyst, Bob Grillo, and Jukka Manner for
+   their comments.  Additionally, Hannes would like to thank Robert and
+   Jorge for their time discussing various issues.
+
+   Finally, we would like to thank Allison Mankin and John Loughney for
+   their guidance and input.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
+         Authentication", RFC 2747, January 2000.
+
+   [2]   Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
+         January 2000.
+
+   [3]   Kent, S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [4]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+         for Message Authentication", RFC 2104, February 1997.
+
+   [5]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+         1992.
+
+   [6]   Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
+         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
+         Specification", RFC 2205, September 1997.
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 40]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   [7]   Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
+         Herzog, S., and R. Hess, "Identity Representation for RSVP",
+         RFC 3182, October 2001.
+
+   [8]   Kohl, J. and C. Neuman, "The Kerberos Network Authentication
+         Service (V5)", RFC 1510, September 1993.  Obsoleted by RFC
+         4120.
+
+   [9]   Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
+         "Diameter Base Protocol", RFC 3588, September 2003.
+
+   [10]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
+         Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
+         2748, January 2000.
+
+   [11]  Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
+         Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
+
+   [12]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
+         Flows", RFC 2207, September 1997.
+
+   [13]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
+         Operation Over IP Tunnels", RFC 2746, January 2000.
+
+9.2.  Informative References
+
+   [14]  Hess, R. and S. Herzog, "RSVP Extensions for Policy Control",
+         Work in Progress, June 2001.
+
+   [15]  "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal
+         Information Processing Society, April 1995.
+
+   [16]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
+         November 1998.
+
+   [17]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
+         (ESP)", RFC 2406, November 1998.
+
+   [18]  Fowler, D., "Definitions of Managed Objects for the DS1, E1,
+         DS2 and E2 Interface Types", RFC 2495, January 1999.
+
+   [19]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+         "OpenPGP Message Format", RFC 2440, November 1998.
+
+   [20]  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
+         Realm Information with DNS", Work in Progress, July 2002.
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 41]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   [21]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
+         strengthened version of RIPEMD in Fast Software Encryption",
+         LNCS vol. 1039, pp. 71-82, 1996.
+
+   [22]  Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
+         Laboratories CryptoBytes, vol. 2, no. 2, 1996.
+
+   [23]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+         Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
+         3748, June 2004.
+
+   [24]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
+         Authentication Dial In User Service (RADIUS)", RFC 2865, June
+         2000.
+
+   [25]  "Microsoft Authorization Data Specification v. 1.0 for
+         Microsoft Windows 2000 Operating Systems", April 2000.
+
+   [26]  Cable Television Laboratories, Inc., "PacketCable Security
+         Specification, PKT-SP-SEC-I01-991201", website:
+         http://www.PacketCable.com/, June 2003.
+
+   [27]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
+         "X.509 Internet Public Key Infrastructure Online Certificate
+         Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [28]  Malpani, A., Housley, R., and T. Freeman, "Simple Certificate
+         Validation Protocol (SCVP)", Work in Progress, October 2005.
+
+   [29]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
+         August 2002.
+
+   [30]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
+         1.5", RFC 2315, March 1998.
+
+   [31]  "Specifications and standard documents", website:
+         http://www.PacketCable.com/, March 2002.
+
+   [32]  Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History,
+         Protocols and Implementation", USENIX Computing Systems, vol 9
+         no. 1, Winter 1996.
+
+   [33]  Raeburn, K., "Encryption and Checksum Specifications for
+         Kerberos 5", RFC 3961, February 2005.
+
+   [34]  Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
+         Schulzrinne, "NSIS Authentication, Authorization and Accounting
+         Issues", Work in Progress, March 2003.
+
+
+
+Tschofenig & Graveman        Informational                     [Page 42]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   [35]  Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne,
+         H., and T. Chen, "QoS NSLP Authorization Issues", Work in
+         Progress, June 2003.
+
+   [36]  Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work
+         in Progress, October 2002.
+
+   [37]  Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP
+         Proxy", Work in Progress, March 2002.
+
+   [38]  Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K.
+         Raatikainen, "Localized RSVP", Work in Progress, September
+         2004.
+
+   [39]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
+         RFC 2409, November 1998.
+
+   [40]  Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)",
+         Work in Progress, October 2005.
+
+   [41]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+         4306, November 2005.
+
+   [42]  Herzog, S., "Accounting and Access Control in RSVP", PhD
+         Dissertation, USC, Work in Progress, November 1995.
+
+   [43]  Herzog, S., "Accounting and Access Control for Multicast
+         Distributions: Models and Mechanisms", June 1996.
+
+   [44]  Pato, J., "Using Pre-Authentication to Avoid Password Guessing
+         Attacks", Open Software Foundation DCE Request for Comments,
+         December 1992.
+
+   [45]  Tung, B. and L. Zhu, "Public Key Cryptography for Initial
+         Authentication in Kerberos", Work in Progress, November 2005.
+
+   [46]  Wu, T., "A Real-World Analysis of Kerberos Password Security",
+         in Proceedings of the 1999 Internet Society Network and
+         Distributed System Security Symposium, San Diego, February
+         1999.
+
+   [47]  Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP
+         Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64,
+         1999.
+
+   [48]  Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For
+         Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia
+         Security Workshop), November 2000.
+
+
+
+Tschofenig & Graveman        Informational                     [Page 43]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   [49]  Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure
+         RSVP Protocol", International Conf on Multimedia and
+         Exposition, Tokyo, Japan, August 2001.
+
+   [50]  Jablon, D., "Strong Password-only Authenticated Key Exchange",
+         ACM Computer Communication Review, 26(5), pp. 5-26, October
+         1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 44]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+Appendix A.  Dictionary Attacks and Kerberos
+
+   Kerberos might be used with RSVP as described in this document.
+   Because dictionary attacks are often mentioned in relationship with
+   Kerberos, a few issues are addressed here.
+
+   The initial Kerberos AS_REQ request (without pre-authentication,
+   without various extensions, and without PKINIT) is unprotected.  The
+   response message AS_REP is encrypted with the client's long-term key.
+   An adversary can take advantage of this fact by requesting AS_REP
+   messages to mount an off-line dictionary attack.  Pre-authentication
+   ([44]) can be used to reduce this problem.  However, pre-
+   authentication does not entirely prevent dictionary attacks by an
+   adversary who can still eavesdrop on Kerberos messages along the path
+   between a mobile node and a KDC.  With mandatory pre-authentication
+   for the initial request, an adversary cannot request a Ticket
+   Granting Ticket for an arbitrary user.  On-line password guessing
+   attacks are still possible by choosing a password (e.g., from a
+   dictionary) and then transmitting an initial request that includes a
+   pre-authentication data field.  An unsuccessful authentication by the
+   KDC results in an error message and thus gives the adversary a hint
+   to restart the protocol and try a new password.
+
+   There are, however, some proposals that prevent dictionary attacks.
+   The use of Public Key Cryptography for initial authentication [45]
+   (PKINIT) is one such solution.  Other proposals use strong-password-
+   based authenticated key agreement protocols to protect the user's
+   password during the initial Kerberos exchange. [46] discusses the
+   security of Kerberos and also discusses mechanisms to prevent
+   dictionary attacks.
+
+Appendix B.  Example of User-to-PDP Authentication
+
+   The following Section describes an example of user-to-PDP
+   authentication.  Note that the description below is not fully covered
+   by the RSVP specification and hence it should only be viewed as an
+   example.
+
+   Windows 2000, which integrates Kerberos into RSVP, uses a
+   configuration with the user authentication to the PDP as described in
+   [25].  The steps for authenticating the user to the PDP in an intra-
+   realm scenario are the following:
+
+   o  Windows 2000 requires the user to contact the KDC and to request a
+      Kerberos service ticket for the PDP account AcsService in the
+      local realm.
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 45]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   o  This ticket is then embedded into the AUTH_DATA element and
+      included in either the PATH or the RESV message.  In the case of
+      Microsoft's implementation, the user identity encoded as a
+      distinguished name is encrypted with the session key provided with
+      the Kerberos ticket.  The Kerberos ticket is sent without the
+      Kerberos authdata element that contains authorization information,
+      as explained in [25].
+
+   o  The RSVP message is then intercepted by the PEP, which forwards it
+      to the PDP. [25] does not state which protocol is used to forward
+      the RSVP message to the PDP.
+
+   o  The PDP that finally receives the message and decrypts the
+      received service ticket.  The ticket contains the session key used
+      by the user's host to
+
+      *  Encrypt the principal name inside the policy locator field of
+         the AUTH_DATA object and to
+
+      *  Create the integrity-protected Keyed Message Digest field in
+         the INTEGRITY object of the POLICY_DATA element.  The
+         protection described here is between the user's host and the
+         PDP.  The RSVP INTEGRITY object on the other hand is used to
+         protect the path between the user's host and the first-hop
+         router, because the two message parts terminate at different
+         nodes, and different security associations must be used.  The
+         interface between the message-intercepting, first-hop router
+         and the PDP must be protected as well.
+
+      *  The PDP does not maintain a user database, and [25] describes
+         how the PDP may query the Active Directory (a LDAP based
+         directory service) for user policy information.
+
+Appendix C.  Literature on RSVP Security
+
+   Few documents address the security of RSVP signaling.  This section
+   briefly describes some important documents.
+
+   Improvements to RSVP are proposed in [47] to deal with insider
+   attacks.  Insider attacks are caused by malicious RSVP routers that
+   modify RSVP signaling messages in such a way that they cause harm to
+   the nodes participating in the signaling message exchange.
+
+   As a solution, non-mutable RSVP objects are digitally signed by the
+   sender.  This digital signature is added to the RSVP PATH message.
+   Additionally, the receiver attaches an object to the RSVP RESV
+   message containing a "signed" history.  This value allows
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 46]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+   intermediate RSVP routers (by examining the previously signed value)
+   to detect a malicious RSVP node.
+
+   A few issues are, however, left open in this document.  Replay
+   attacks are not covered, and it is therefore assumed that timestamp-
+   based replay protection is used.  To identify a malicious node, it is
+   necessary that all routers along the path are able to verify the
+   digital signature.  This may require a global public key
+   infrastructure and also client-side certificates.  Furthermore, the
+   bandwidth and computational requirements to compute, transmit, and
+   verify digital signatures for each signaling message might place a
+   burden on a real-world deployment.
+
+   Authorization is not considered in the document, which might have an
+   influence on the implications of signaling message modification.
+   Hence, the chain-of-trust relationship (or this step in a different
+   direction) should be considered in relationship with authorization.
+
+   In [48], the above-described idea of detecting malicious RSVP nodes
+   is improved by addressing performance aspects.  The proposed solution
+   is somewhere between hop-by-hop security and the approach in [47],
+   insofar as it separates the end-to-end path into individual networks.
+   Furthermore, some additional RSVP messages (e.g., feedback messages)
+   are introduced to implement a mechanism called "delayed integrity
+   checking."  In [49], the approach presented in [48] is enhanced.
+
+Authors' Addresses
+
+   Hannes Tschofenig
+   Siemens
+   Otto-Hahn-Ring 6
+   Munich, Bavaria  81739
+   Germany
+
+   EMail: Hannes.Tschofenig@siemens.com
+
+
+   Richard Graveman
+   RFG Security
+   15 Park Avenue
+   Morristown, NJ  07960
+   USA
+
+   EMail: rfg@acm.org
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 47]
+
+RFC 4230                RSVP Security Properties           December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Tschofenig & Graveman        Informational                     [Page 48]
+