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

Versions: 00 01 02 03 04 05 06 RFC 4230

   NSIS
   Internet Draft                                      Hannes Tschofenig
                                                                 Siemens
                                                        Richard Graveman
                                                            RFG Security
   Document:
   draft-ietf-nsis-rsvp-sec-properties-05.txt
   Expires: March 2005                                   September 2004
  
  
                         RSVP Security Properties
               <draft-ietf-nsis-rsvp-sec-properties-05.txt>
  
  
  Status of this Memo
  
   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
  
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
  
   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."
  
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
  
  Copyright Notice
  
   Copyright (C) The Internet Society (2004).  All Rights Reserved.
  
  
  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  Expires - March 2005                 [Page 1]
  

                       RSVP Security Properties         September 2004
  
  
  Table of Contents
  
   1. Introduction..................................................2
   2. Terminology and Architectural Assumptions.....................3
   3. Overview......................................................5
      3.1 The RSVP INTEGRITY Object.................................5
      3.2 Security Associations.....................................7
      3.3 RSVP Key Management Assumptions...........................8
      3.4 Identity Representation...................................8
      3.5 RSVP Integrity Handshake.................................12
   4. Detailed Security Property Discussion........................13
      4.1 Network Topology.........................................13
      4.2 Host/Router..............................................14
      4.3 User to PEP/PDP..........................................18
      4.4 Communication between RSVP-Aware Routers.................27
   5. Miscellaneous Issues.........................................29
      5.1 First Hop Issue..........................................29
      5.2 Next-Hop Problem.........................................29
      5.3 Last-Hop Issue...........................................32
      5.4 RSVP and IPsec protected data traffic....................33
      5.5 End-to-End Security Issues and RSVP......................35
      5.6 IPsec protection of RSVP signaling messages..............35
      5.7 Authorization............................................36
   6. Conclusions..................................................37
   7. Security Considerations......................................39
   8. IANA considerations..........................................39
   9. Acknowledgments..............................................39
   10. Normative References........................................41
   11. Informative References......................................42
   Author's Contact Information....................................45
  
  1. Introduction
  
   As the work of the NSIS working group has begun, there are also
   concerns about security and its implications for the design of a
   signaling protocol. 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 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.
  
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 2]
  

                       RSVP Security Properties         September 2004
  
  
   Section 4 provides a more detailed discussion of the mechanisms used
   and tries to describe in detail the mechanisms provided.
  
   Finally a number of miscellaneous issues are described, which
   address first-hop, next-hop, and last-hop issues. Furthermore the
   problem of IPsec security protection of data traffic and RSVP
   signaling messages is discussed.
  
   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.
  
  2. Terminology and Architectural Assumptions
  
   This section describes some important terms and explains some
   architectural assumptions:
  
   - Chain-of-Trust
  
   The security mechanisms supported by RSVP [RFC2747] 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
   network elements 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.
  
   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 unauthorized nodes' injecting bogus
   messages. Furthermore, each RSVP-router is assumed to behave in the
   expected manner. Outgoing messages transmitted to the next hop
   network element receive protection according RSVP security
   processing.
  
   Using the above described mechanisms, a chain-of-trust is created
   whereby a signaling message 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.
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 3]
  

                       RSVP Security Properties         September 2004
  
  
  
   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 not limited
   only 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 more likely 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 [RFC2750] mentions the term chain-of-trust in the
   context of RSVP integrity protection. In Section 6 of [HH01] 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.
  
   - 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.
  
   - 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.
  
   - 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 [RFC2747]. The second is included in the POLICY_DATA
   object and defined in [RFC2750]. To differentiate the two objects
   regarding 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.
  
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 4]
  

                       RSVP Security Properties         September 2004
  
  
   - 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 [RFC2747], the
   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. Furthermore, the RSVP INTEGRITY object
   provides data origin authentication. The attributes of the object
   are briefly described:
  
   - 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 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.
  
   - 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. [RFC2747]
   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
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 5]
  

                       RSVP Security Properties         September 2004
  
  
   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.
  
   - 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 [RFC2747]. 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 [RFC2747] 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.
  
   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 presence of system crashes, failures
   and restarts. Section 3 of [RFC2747] 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 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
  
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 6]
  

                       RSVP Security Properties         September 2004
  
  
   out-of-order delivery, for example, as described in Appendix C of
   [RFC2401].
  
   - Keyed Message Digest
  
   The Keyed Message Digest is a security mechanism built into RSVP and
   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
   [RFC2104] is required for a RSVP implementation as noted in Section
   1 of [RFC2747]. Hash algorithms other than MD5 [RFC1321] like SHA-1
   [SHA] 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 key 160 bits,
   as in IPsec AH [RFC2402]and ESP [RFC2406].
  
  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 [RFC2747]:
  
   - Authentication algorithm and algorithm mode
   - Key
   - Key Lifetime
   - Sending Interface
   - Latest sequence number (sent with this key identifier)
  
   The receiving system has to store the following fields:
  
   - Authentication algorithm and algorithm mode
   - Key
   - Key Lifetime
   - Source address of the sending system
   - List of last n sequence numbers (received with this key
   identifier)
  
  
  
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 7]
  

                       RSVP Security Properties         September 2004
  
  
   Note that the security associations need to have additional fields
   to indicate their state. It is necessary to have an overlapping
   lifetime 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
   either one or both active keys. As mentioned in [RFC2747], 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
  
   [RFC2205] assumes that security associations are already available.
   An implementation must provide manual key distribution as noted in
   Section 5.2 of [RFC2747]. 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 a key engine would be more appropriate. Further
   security requirements listed in Section 5.2 of [RFC2747] are the
   following:
  
   - The manual deletion of security associations must be supported.
   - The key storage should persist a system restart.
   - 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 [RFC2750]. Section 2 of [RFC3182] 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 [RFC2750]. Network nodes like the policy decision point (PDP)
   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 [RFC3182], 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
   [RFC2750]. The attributes contained in the authentication data
   policy element AUTH_DATA, which is defined in [RFC3182], are briefly
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 8]
  

                       RSVP Security Properties         September 2004
  
  
   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.
  
    +--------------------------------------------------------+
    | RSVP Message                                           |
    +--------------------------------------------------------+
    | INTEGRITY +-------------------------------------------+|
    | 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 [RFC3182], 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 [RFC3182], 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 implement an access control
   policy.
  
   The following attributes are defined for the usage in the AUTH_DATA
   object:
  
   a) Policy Locator
  
  
  
  
   Tschofenig, Graveman  Expires - March 2005                 [Page 9]
  

                       RSVP Security Properties         September 2004
  
  
   The policy locator string that is an X.500 distinguished name (DN)
   used to locate user or application specific policy information. The
   following types of X.500 DNs are listed:
  
   - ASCII_DN
   - UNICODE_DN
   - ASCII_DN_ENCRYPT
   - UNICODE_DN_ENCRYPT
  
   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. Such an issue may be
   specified in a concrete architecture where RSVP is used.
  
   b) Credentials
  
   Two cryptographic credentials are currently defined for a user:
   Authentication with Kerberos V5 [RFC1510], and authentication with
   the help of digital signatures based on X.509 [RFC2495] and PGP
   [RFC2440]. The following list contains all defined credential types
   currently available and defined in [RFC3182]:
  
   +--------------+--------------------------------+
   | 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               |
   +--------------+--------------------------------+
  
                  Table 1: Credentials Supported in RSVP
  
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 10]
  

                       RSVP Security Properties         September 2004
  
  
   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, which
   are included for policy-based admission control. Note that these
   plain-text identifiers may, however, be protected if either the RSVP
   INTEGRITY or the 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 [RFC1510] 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
   [RFC2747] 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 [RFC3182] and may involve
   several roundtrips depending on many Kerberos-related factors. The
   Kerberos ticket does not need to be included in every RSVP message
   as an optimization, as described in Section 7.1 of [RFC2747]. 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 timestamps or sequence numbers) is
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 11]
  

                       RSVP Security Properties         September 2004
  
  
   provided by the digital signature is an open issue as discussed in
   Section 4.3.
  
   c) Digital Signature
  
   The digital signature computed over the data 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).
  
   d) 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 [RFC3182].
  
  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
   is a steady flow of RSVP protected messages between the two hosts,
   an attacker may find it difficult to inject old messages, because
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 12]
  

                       RSVP Security Properties         September 2004
  
  
   new, authenticated messages with higher sequence numbers arrive and
   get stored immediately.
  
   The following description explains the details of a 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 2: 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 [RFC2747].
  
   The Integrity Challenge message is not protected with an INTEGRITY
   object as shown in the protocol flow above. As explained in Section
   10 of [RFC2747] 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 (since it may not be needed in all network
   environments).
  
  4. Detailed Security Property Discussion
  
   The purpose of this section is to describe the protection of the
   RSVP-provided mechanisms individually for authentication,
   authorization, integrity and replay protection, user identity
   confidentiality, and confidentiality of the signaling messages.
  
  4.1 Network Topology
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 13]
  

                       RSVP Security Properties         September 2004
  
  
   The main purpose of this paragraph is to show the basic interfaces
   in a simple RSVP network architecture. The architecture below
   assumes that there is only a single domain and that 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 a 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 3: 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. By using the RSVP INTEGRITY object the host is
   authenticated while 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.
  
   a) Authentication
  
   The term host authentication is used above, because the selection of
   the security association is bound to the host's IP address as
   mentioned in Sections 3.1 and 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
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 14]
  

                       RSVP Security Properties         September 2004
  
  
   selecting the security association has already been described in
   Section 3.1.
  
   Data origin authentication is provided with the 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 must therefore be available before
   signaling is started.
  
   - Kerberos for the RSVP INTEGRITY object
  
   As described in Section 7 of [RFC2747], 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 [RFC2747]. Section 4.2.1 of [RFC2747] states that the
   required identities can be obtained statically or dynamically via a
   directory service or DHCP. [HA01] 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 requires
   additional considerations:
  
   Section 7 of [RFC2747] 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.
  
   b) 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,
  
   Tschofenig, Graveman  Expires - March 2005                [Page 15]
  

                       RSVP Security Properties         September 2004
  
  
   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 must support
   the most important keyed hash algorithms for example MD5, SHA-1,
   RIPEMD-160, etc. HMAC-MD5 was mainly chosen because of its
   performance characteristics. The weaknesses of MD5 [DBP96] are known
   and described in [Dob96]. Other algorithms like SHA-1 [SHA] and
   RIPEMD-160 [DBP96] have stronger security properties.
  
   c) 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. 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
   [RFC2747]. We assume that this is a typo. Section 4.1 of [RFC2747]
   gives a few comments about the out-of-order delivery and the ability
   of an implementation to specify the replay window. Appendix C of
   [RFC2401] describes a window mechanism for handling out-of-sequence
   delivery.
  
   - Integrity Handshake
  
   The mechanism of the Integrity Handshake is explained in Section
   3.5. The Cookie value is suggested to be 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.
  
   In Section 10 of [RFC2747] the authors note that an adversary can
   create a faked Integrity Handshake message including 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
  
   Tschofenig, Graveman  Expires - March 2005                [Page 16]
  

                       RSVP Security Properties         September 2004
  
  
   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.
  
   d) 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, in addition to
   users' identities, also billing data, network usage patterns, or
   network configurations 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.
  
   e) 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 [RFC2284] in combination with AAA protocols
   (for example using RADIUS [RFC2865] or DIAMETER [CA+02]). 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., by using COPS (see [RFC2748] and [RFC2749]),
     to request that an admission control procedure be executed or
   - 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 or
     not.
  
   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.
  
   f) Performance
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 17]
  

                       RSVP Security Properties         September 2004
  
  
   The computation of the keyed message digest for a 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 a RSVP routers 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 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, both user-based and host-based
   authentication are supported by RSVP. Using RSVP, a user may
   authenticate to the first hop router or to the PDP as specified in
   [RFC2747], 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 [MADS01]).
   Another architecture in which RSVP is tightly integrated is the one
   specified by the PacketCable organization. The interested reader is
   referred to [PKTSEC] for a discussion of their security
   architecture.
  
   a) Authentication
  
   When a user sends a RSVP PATH or RESV message, this message may
   include some information to authenticate the user. [RFC3182]
   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
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 18]
  

                       RSVP Security Properties         September 2004
  
  
   message. It is assumed, although not clearly specified in [RFC3182],
   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 [RFC3182] 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 [RFC3182] 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), which has to authenticate
   the user, could frequently download certificate revocation lists or
   use a protocol like the Online Certificate Status Protocol (OCSP)
   [RFC2560] and the Simple Certificate Validation Protocol (SCVP)
   [MHHF01] 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 [RFC3182] 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 needs to be requested first. A user who roams between
   different routers in the same administrative domain does not need to
   request a new service ticket, because the 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 forwarding
   the request only 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 only provides unilateral
   authentication whereby the client authenticates to the router or to
   the PDP. If a RSVP message is sent to the user's host and public key
   based authentication is 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
  
   Tschofenig, Graveman  Expires - March 2005                [Page 19]
  

                       RSVP Security Properties         September 2004
  
  
   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. [RFC3182] does not discuss this issue
   and therefore there is no particular requirement dealing with
   transmitting network-specific credentials back to the end-user's
   host.
  
   b) 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 and a guarantee of freshness for the
   receiving host. 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
   [RFC1510]).
  
   - 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 [RFC3182], the DIGITAL_SIGNATURE
   attribute must be the last attribute in the AUTH_DATA object, and
   the digital signature covers the entire AUTH_DATA object. Which hash
   algorithm and public key algorithm are used for the digital
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 20]
  

                       RSVP Security Properties         September 2004
  
  
   signature computation is described in [RFC2440] in the case of PGP.
   In the case of X.509 credentials the situation is more complex,
   because different mechanisms like CMS [RFC2630] or PKCS#7 [RFC2315]
   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 and PKCS#7. [RFC3182],
   however, does not make any statements about the usage of CMS and
   PKCS#7. Currently there is no support for CMS or PKCS#7 described in
   [RFC3182], 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 [RFC2440]), 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. Additionally, the large
   processing, memory, and bandwidth utilization should 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:
  
   a) 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 protection is based on the
      availability of the RSVP INTEGRITY object used with a security
      association that is established by other means.
  
   b) Including only the Kerberos session ticket is insufficient,
      because freshness is not provided (since 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).
  
   c) Replay Protection
  
   Figure 4 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
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 21]
  

                       RSVP Security Properties         September 2004
  
  
   the Client and the PDP indicates the protection provided by the
   AUTH_DATA element, which has no RSVP INTEGRITY object included.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 22]
  

                       RSVP Security Properties         September 2004
  
  
                           AUTH_DATA                      +----+
      +- - - - - - - - - - - - - - - - - - - - - - - - - -+PDP +-+
                                                          +----+ |
      |                                                          |
                                                                 |
      |                                                 COPS     |
                                                        INTEGRITY|
      |                                                          |
                                                                 |
      |                                                          |
   +--+---+   RSVP INTEGRITY  +----+    RSVP INTEGRITY    +----+ |
   |Client+-------------------+PEP1+----------------------+PEP2+-+
   +--+---+                   +----+                      +-+--+
      |                                                     |
      +-----------------------------------------------------+
                       POLICY_DATA INTEGRITY
  
                        Figure 4: 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 the
   Sequence Number field, sequence number rollover, and the Integrity
   Handshake have already been explained in Section 3.1.
  
   Section 9 of [RFC3182] 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 [PGP] and in [RFC2440]. 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 OpenPGP version [RFC2440] contains more information and
   describes the different hash algorithms (MD2, MD5, SHA-1, RIPEMD-
   160) supported. [RFC3182] 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.
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 23]
  

                       RSVP Security Properties         September 2004
  
  
   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 [RFC1510]. 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 [DG96].
  
   If the lifetime of the Kerberos ticket expires, then a new ticket
   must be requested and used. Rekeying is implemented with this
   procedure.
  
   d) (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). User identities
   should furthermore not be transmitted outside the domain of the
   visited network provider, i.e., the user identity information inside
   the policy data element should be removed or modified by the PDP to
   prevent revealing its contents to other (non-authorized) 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 user or application
   inside the POLICY_LOCATOR attribute of the AUTH_DATA element may be
   encrypted as specified in Section 3.3.1 of [RFC3182].  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
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 24]
  

                       RSVP Security Properties         September 2004
  
  
   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
   [RFC3182].
  
   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 [RFC1510] lists the supported
   algorithms. [Rae01] defines new encryption algorithms (Rijndael,
   Serpent, and Twofish).
  
   Evaluating user identity confidentiality requires also 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 and
   application specific information can leak after the messages leave
  
   Tschofenig, Graveman  Expires - March 2005                [Page 25]
  

                       RSVP Security Properties         September 2004
  
  
   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.
  
   e) 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, a LDAP server for a service level agreement stating 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 assume that the
   home domain knows the user and that the user is entitled to roam and
   to be able 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. [TB+03a] and [TB+03b] discuss
   authorization issues for QoS signaling protocols. Furthermore, a
   number of mobililty implications for policy handling in RSVP are
   described in [Tho02].
  
   f) 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 only needs
   to be sent once, because a performance optimization allows the
   session key to be cached as noted in Section 7.1 of [RFC2747]. It is
   assumed that subsequent RSVP messages only include the POLICY_DATA
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 26]
  

                       RSVP Security Properties         September 2004
  
  
   INTEGRITY object with a keyed message digest that uses the Kerberos
   session key. This, however, 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.
  
   When 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 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 [RFC2560] and the Simple
   Certificate Validation Protocol [MHHF01] are needed. Then the
   integrity of the AUTH_DATA object via the digital signature can be
   verified.
  
  4.4 Communication between RSVP-Aware Routers
  
   a) Authentication
  
   RSVP signaling messages are data origin authenticated and protected
   against modification and replay using the RSVP INTEGRITY object. The
   RSVP message flow between routers is protected based on the chain of
   trust and hence each router only needs to have 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 where 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.
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 27]
  

                       RSVP Security Properties         September 2004
  
  
   Independent of the key distribution mechanism, host authentication
   with RSVP built-in mechanisms is accomplished with the keyed message
   digest in the RSVP INTEGRITY object computed using the previously
   exchanged symmetric key.
  
   b) Integrity Protection
  
   Integrity protection is accomplished with the RSVP INTEGRITY object
   with the variable length Keyed Message Digest field.
  
   c) 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.
  
   d) Confidentiality
  
   Confidentiality is not provided by RSVP.
  
   e) 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.
  
   f) 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, i.e., 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.
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 28]
  

                       RSVP Security Properties         September 2004
  
  
  5. Miscellaneous Issues
  
   This section describes a number of issues that illustrate some of
   the shortcomings of RSVP with respect to security.
  
  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:
  
   - Does this network support RSVP signaling?
   - Which node supports RSVP signaling?
   - To which node is authentication required?
   - Which security mechanisms are used for authentication?
   - Which algorithms have to be used?
   - Where should the keys and security association come from?
   - 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 giving an answer to this question, 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 your next hop is important to be
   able to select the correct key for the RSVP Integrity object and to
   apply the proper protection. In case in which an RSVP node assumes
   it knows which node is the next hop the following protocol exchange
   can occur:
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 29]
  

                       RSVP Security Properties         September 2004
  
  
                                    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 5: Next-Hop Issue
  
   When RSVP node A in Figure 5 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, because of 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
   recognizing 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 5 describes a behavior that might help node A learn that an
   error occurred. However, the description of Section 4.2 of [RFC2747]
   describes 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.
  
   The RSVP Path message therefore provides a number of functions: path
   discovery, detecting route changes, learning of QoS capabilities
   along the path using the Adspec object, (with some interpretation)
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 30]
  

                       RSVP Security Properties         September 2004
  
  
   next-hop discovery, and possibly security association establishment
   (for example, in the case of Kerberos).
  
   From a security point of view there is a conflict between
  
   - 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 additionally
   a risk of introducing denial of service attacks.
  
   - RSVP Path message functionality and next-hop discovery
  
   To protect an RSVP signaling message (and a 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 a 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 a 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 an intra-domain case with a dense
   distribution of RSVP nodes this 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
  
   Tschofenig, Graveman  Expires - March 2005                [Page 31]
  

                       RSVP Security Properties         September 2004
  
  
   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:
  
   a) 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.
  
   b) Entity A then requests a ticket granting ticket for the network
   domain. This assumes that the identity of the network domain is
   known.
  
   c) Entity A then requests a service ticket for entity B, whose name
   was learned in step (a).
  
   d) 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.
  
   For last-hop communication this processing step 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 a application server). The access
   router might, however, in step (a) not be able to learn the user's
   principal name, because this information might not be available.
  
   Tschofenig, Graveman  Expires - March 2005                [Page 32]
  

                       RSVP Security Properties         September 2004
  
  
   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. IAKERB is however 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. IPsec-protected
   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. RFC 2207 considers these IPsec implications for
   RSVP and is based on three assumptions:
  
   a) An end host, which initiates the RSVP signaling message exchange,
   has to be able to retrieve the SPI for given flow. This requires
   some interaction with the IPsec security association database (SAD)
   and security policy database (SPD) [RFC2401]. 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 the
   SPI as an output parameter.
  
   b) RFC 2207 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 tunneling
   problem, but it is initiated by the end host. A figure better
   illustrates the problem in the case of enforcing secure network
   access:
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 33]
  

                       RSVP Security Properties         September 2004
  
  
   +------+          +---------------+      +--------+          +-----+
   | Host |          | Security      |      | Router |          | Host|
   |  A   |          | Gateway (SGW) |      |   Rx   |          |  B  |
   +--+---+          +-------+-------+      +----+---+          +--+--+
      |                      |                   |                 |
      |IPsec-Data(           |                   |                 |
      | OuterSrc=A,          |                   |                 |
      | OuterDst=SGW,        |                   |                 |
      | SPI=SPI1,            |                   |                 |
      | InnerSrc=A,          |                   |                 |
      | OuterDst=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 6: 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. With a nested application of IPsec (for
   example, IPsec between A and SGW and between A and B) the same
   problem occurs.
  
   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 [RFC2746].
  
   c) 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
  
   Tschofenig, Graveman  Expires - March 2005                [Page 34]
  

                       RSVP Security Properties         September 2004
  
  
   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 an 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. Some objects or mechanisms, however, could be
   used for end-to-end protection. The main question however is what
   the benefit of such an end-to-end security is. 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. Furthermore, te usefulness of end-to-end
   security depends on the architecture in which RSVP is deployed. If
   RSVP is only used 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 [GD+02], Localized RSVP [MS+02], 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 [RFC2401] 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., a 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.
  
   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 [RFC2205]. Some RSVP messages (Path, PathTear, and
   ResvConf) must have the Router Alert IP Option set in the IP header.
  
   Tschofenig, Graveman  Expires - March 2005                [Page 35]
  

                       RSVP Security Properties         September 2004
  
  
   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 [RFC2406] or AH
   [RFC2402] in transport mode--only IPsec in tunnel mode is possible.
  
   If there is more than one possible path an RSVP message can take,
   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
   allowing 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 [RFC2409], KINK [FH+01] or IKEv2 [IKEv2].
  
  5.7 Authorization
  
   [TB+03a] 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
   mechanism but authentication might in many cases be insufficient for
   authorization. The communication procedures defined for policy
   objects [Her95] 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.
  
   Tschofenig, Graveman  Expires - March 2005                [Page 36]
  

                       RSVP Security Properties         September 2004
  
  
   Additional information about expected behavior of policy handling in
   RSVP can also be obtained from [Her96].
  
   [TB+03b] and [Tho02] 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 number of
   complexity for mobility handling as described, for example, in
   [Tho02].
  
  6. Conclusions
  
   RSVP was the first QoS signaling protocol that provided some
   security protection. Whether RSVP provides enough security
   protection heavily depends on the environment where it is deployed.
   RSVP as specified today should be seen as a building block that has
   to be adapted to a given architecture.
  
   This document aims to provide more insights into the security of
   RSVP. It cannot not 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 [RFC2207]), multicast
   issues, and other security properties like traffic analysis.
   Additionally, the interaction with mobility protocols (micro- and
   macro-mobility) from a security point of view demands further
   investigation.
  
   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 put additional demands
   on the design of public key based authentication.
  
   The following list briefly summarizes a few security or
   architectural issues that deserve improvement:
  
   * Discovery and signaling message delivery should be separated.
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 37]
  

                       RSVP Security Properties         September 2004
  
  
   * 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.
  
   * Addressing for signaling messages should be done in a hop-by-hop
     fashion.
  
   * 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.
  
   * 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.
  
   * Public key authentication and user identity confidentiality
     provided with RSVP require some improvement.
  
   * Public key based user authentication only provides entity
     authentication. An additional security association is required to
     protect signaling messages.
  
   * 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.
  
   * Authorization and charging should be better integrated into the
     base protocol.
  
   * Selective message protection should be provided. A protected
     message should be recognizable from a flag in the header.
  
   * 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.
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 38]
  

                       RSVP Security Properties         September 2004
  
  
   * 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. IANA considerations
  
   This document does not address any IANA considerations.
  
  9. Acknowledgments
  
   We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu,
   Guenther Schaefer, Marc De Vuyst and Jukka Manner for their valuable
   comments. Additionally, we would like to thank Robert and Jorge for
   their time to discuss various issues with me.
  
   Finally we would Allison Mankin and John Loughney for their
   comments.
  
  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 ([Pat92]) 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
   including a pre-authentication data field. An unsuccessful
   authentication by the KDC results in an error message and the 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
   [TN+01] (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. [Wu99]
  
   Tschofenig, Graveman  Expires - March 2005                [Page 39]
  

                       RSVP Security Properties         September 2004
  
  
   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 seen as an
   example.
  
   Windows 2000, which integrates Kerberos into RSVP, uses a
   configuration with the user authentication to the PDP as described
   in [MADS01]. The steps for authenticating the user to the PDP in an
   intra-realm scenario are the following:
  
   - 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.
  
   - This ticket is then embedded into the AUTH_DATA element and
     included in either the PATH or the RESV message. In 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 [MADS01].
  
   - The RSVP message is then intercepted by the PEP, which forwards it
     to the PDP. [MADS01] does not state which protocol is used to
     forward the RSVP message to the PDP.
  
   - The PDP that finally receives the message decrypts the received
     service ticket. The ticket contains the session key used by the
     user's host to
  
     a) Encrypt the principal name inside the policy locator field of
        the AUTH_DATA object and to
     b) 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.
     c) The PDP does not maintain a user database, and [MADS01]
        describes how the PDP may query the Active Directory (a LDAP
        based directory service) for user policy information.
  
   Tschofenig, Graveman  Expires - March 2005                [Page 40]
  

                       RSVP Security Properties         September 2004
  
  
  
  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 [WW+99] 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
   intermediate RSVP routers (by examining the previously signed value)
   to detect a malicious RSVP node.
  
   A few issues are, however, left open in the document. Replay attacks
   are not covered, and it is therefore assumed that timestamp-based
   replay protection is used. To detect 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 [TN00], 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 [WW+99], 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 [TN+01], the approach
   presented in [TN00] is enhanced.
  
  10. Normative References
  
   [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
   Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 3182,
   October, 2001.
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 41]
  

                       RSVP Security Properties         September 2004
  
  
   [RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC
   2750, January, 2000.
  
   [RFC2747] Baker, F., Lindell, B., Talwar, M.: "RSVP Cryptographic
   Authentication", RC 2747, January, 2000.
  
   [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
   Sastry, A.: "The COPS(Common Open Policy Service) Protocol", RFC
   2748, January, 2000.
  
   [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
   Sastry, A.: "COPS usage for RSVP", RFC 2749, January, 2000.
  
   [RFC2207] Berger, L., O'Malley, T.: "RSVP Extensions for IPSEC Data
   Flows", RFC 2207, September 1997.
  
   [RFC1321] Rivest, R.: "The MD5 Message-Digest Algorithm", RFC 1321,
   April, 1992.
  
   [RFC1510] Kohl, J., Neuman, C.: "The Kerberos Network Authentication
   Service (V5)", RFC 1510, September 1993.
  
   [RFC2104] Krawczyk, H., Bellare, M., Canetti, R.: "HMAC: Keyed-
   Hashing for Message Authentication", RFC 2104, February, 1997.
  
   [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.:
   "Resource ReSerVation Protocol (RSVP) - Version 1 Functional
   Specification", RFC 2205, September 1997.
  
  11. Informative References
  
   [CA+02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G., Loughney, J.:
   "DIAMETER Base Protocol", <draft-ietf-aaa-diameter-17.txt>, (work in
   progress), December, 2002.
  
   [DBP96] Dobbertin, H., Bosselaers, A., Preneel, B.: "RIPEMD-160: A
   strengthened version of RIPEMD", in "Fast Software Encryption, LNCS
   Vol 1039, pp. 71-82", 1996.
  
   [DG96] Davis, D., Geer, D.: "Kerberos With Clocks Adrift: History,
   Protocols and Implementation", in "USENIX Computing Systems Volume 9
   no. 1, Winter", 1996.
  
   [Dob96] Dobbertin, H.: "The Status of Md5 After a Recent Attack,"
   RSA Laboratories' CryptoBytes, Volume 2, Number 2, 1996.
  
   [GD+02]  Gai, S., Dutt, D., Elfassy, N., Bernet, Y.: "RSVP Proxy",
   <draft-ietf-rsvp-proxy-03.txt>, (expired), March, 2002.
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 42]
  

                       RSVP Security Properties         September 2004
  
  
   [HA01] Hornstein, K., Altman, J.: "Distributing Kerberos KDC and
   Realm Information with DNS", <draft-ietf-krb-wg-krb-dns-locate-
   03.txt>, (expired), July, 2002.
  
   [HH01] Hess, R., Herzog, S.: "RSVP Extensions for Policy Control",
   <draft-ietf-rap-new-rsvp-ext-00.txt>, (expired), June, 2001.
  
   [Jab96] Jablon, D.: "Strong password-only authenticated key
   exchange", Computer Communication Review, 26(5), pp. 5-26, October,
   1996.
  
   [MADS01] "Microsoft Authorization Data Specification v. 1.0 for
   Microsoft Windows 2000 Operating Systems", April, 2000.
  
   [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
   Authentication Protocol (EAP)", RFC 2284, March 1998.
  
   [MHHF01] Malpani, A., Hoffman, P., Housley, R., Freeman, T.: "Simple
   Certificate Validation Protocol (SCVP)", <draft-ietf-pkix-scvp-
   11.txt>, (work in progress), December, 2002.
  
   [MS+02] Manner, J., Suihko, T., Kojo, M., Liljeberg, M.,
   Raatikainen, K.: "Localized RSVP", <draft-manner-lrsvp-00.txt>,
   (expired), May, 2002.
  
   [Pat92] Pato, J., "Using Pre-Authentication to Avoid Password
   Guessing Attacks", Open Software Foundation DCE Request for Comments
   26, December, 1992.
  
   [PGP] "Specifications and standard documents",
   http://www.pgpi.org/doc/specs/ (March, 2002).
  
   [PKTSEC] PacketCable Security Specification, PKT-SP-SEC-I01-991201,
   Cable Television Laboratories, Inc., December 1, 1999,
   http://www.PacketCable.com/ (June, 2003).
  
   [Rae01] Raeburn, K.: "Encryption and Checksum Specifications for
   Kerberos 5", <draft-ietf-krb-wg-crypto-05.txt>, (work in progress),
   June, 2003.
  
   [RFC2315] Kaliski, B.: "PKCS #7: Cryptographic Message Syntax
   Version 1.5", RFC 2315, March, 1998.
  
   [RFC2440] Callas, J.,  Donnerhacke, L., Finney, H., Thayer, R.:
   "OpenPGP Message Format", RFC 2440, November, 1998.
  
   [RFC2495] Housley, R., Ford, W., Polk, W., Solo, D.: "Internet X.509
   Public Key Infrastructure Certificate and CRL Profile", RFC 2459,
   January, 1999.
  
   Tschofenig, Graveman  Expires - March 2005                [Page 43]
  

                       RSVP Security Properties         September 2004
  
  
  
   [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams,
   C.: "X.509 Internet Public Key Infrastructure Online Certificate
   Status Protocol - OCSP", RFC 2560, June, 1999.
  
   [RFC2630] Housley, R.: "Cryptographic Message Syntax", RFC 2630,
   June, 1999.
  
   [RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.: "Remote
   Authentication Dial In User Service (RADIUS)", RFC 2865, June, 2000.
  
   [SHA] NIST, FIPS PUB 180-1, "Secure Hash Standard", April, 1995.
  
   [TN+01] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S.,
   Wray, J., Trostle, J.: "Public Key Cryptography for Initial
   Authentication in Kerberos", <draft-ietf-cat-kerberos-pk-init-
   16.txt>, (expired), October, 2001.
  
   [Wu99] Wu, T.: "A Real-World Analysis of Kerberos Password
   Security", in "Proceedings of the 1999 Network and Distributed
   System Security", February, 1999.
  
   [TB+03a] H. Tschofenig, M. Buechli, S. Van den Bosch, H.
   Schulzrinne: "NSIS Authentication, Authorization and Accounting
   Issues", <draft-tschofenig-nsis-aaa-issues-01.txt>, (work in
   progress), March, 2003.
  
   [TB+03b] H. Tschofenig, M. Buechli, S. Van den Bosch, H.
   Schulzrinne, T. Chen: "QoS NSLP Authorization Issues", <draft-
   tschofenig-nsis-qos-authz-issues-00.txt>, (work in progress), June,
   2003.
  
   [Her95] Herzog, S.: "Accounting and Access Control in RSVP", <draft-
   ietf-rsvp-lpm-arch-00.txt>, (expired), November, 1995.
  
   [Her96] S. Herzog: "Accounting and Access Control for Multicast
   Distributions: Models and Mechanisms", PhD Dissertation, University
   of Southern California, June 1996, available at:
   http://www.policyconsulting.com/publications/USC%20thesis.pdf,
   (June, 2003).
  
   [Tho02] M. Thomas: "Analysis of Mobile IP and RSVP Interactions",
   <draft-thomas-nsis-rsvp-analysis-00.txt>, (work in progress),
   October 2002.
  
   [FH+01] Thomas, M., Vilhuber, J.: "Kerberized Internet Negotiation
   of Keys (KINK)", <draft-ietf-kink-kink-05.txt>, (work in progress),
   January, 2003.
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 44]
  

                       RSVP Security Properties         September 2004
  
  
   [RFC2402]  Kent, S., Atkinson, R.: "IP Authentication Header", RFC
   2402, November, 1998.
  
   [RFC2406] Kent, S., Atkinson, R.: "IP Encapsulating Security Payload
   (ESP)", RFC 2406, November, 1998.
  
   [RFC2409] Harkins, D., Carrel, D.: "The Internet Key Exchange
   (IKE)", RFC 2409, November, 1998.
  
   [IKEv2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol",
   Internet Draft, <draft-ietf-ipsec-ikev2-08.txt>, (work in progress),
   June, 2003.
  
   [WW+99] Wu, T., Wu, F. and Gong, F.: "Securing QoS: Threats to RSVP
   Messages and Their Countermeasures", in "IEEE IWQoS, pp. 62-64,
   1999.
  
   [TN00] Talwar, V. and Nahrstedt, K.: "Securing RSVP For Multimedia
   Applications", in "Proceedings of ACM Multimedia (Multimedia
   Security Workshop)", Los Angeles, November, 2000.
  
   [TN+01] Talwar, V., Nath, S., Nahrstedt, K.: "RSVP-SQoS : A Secure
   RSVP Protocol", in "International Conference on Multimedia and
   Exposition", Tokyo , Japan,  August 2001.
  
  Author's Contact Information
  
   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   Email: Hannes.Tschofenig@siemens.com
  
   Richard Graveman
   RFG Security, LLC
   15 Park Avenue
   Morristown, NJ 07960 USA
   email: rfg@acm.org
  
  Intellectual Property Statement
  
   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.
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 45]
  

                       RSVP Security Properties         September 2004
  
  
   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.
  
  
  Disclaimer of Validity
  
   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.
  
  
  Copyright Statement
  
   Copyright (C) The Internet Society (2004).  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.
  
  
  Acknowledgment
  
   Funding for the RFC Editor function is currently provided by the
   Internet Society.
  
  
  
  
  
  
  
  
  
  
   Tschofenig, Graveman  Expires - March 2005                [Page 46]
  

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/