GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4230

Network Working Group H. Tschofenig Request for Comments: 4230 Siemens Category: Informational R. Graveman

                                                          RFG Security
                                                         December 2005
                      RSVP Security Properties

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document summarizes the security properties of RSVP.  The goal
 of this analysis is to benefit from previous work done on RSVP and to
 capture knowledge about past activities.

Tschofenig & Graveman Informational [Page 1] RFC 4230 RSVP Security Properties December 2005

Table of Contents

 1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.   Terminology and Architectural Assumptions  . . . . . . . . .   3
 3.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   5
      3.1.  The RSVP INTEGRITY Object  . . . . . . . . . . . . . .   5
      3.2.  Security Associations  . . . . . . . . . . . . . . . .   8
      3.3.  RSVP Key Management Assumptions  . . . . . . . . . . .   8
      3.4.  Identity Representation  . . . . . . . . . . . . . . .   9
      3.5.  RSVP Integrity Handshake   . . . . . . . . . . . . . .  13
 4.   Detailed Security Property Discussion  . . . . . . . . . . .  15
      4.1.  Network Topology   . . . . . . . . . . . . . . . . . .  15
      4.2.  Host/Router  . . . . . . . . . . . . . . . . . . . . .  15
      4.3.  User to PEP/PDP  . . . . . . . . . . . . . . . . . . .  19
      4.4.  Communication between RSVP-Aware Routers . . . . . . .  28
 5.   Miscellaneous Issues . . . . . . . . . . . . . . . . . . . .  29
      5.1.  First-Hop Issue  . . . . . . . . . . . . . . . . . . .  30
      5.2.  Next-Hop Problem . . . . . . . . . . . . . . . . . . .  30
      5.3.  Last-Hop Issue   . . . . . . . . . . . . . . . . . . .  33
      5.4.  RSVP- and IPsec-protected data traffic . . . . . . . .  34
      5.5.  End-to-End Security Issues and RSVP  . . . . . . . . .  36
      5.6.  IPsec protection of RSVP signaling messages  . . . . .  36
      5.7.  Authorization  . . . . . . . . . . . . . . . . . . . .  37
 6.   Conclusions  . . . . . . . . . . . . . . . . . . . . . . . .  38
 7.   Security Considerations  . . . . . . . . . . . . . . . . . .  40
 8.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  40
 9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  40
      9.1.  Normative References . . . . . . . . . . . . . . . . .  40
      9.2.  Informative References . . . . . . . . . . . . . . . .  41
 A.   Dictionary Attacks and Kerberos  . . . . . . . . . . . . . .  45
 B.   Example of User-to-PDP Authentication  . . . . . . . . . . .  45
 C.   Literature on RSVP Security  . . . . . . . . . . . . . . . .  46

Tschofenig & Graveman Informational [Page 2] RFC 4230 RSVP Security Properties December 2005

1. Introduction

 As the work of the NSIS working group began, concerns about security
 and its implications for the design of a signaling protocol were
 raised.  In order to understand the security properties and available
 options of RSVP, a number of documents have to be read.  This
 document summarizes the security properties of RSVP and is part of
 the overall process of analyzing other signaling protocols and
 learning from their design considerations.  This document should also
 provide a starting point for further discussions.
 The content of this document is organized as follows.  Section 2
 introduces the terminology used throughout the document.  Section 3
 provides an overview of the security mechanisms provided by RSVP
 including the INTEGRITY object, a description of the identity
 representation within the POLICY_DATA object (i.e., user
 authentication), and the RSVP Integrity Handshake mechanism.  Section
 4 provides a more detailed discussion of the mechanisms used and
 tries to describe in detail the mechanisms provided.  Several
 miscellaneous issues are covered in Section 5.
 RSVP also supports multicast, but this document does not address
 security aspects for supporting multicast QoS signaling.  Multicast
 is currently outside the scope of the NSIS working group.
 Although a variation of RSVP, namely RSVP-TE, is used in the context
 of MPLS to distribute labels for a label switched path, its usage is
 different from the usage scenarios envisioned for NSIS.  Hence, this
 document does not address RSVP-TE or its security properties.

2. Terminology and Architectural Assumptions

 This section describes some important terms and explains some
 architectural assumptions.
 o  Chain-of-Trust:
    The security mechanisms supported by RSVP [1] heavily rely on
    optional hop-by-hop protection, using the built-in INTEGRITY
    object.  Hop-by-hop security with the INTEGRITY object inside the
    RSVP message thereby refers to the protection between RSVP-
    supporting network elements.  Additionally, there is the notion of
    policy-aware nodes that understand the POLICY_DATA element within
    the RSVP message.  Because this element also includes an INTEGRITY
    object, there is an additional hop-by-hop security mechanism that
    provides security between policy-aware nodes.  Policy-ignorant
    nodes are not affected by the inclusion of this object in the
    POLICY_DATA element, because they do not try to interpret it.

Tschofenig & Graveman Informational [Page 3] RFC 4230 RSVP Security Properties December 2005

    To protect signaling messages that are possibly modified by each
    RSVP router along the path, it must be assumed that each incoming
    request is authenticated, integrity protected, and replay
    protected.  This provides protection against bogus messages
    injected by unauthorized nodes.  Furthermore, each RSVP-aware
    router is assumed to behave in the expected manner.  Outgoing
    messages transmitted to the next-hop network element receive new
    protection according to RSVP security processing.
    Using the mechanisms described above, a chain-of-trust is created
    whereby a signaling message that is transmitted by router A via
    router B and received by router C is supposed to be secure if
    routers A and B and routers B and C share security associations
    and all routers behave as expected.  Hence, router C trusts router
    A although router C does not have a direct security association
    with router A.  We can therefore conclude that the protection
    achieved with this hop-by-hop security for the chain-of-trust is
    no better than the weakest link in the chain.
    If one router is malicious (for example, because an adversary has
    control over this router), then it can arbitrarily modify
    messages, cause unexpected behavior, and mount a number of attacks
    that are not limited to QoS signaling.  Additionally, it must be
    mentioned that some protocols demand more protection than others
    (which depends, in part, on which nodes are executing these
    protocols).  For example, edge devices, where end-users are
    attached, may be more likely to be attacked in comparison with the
    more secure core network of a service provider.  In some cases, a
    network service provider may choose not to use the RSVP-provided
    security mechanisms inside the core network because a different
    security protection is deployed.
    Section 6 of [2] mentions the term chain-of-trust in the context
    of RSVP integrity protection.  In Section 6 of [14] the same term
    is used in the context of user authentication with the INTEGRITY
    object inside the POLICY_DATA element.  Unfortunately, the term is
    not explained in detail and the assumptions behind it are not
    clearly specified.
 o  Host and User Authentication:
    The presence of RSVP protection and a separate user identity
    representation leads to the fact that both user-identity and host-
    identity are used for RSVP protection.  Therefore, user-based
    security and host-based security are covered separately, because
    of the different authentication mechanisms provided.  To avoid
    confusion about the different concepts, Section 3.4 describes the
    concept of user authentication in more detail.

Tschofenig & Graveman Informational [Page 4] RFC 4230 RSVP Security Properties December 2005

 o  Key Management:
    It is assumed that most of the security associations required for
    the protection of RSVP signaling messages are already available,
    and hence key management was done in advance.  There is, however,
    an exception with respect to support for Kerberos.  Using
    Kerberos, an entity is able to distribute a session key used for
    RSVP signaling protection.
 o  RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
    RSVP uses an INTEGRITY object in two places in a message.  The
    first is in the RSVP message itself and covers the entire RSVP
    message as defined in [1].  The second is included in the
    POLICY_DATA object and defined in [2].  To differentiate the two
    objects by their scope of protection, the two terms RSVP INTEGRITY
    and POLICY_DATA INTEGRITY object are used, respectively.  The data
    structure of the two objects, however, is the same.
 o  Hop versus Peer:
    In the past, the terminology for nodes addressed by RSVP has been
    discussed considerably.  In particular, two favorite terms have
    been used: hop and peer.  This document uses the term hop, which
    is different from an IP hop.  Two neighboring RSVP nodes
    communicating with each other are not necessarily neighboring IP
    nodes (i.e., they may be more than one IP hop away).

3. Overview

 This section describes the security mechanisms provided by RSVP.
 Although use of IPsec is mentioned in Section 10 of [1], the other
 security mechanisms primarily envisioned for RSVP are described.

3.1. The RSVP INTEGRITY Object

 The RSVP INTEGRITY object is the major component of RSVP security
 protection.  This object is used to provide integrity and replay
 protection for the content of the signaling message between two RSVP
 participating routers or between an RSVP router and host.
 Furthermore, the RSVP INTEGRITY object provides data origin
 authentication.  The attributes of the object are briefly described:
 o  Flags field:
     The Handshake Flag is the only defined flag.  It is used to
     synchronize sequence numbers if the communication gets out of
     sync (e.g., it allows a restarting host to recover the most

Tschofenig & Graveman Informational [Page 5] RFC 4230 RSVP Security Properties December 2005

     recent sequence number).  Setting this flag to one indicates that
     the sender is willing to respond to an Integrity Challenge
     message.  This flag can therefore be seen as a negotiation
     capability transmitted within each INTEGRITY object.
 o  Key Identifier:
     The Key Identifier selects the key used for verification of the
     Keyed Message Digest field and, hence, must be unique for the
     sender.  It has a fixed 48-bit length.  The generation of this
     Key Identifier field is mostly a decision of the local host. [1]
     describes this field as a combination of an address, sending
     interface, and key number.  We assume that the Key Identifier is
     simply a (keyed) hash value computed over a number of fields,
     with the requirement to be unique if more than one security
     association is used in parallel between two hosts (e.g., as is
     the case with security associations having overlapping
     lifetimes).  A receiving system uniquely identifies a security
     association based on the Key Identifier and the sender's IP
     address.  The sender's IP address may be obtained from the
     RSVP_HOP object or from the source IP address of the packet if
     the RSVP_HOP object is not present.  The sender uses the outgoing
     interface to determine which security association to use.  The
     term "outgoing interface" may be confusing.  The sender selects
     the security association based on the receiver's IP address
     (i.e., the address of the next RSVP-capable router).  The process
     of determining which node is the next RSVP-capable router is not
     further specified and is likely to be statically configured.
 o  Sequence Number:
     The sequence number used by the INTEGRITY object is 64 bits in
     length, and the starting value can be selected arbitrarily.  The
     length of the sequence number field was chosen to avoid
     exhaustion during the lifetime of a security association as
     stated in Section 3 of [1].  In order for the receiver to
     distinguish between a new and a replayed message, the sequence
     number must be monotonically incremented (modulo 2^64) for each
     message.  We assume that the first sequence number seen (i.e.,
     the starting sequence number) is stored somewhere.  The modulo-
     operation is required because the starting sequence number may be
     an arbitrary number.  The receiver therefore only accepts packets
     with a sequence number larger (modulo 2^64) than the previous
     packet.  As explained in [1] this process is started by
     handshaking and agreeing on an initial sequence number.  If no
     such handshaking is available then the initial sequence number
     must be part of the establishment of the security association.

Tschofenig & Graveman Informational [Page 6] RFC 4230 RSVP Security Properties December 2005

     The generation and storage of sequence numbers is an important
     step in preventing replay attacks and is largely determined by
     the capabilities of the system in the presence of system crashes,
     failures, and restarts.  Section 3 of [1] explains some of the
     most important considerations.  However, the description of how
     the receiver distinguishes proper from improper sequence numbers
     is incomplete: it implicitly assumes that gaps large enough to
     cause the sequence number to wrap around cannot occur.
     If delivery in order were guaranteed, the following procedure
     would work: the receiver keeps track of the first sequence number
     received, INIT-SEQ, and the most recent sequence number received,
     LAST-SEQ, for each key identifier in a security association.
     When the first message is received, set INIT-SEQ = LAST-SEQ =
     value received and accept.  When a subsequent message is
     received, if its sequence number is strictly between LAST-SEQ and
     INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the
     value just received.  If it is between INIT-SEQ and LAST-SEQ,
     inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ
     unchanged.  Because delivery in order is not guaranteed, the
     above rules need to be combined with a method of allowing a fixed
     sized window in the neighborhood of LAST-SEQ for out-of-order
     delivery, for example, as described in Appendix C of [3].
 o  Keyed Message Digest:
     The Keyed Message Digest is a security mechanism built into RSVP
     that used to provide integrity protection of a signaling message
     (including its sequence number).  Prior to computing the value
     for the Keyed Message Digest field, the Keyed Message Digest
     field itself must be set to zero and a keyed hash computed over
     the entire RSVP packet.  The Keyed Message Digest field is
     variable in length but must be a multiple of four octets.  If
     HMAC-MD5 is used, then the output value is 16 bytes long.  The
     keyed hash function HMAC-MD5 [4] is required for an RSVP
     implementation, as noted in Section 1 of [1].  Hash algorithms
     other than MD5 [5], like SHA-1 [15], may also be supported.
     The key used for computing this Keyed Message Digest may be
     obtained from the pre-shared secret, which is either manually
     distributed or the result of a key management protocol.  No key
     management protocol, however, is specified to create the desired
     security associations.  Also, no guidelines for key length are
     given.  It should be recommended that HMAC-MD5 keys be 128 bits
     and SHA-1 keys 160 bits, as in IPsec AH [16] and ESP [17].

Tschofenig & Graveman Informational [Page 7] RFC 4230 RSVP Security Properties December 2005

3.2. Security Associations

 Different attributes are stored for security associations of sending
 and receiving systems (i.e., unidirectional security associations).
 The sending system needs to maintain the following attributes in such
 a security association [1]:
    o  Authentication algorithm and algorithm mode
    o  Key
    o  Key Lifetime
    o  Sending Interface
    o  Latest sequence number (received with this key identifier)
 The receiving system has to store the following fields:
    o  Authentication algorithm and algorithm mode
    o  Key
    o  Key Lifetime
    o  Source address of the sending system
    o  List of last n sequence numbers (received with this key
       identifier)
 Note that the security associations need to have additional fields to
 indicate their state.  It is necessary to have overlapping lifetimes
 of security associations to avoid interrupting an ongoing
 communication because of expired security associations.  During such
 a period of overlapping lifetime it is necessary to authenticate with
 either one or both active keys.  As mentioned in [1], a sender and a
 receiver may have multiple active keys simultaneously.  If more than
 one algorithm is supported, then the algorithm used must be specified
 for a security association.

3.3. RSVP Key Management Assumptions

 RFC 2205 [6] assumes that security associations are already
 available.  An implementation must support manual key distribution as
 noted in Section 5.2 of [1].  Manual key distribution, however, has
 different requirements for key storage; a simple plaintext ASCII file
 may be sufficient in some cases.  If multiple security associations
 with different lifetimes need to be supported at the same time, then

Tschofenig & Graveman Informational [Page 8] RFC 4230 RSVP Security Properties December 2005

 a key engine would be more appropriate.  Further security
 requirements listed in Section 5.2 of [1] are the following:
 o  The manual deletion of security associations must be supported.
 o  The key storage should persist during a system restart.
 o  Each key must be assigned a specific lifetime and a specific Key
    Identifier.

3.4. Identity Representation

 In addition to host-based authentication with the INTEGRITY object
 inside the RSVP message, user-based authentication is available as
 introduced in [2].  Section 2 of [7] states that "Providing policy
 based admission control mechanism based on user identities or
 application is one of the prime requirements."  To identify the user
 or the application, a policy element called AUTH_DATA, which is
 contained in the POLICY_DATA object, is created by the RSVP daemon at
 the user's host and transmitted inside the RSVP message.  The
 structure of the POLICY_DATA element is described in [2].  Network
 nodes acting as policy decision points (PDPs) then use the
 information contained in the AUTH_DATA element to authenticate the
 user and to allow policy-based admission control to be executed.  As
 mentioned in [7], the policy element is processed and the PDP
 replaces the old element with a new one for forwarding to the next
 hop router.
 A detailed description of the POLICY_DATA element can be found in
 [2].  The attributes contained in the authentication data policy
 element AUTH_DATA, which is defined in [7], are briefly explained in
 this Section.  Figure 1 shows the abstract structure of the RSVP
 message with its security-relevant objects and the scope of
 protection.  The RSVP INTEGRITY object (outer object) covers the
 entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
 covers objects within the POLICY_DATA element.

Tschofenig & Graveman Informational [Page 9] RFC 4230 RSVP Security Properties December 2005

 +--------------------------------------------------------+
 | RSVP Message                                           |
 +--------------------------------------------------------+
 | Object    |POLICY_DATA Object                         ||
 |           +-------------------------------------------+|
 |           | INTEGRITY +------------------------------+||
 |           | Object    | AUTH_DATA Object             |||
 |           |           +------------------------------+||
 |           |           | Various Authentication       |||
 |           |           | Attributes                   |||
 |           |           +------------------------------+||
 |           +-------------------------------------------+|
 +--------------------------------------------------------+
             Figure 1: Security Relevant Objects and Elements
                       within the RSVP Message.
 The AUTH_DATA object contains information for identifying users and
 applications together with credentials for those identities.  The
 main purpose of these identities seems to be usage for policy-based
 admission control and not authentication and key management.  As
 noted in Section 6.1 of [7], an RSVP message may contain more than
 one POLICY_DATA object and each of them may contain more than one
 AUTH_DATA object.  As indicated in Figure 1 and in [7], one AUTH_DATA
 object may contain more than one authentication attribute.  A typical
 configuration for Kerberos-based user authentication includes at
 least the Policy Locator and an attribute containing the Kerberos
 session ticket.
 Successful user authentication is the basis for executing policy-
 based admission control.  Additionally, other information such as
 time-of-day, application type, location information, group
 membership, etc. may be relevant to the implementation of an access
 control policy.
 The following attributes are defined for use in the AUTH_DATA object:
    o  Policy Locator
  • ASCII_DN
  • UNICODE_DN
  • ASCII_DN_ENCRYPT
  • UNICODE_DN_ENCRYPT

Tschofenig & Graveman Informational [Page 10] RFC 4230 RSVP Security Properties December 2005

       The policy locator string is an X.500 distinguished name (DN)
       used to locate user or application-specific policy information.
       The four types of X.500 DNs are listed above.  The first two
       types are the ASCII and the Unicode representation of the user
       or application DN identity.  The two "encrypted" distinguished
       name types are either encrypted with the Kerberos session key
       or with the private key of the user's digital certificate
       (i.e., digitally signed).  The term "encrypted together with a
       digital signature" is easy to misconceive.  If user identity
       confidentiality is provided, then the policy locator has to be
       encrypted with the public key of the recipient.  How to obtain
       this public key is not described in the document.  This detail
       may be specified in a concrete architecture in which RSVP is
       used.
    o  Credentials
       Two cryptographic credentials are currently defined for a user:
       authentication with Kerberos V5 [8], and authentication with
       the help of digital signatures based on X.509 [18] and PGP
       [19].  The following list contains all defined credential types
       currently available and defined in [7]:
       +--------------+--------------------------------+
       | Credential   |  Description                   |
       |    Type      |                                |
       +===============================================|
       | ASCII_ID     |  User or application identity  |
       |              |  encoded as an ASCII string    |
       +--------------+--------------------------------+
       | UNICODE_ID   |  User or application identity  |
       |              |  encoded as a Unicode string   |
       +--------------+--------------------------------+
       | KERBEROS_TKT |  Kerberos V5 session ticket    |
       +--------------+--------------------------------+
       | X509_V3_CERT |  X.509 V3 certificate          |
       +--------------+--------------------------------+
       | PGP_CERT     |  PGP certificate               |
       +--------------+--------------------------------+
                  Figure 2: Credentials Supported in RSVP.
       The first two credentials contain only a plaintext string, and
       therefore they do not provide cryptographic user
       authentication.  These plaintext strings may be used to
       identify applications, that are included for policy-based
       admission control.  Note that these plain-text identifiers may,
       however, be protected if either the RSVP INTEGRITY or the

Tschofenig & Graveman Informational [Page 11] RFC 4230 RSVP Security Properties December 2005

       INTEGRITY object of the POLICY_DATA element is present.  Note
       that the two INTEGRITY objects can terminate at different
       entities depending on the network structure.  The digital
       signature may also provide protection of application
       identifiers.  A protected application identity (and the entire
       content of the POLICY_DATA element) cannot be modified as long
       as no policy-ignorant nodes are encountered in between.
       A Kerberos session ticket, as previously mentioned, is the
       ticket of a Kerberos AP_REQ message [8] without the
       Authenticator.  Normally, the AP_REQ message is used by a
       client to authenticate to a server.  The INTEGRITY object
       (e.g., of the POLICY_DATA element) provides the functionality
       of the Kerberos Authenticator, namely protecting against replay
       and showing that the user was able to retrieve the session key
       following the Kerberos protocol.  This is, however, only the
       case if the Kerberos session was used for the keyed message
       digest field of the INTEGRITY object.  Section 7 of [1]
       discusses some issues for establishment of keys for the
       INTEGRITY object.  The establishment of the security
       association for the RSVP INTEGRITY object with the inclusion of
       the Kerberos Ticket within the AUTH_DATA element may be
       complicated by the fact that the ticket can be decrypted by
       node B, whereas the RSVP INTEGRITY object terminates at a
       different host C.
       The Kerberos session ticket contains, among many other fields,
       the session key.  The Policy Locator may also be encrypted with
       the same session key.  The protocol steps that need to be
       executed to obtain such a Kerberos service ticket are not
       described in [7] and may involve several roundtrips, depending
       on many Kerberos-related factors.  As an optimization, the
       Kerberos ticket does not need to be included in every RSVP
       message, as described in Section 7.1 of [1].  Thus, the
       receiver must store the received service ticket.  If the
       lifetime of the ticket has expired, then a new service ticket
       must be sent.  If the receiver lost its state information
       (because of a crash or restart) then it may transmit an
       Integrity Challenge message to force the sender to re-transmit
       a new service ticket.
       If either the X.509 V3 or the PGP certificate is included in
       the policy element, then a digital signature must be added.
       The digital signature computed over the entire AUTH_DATA object
       provides authentication and integrity protection.  The SubType
       of the digital signature authentication attribute is set to
       zero before computing the digital signature.  Whether or not a
       guarantee of freshness with replay protection (either

Tschofenig & Graveman Informational [Page 12] RFC 4230 RSVP Security Properties December 2005

       timestamps or sequence numbers) is provided by the digital
       signature is an open issue as discussed in Section 4.3.
    o  Digital Signature
       The digital signature computed over the contents of the
       AUTH_DATA object must be the last attribute.  The algorithm
       used to compute the digital signature depends on the
       authentication mode listed in the credential.  This is only
       partially true, because, for example, PGP again allows
       different algorithms to be used for computing a digital
       signature.  The algorithm identifier used for computing the
       digital signature is not included in the certificate itself.
       The algorithm identifier included in the certificate only
       serves the purpose of allowing the verification of the
       signature computed by the certificate authority (except for the
       case of self-signed certificates).
    o  Policy Error Object
       The Policy Error Object is used in the case of a failure of
       policy-based admission control or other credential
       verification.  Currently available error messages allow
       notification if the credentials are expired
       (EXPIRED_CREDENTIALS), if the authorization process disallowed
       the resource request (INSUFFICIENT_PRIVILEGES), or if the given
       set of credentials is not supported
       (UNSUPPORTED_CREDENTIAL_TYPE).  The last error message returned
       by the network allows the user's host to discover the type of
       credentials supported.  Particularly for mobile environments
       this might be quite inefficient.  Furthermore, it is unlikely
       that a user supports different types of credentials.  The
       purpose of the error message IDENTITY_CHANGED is unclear.
       Also, the protection of the error message is not discussed in
       [7].

3.5. RSVP Integrity Handshake

 The Integrity Handshake protocol was designed to allow a crashed or
 restarted host to obtain the latest valid challenge value stored at
 the receiving host.  Due to the absence of key management, it must be
 guaranteed that two messages do not use the same sequence number with
 the same key.  A host stores the latest sequence number of a
 cryptographically verified message.  An adversary can replay
 eavesdropped packets if the crashed host has lost its sequence
 numbers.  A signaling message from the real sender with a new
 sequence number would therefore allow the crashed host to update the
 sequence number field and prevent further replays.  Hence, if there

Tschofenig & Graveman Informational [Page 13] RFC 4230 RSVP Security Properties December 2005

 is a steady flow of RSVP-protected messages between the two hosts, an
 attacker may find it difficult to inject old messages, because new,
 authenticated messages with higher sequence numbers arrive and get
 stored immediately.
 The following description explains the details of an RSVP Integrity
 Handshake that is started by Node A after recovering from a
 synchronization failure:
                   Integrity Challenge
                (1) Message (including
  +----------+      a Cookie)            +----------+
  |          |-------------------------->|          |
  |  Node A  |                           |  Node B  |
  |          |<--------------------------|          |
  +----------+      Integrity Response   +----------+
                (2) Message (including
                    the Cookie and the
                    INTEGRITY object)
                  Figure 3: RSVP Integrity Handshake.
 The details of the messages are as follows:
    CHALLENGE:=(Key Identifier, Challenge Cookie)
    Integrity Challenge Message:=(Common Header, CHALLENGE)
    Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
 The "Challenge Cookie" is suggested to be a MD5 hash of a local
 secret and a timestamp [1].
 The Integrity Challenge message is not protected with an INTEGRITY
 object as shown in the protocol flow above.  As explained in Section
 10 of [1] this was done to avoid problems in situations where both
 communicating parties do not have a valid starting sequence number.
 Using the RSVP Integrity Handshake protocol is recommended although
 it is not mandatory (because it may not be needed in all network
 environments).

Tschofenig & Graveman Informational [Page 14] RFC 4230 RSVP Security Properties December 2005

4. Detailed Security Property Discussion

 This section describes the protection of the RSVP-provided mechanisms
 for authentication, authorization, integrity and replay protection
 individually, user identity confidentiality, and confidentiality of
 the signaling messages,

4.1. Network Topology

 This paragraph shows the basic interfaces in a simple RSVP network
 architecture.  The architecture below assumes that there is only a
 single domain and that the two routers are RSVP- and policy-aware.
 These assumptions are relaxed in the individual paragraphs, as
 necessary.  Layer 2 devices between the clients and their
 corresponding first-hop routers are not shown.  Other network
 elements like a Kerberos Key Distribution Center and, for example, an
 LDAP server from which the PDP retrieves its policies are also
 omitted.  The security of various interfaces to the individual
 servers (KDC, PDP, etc.) depends very much on the security policy of
 a specific network service provider.
                          +--------+
                          | Policy |
                     +----|Decision|
                     |    | Point  +---+
                     |    +--------+   |
                     |                 |
                     |                 |
   +------+       +-+----+        +---+--+          +------+
   |Client|       |Router|        |Router|          |Client|
   |  A   +-------+  1   +--------+  2   +----------+  B   |
   +------+       +------+        +------+          +------+
                   Figure 4: Simple RSVP Architecture.

4.2. Host/Router

 When considering authentication in RSVP, it is important to make a
 distinction between user and host authentication of the signaling
 messages.  The host is authenticated using the RSVP INTEGRITY object,
 whereas credentials inside the AUTH_DATA object can be used to
 authenticate the user.  In this section, the focus is on host
 authentication, whereas the next section covers user authentication.
 (1) Authentication
     The term "host authentication" is used above, because the
     selection of the security association is bound to the host's IP

Tschofenig & Graveman Informational [Page 15] RFC 4230 RSVP Security Properties December 2005

     address, as mentioned in Section 3.1 and Section 3.2.  Depending
     on the key management protocol used to create this security
     association and the identity used, it is also possible to bind a
     user identity to this security association.  Because the key
     management protocol is not specified, it is difficult to evaluate
     this part, and hence we speak about data-origin authentication
     based on the host's identity for RSVP INTEGRITY objects.  The
     fact that the host identity is used for selecting the security
     association has already been described in Section 3.1.
     Data-origin authentication is provided with a keyed hash value
     computed over the entire RSVP message, excluding the keyed
     message digest field itself.  The security association used
     between the user's host and the first-hop router is, as
     previously mentioned, not established by RSVP, and it must
     therefore be available before signaling is started.
  • Kerberos for the RSVP INTEGRITY object
        As described in Section 7 of [1], Kerberos may be used to
        create the key for the RSVP INTEGRITY object.  How to learn
        the principal name (and realm information) of the other node
        is outside the scope of [1]. [20] describes a way to
        distribute principal and realm information via DNS, which can
        be used for this purpose (assuming that the FQDN or the IP
        address of the other node for which this information is
        desired is known).  All that is required is to encapsulate the
        Kerberos ticket inside the policy element.  It is furthermore
        mentioned that Kerberos tickets with expired lifetime must not
        be used, and the initiator is responsible for requesting and
        exchanging a new service ticket before expiration.
        RSVP multicast processing in combination with Kerberos
        involves additional considerations.  Section 7 of [1] states
        that in the multicast case all receivers must share a single
        key with the Kerberos Authentication Server (i.e., a single
        principal used for all receivers).  From a personal discussion
        with Rodney Hess, it seems that there is currently no other
        solution available in the context of Kerberos.  Multicast
        handling therefore leaves some open questions in this context.
        In the case where one entity crashed, the established security
        association is lost and therefore the other node must
        retransmit the service ticket.  The crashed entity can use an
        Integrity Challenge message to request a new Kerberos ticket
        to be retransmitted by the other node.  If a node receives
        such a request, then a reply message must be returned.

Tschofenig & Graveman Informational [Page 16] RFC 4230 RSVP Security Properties December 2005

 (2) Integrity protection
     Integrity protection between the user's host and the first-hop
     router is based on the RSVP INTEGRITY object.  HMAC-MD5 is
     preferred, although other keyed hash functions may also be used
     within the RSVP INTEGRITY object.  In any case, both
     communicating entities must have a security association that
     indicates the algorithm to use.  This may, however, be difficult,
     because no negotiation protocol is defined to agree on a specific
     algorithm.  Hence, if RSVP is used in a mobile environment, it is
     likely that HMAC-MD5 is the only usable algorithm for the RSVP
     INTEGRITY object.  Only in local environments may it be useful to
     switch to a different keyed hash algorithm.  The other possible
     alternative is that every implementation support the most
     important keyed hash algorithms. e.g., MD5, SHA-1, RIPEMD-160,
     etc.  HMAC-MD5 was chosen mainly because of its performance
     characteristics.  The weaknesses of MD5 [21] are known and were
     initially described in [22].  Other algorithms like SHA-1 [15]
     and RIPEMD-160 [21] have stronger security properties.
 (3) Replay Protection
     The main mechanism used for replay protection in RSVP is based on
     sequence numbers, whereby the sequence number is included in the
     RSVP INTEGRITY object.  The properties of this sequence number
     mechanism are described in Section 3.1 of [1].  The fact that the
     receiver stores a list of sequence numbers is an indicator for a
     window mechanism.  This somehow conflicts with the requirement
     that the receiver only has to store the highest number given in
     Section 3 of [1].  We assume that this is an oversight.  Section
     4.2 of [1] gives a few comments about the out-of-order delivery
     and the ability of an implementation to specify the replay
     window.  Appendix C of [3] describes a window mechanism for
     handling out-of-sequence delivery.
 (4) Integrity Handshake
     The mechanism of the Integrity Handshake is explained in Section
     3.5.  The Cookie value is suggested to be a hash of a local
     secret and a timestamp.  The Cookie value is not verified by the
     receiver.  The mechanism used by the Integrity Handshake is a
     simple Challenge/Response message, which assumes that the key
     shared between the two hosts survives the crash.  If, however,
     the security association is dynamically created, then this
     assumption may not be true.

Tschofenig & Graveman Informational [Page 17] RFC 4230 RSVP Security Properties December 2005

     In Section 10 of [1], the authors note that an adversary can
     create a faked Integrity Handshake message that includes
     challenge cookies.  Subsequently, it could store the received
     response and later try to replay these responses while a
     responder recovers from a crash or restart.  If this replayed
     Integrity Response value is valid and has a lower sequence number
     than actually used, then this value is stored at the recovering
     host.  In order for this attack to be successful, the adversary
     must either have collected a large number of challenge/response
     value pairs or have "discovered" the cookie generation mechanism
     (for example by knowing the local secret).  The collection of
     Challenge/Response pairs is even more difficult, because they
     depend on the Cookie value, the sequence number included in the
     response message, and the shared key used by the INTEGRITY
     object.
 (5) Confidentiality
     Confidentiality is not considered to be a security requirement
     for RSVP.  Hence, it is not supported by RSVP, except as
     described in paragraph d) of Section 4.3.  This assumption may
     not hold, however, for enterprises or carriers who want to
     protect billing data, network usage patterns, or network
     configurations, in addition to users' identities, from
     eavesdropping and traffic analysis.  Confidentiality may also
     help make certain other attacks more difficult.  For example, the
     PathErr attack described in Section 5.2 is harder to carry out if
     the attacker cannot observe the Path message to which the PathErr
     corresponds.
 (6) Authorization
     The task of authorization consists of two subcategories: network
     access authorization and RSVP request authorization.  Access
     authorization is provided when a node is authenticated to the
     network, e.g., using EAP [23] in combination with AAA protocols
     (for example, RADIUS [24] or DIAMETER [9]).  Issues related to
     network access authentication and authorization are outside the
     scope of RSVP.
     The second authorization refers to RSVP itself.  Depending on the
     network configuration:
  • the router either forwards the received RSVP request to the

policy decision point (e.g., using COPS [10] and [11]) to

        request that an admission control procedure be executed, or

Tschofenig & Graveman Informational [Page 18] RFC 4230 RSVP Security Properties December 2005

  • the router supports the functionality of a PDP and, therefore,

there is no need to forward the request, or

  • the router may already be configured with the appropriate

policy information to decide locally whether to grant this

        request.
     Based on the result of the admission control, the request may be
     granted or rejected.  Information about the resource-requesting
     entity must be available to provide policy-based admission
     control.
 (7) Performance
     The computation of the keyed message digest for an RSVP INTEGRITY
     object does not represent a performance problem.  The protection
     of signaling messages is usually not a problem, because these
     messages are transmitted at a low rate.  Even a high volume of
     messages does not cause performance problems for an RSVP router
     due to the efficiency of the keyed message digest routine.
     Dynamic key management, which is computationally more demanding,
     is more important for scalability.  Because RSVP does not specify
     a particular key exchange protocol, it is difficult to estimate
     the effort needed to create the required security associations.
     Furthermore, the number of key exchanges to be triggered depends
     on security policy issues like lifetime of a security
     association, required security properties of the key exchange
     protocol, authentication mode used by the key exchange protocol,
     etc.  In a stationary environment with a single administrative
     domain, manual security association establishment may be
     acceptable and may provide the best performance characteristics.
     In a mobile environment, asymmetric authentication methods are
     likely to be used with a key exchange protocol, and some sort of
     public key or certificate verification needs to be supported.

4.3. User to PEP/PDP

 As noted in the previous section, RSVP supports both user-based and
 host-based authentication.  Using RSVP, a user may authenticate to
 the first hop router or to the PDP as specified in [1], depending on
 the infrastructure provided by the network domain or the architecture
 used (e.g., the integration of RSVP and Kerberos V5 into the Windows
 2000 Operating System [25]).  Another architecture in which RSVP is
 tightly integrated is the one specified by the PacketCable
 organization.  The interested reader is referred to [26] for a
 discussion of their security architecture.

Tschofenig & Graveman Informational [Page 19] RFC 4230 RSVP Security Properties December 2005

 (1) Authentication
     When a user sends an RSVP PATH or RESV message, this message may
     include some information to authenticate the user. [7] describes
     how user and application information is embedded into the RSVP
     message (AUTH_DATA object) and how to protect it.  A router
     receiving such a message can use this information to authenticate
     the client and forward the user or application information to the
     policy decision point (PDP).  Optionally, the PDP itself can
     authenticate the user, which is described in the next section.
     To be able to authenticate the user, to verify the integrity, and
     to check for replays, the entire POLICY_DATA element has to be
     forwarded from the router to the PDP (e.g., by including the
     element into a COPS message).  It is assumed, although not
     clearly specified in [7], that the INTEGRITY object within the
     POLICY_DATA element is sent to the PDP along with all other
     attributes.
  • Certificate Verification
        Using the policy element as described in [7], it is not
        possible to provide a certificate revocation list or other
        information to prove the validity of the certificate inside
        the policy element.  A specific mechanism for certificate
        verification is not discussed in [7] and hence a number of
        them can be used for this purpose.  For certificate
        verification, the network element (a router or the policy
        decision point) that has to authenticate the user could
        frequently download certificate revocation lists or use a
        protocol like the Online Certificate Status Protocol (OCSP)
        [27] and the Simple Certificate Validation Protocol (SCVP)
        [28] to determine the current status of a digital certificate.
  • User Authentication to the PDP
        This alternative authentication procedure uses the PDP to
        authenticate the user instead of the first-hop router.  In
        Section 4.2.1 of [7], the choice is given for the user to
        obtain a session ticket either for the next hop router or for
        the PDP.  As noted in the same section, the identity of the
        PDP or the next hop router is statically configured or
        dynamically retrieved.  Subsequently, user authentication to
        the PDP is considered.
  • Kerberos-based Authentication to the PDP
        If Kerberos is used to authenticate the user, then a session
        ticket for the PDP must be requested first.  A user who roams

Tschofenig & Graveman Informational [Page 20] RFC 4230 RSVP Security Properties December 2005

        between different routers in the same administrative domain
        does not need to request a new service ticket, because the
        same PDP is likely to be used by most or all first-hop routers
        within the same administrative domain.  This is different from
        the case in which a session ticket for a router has to be
        obtained and authentication to a router is required.  The
        router therefore plays a passive role of simply forwarding the
        request to the PDP and executing the policy decision returned
        by the PDP.  Appendix B describes one example of user-to-PDP
        authentication.
        User authentication with the policy element provides only
        unilateral authentication, whereby the client authenticates to
        the router or to the PDP.  If an RSVP message is sent to the
        user's host and public-key-based authentication is not used,
        then the message does not contain a certificate and digital
        signature.  Hence, no mutual authentication can be assumed.
        In case of Kerberos, mutual authentication may be accomplished
        if the PDP or the router transmits a policy element with an
        INTEGRITY object computed with the session key retrieved from
        the Kerberos ticket, or if the Kerberos ticket included in the
        policy element is also used for the RSVP INTEGRITY object as
        described in Section 4.2.  This procedure only works if a
        previous message was transmitted from the end host to the
        network and such key is already established.  Reference [7]
        does not discuss this issue, and therefore there is no
        particular requirement for transmitting network-specific
        credentials back to the end-user's host.
 (2) Integrity Protection
        Integrity protection is applied separately to the RSVP message
        and the POLICY_DATA element, as shown in Figure 1.  In case of
        a policy-ignorant node along the path, the RSVP INTEGRITY
        object and the INTEGRITY object inside the policy element
        terminate at different nodes.  Basically, the same is true for
        the user credentials if they are verified at the policy
        decision point instead of the first hop router.
  • Kerberos
        If Kerberos is used to authenticate the user to the first hop
        router, then the session key included in the Kerberos ticket
        may be used to compute the INTEGRITY object of the policy
        element.  It is the keyed message digest that provides the
        authentication.  The existence of the Kerberos service ticket
        inside the AUTH_DATA object does not provide authentication or
        a guarantee of freshness for the receiving host.

Tschofenig & Graveman Informational [Page 21] RFC 4230 RSVP Security Properties December 2005

        Authentication and guarantee of freshness are provided by the
        keyed hash value of the INTEGRITY object inside the
        POLICY_DATA element.  This shows that the user actively
        participated in the Kerberos protocol and was able to obtain
        the session key to compute the keyed message digest.  The
        Authenticator used in the Kerberos V5 protocol provides
        similar functionality, but replay protection is based on
        timestamps (or on a sequence number if the optional seq-number
        field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
        messages as described in Section 5.3.2 of [8]).
  • Digital Signature
        If public-key-based authentication is provided, then user
        authentication is accomplished with a digital signature.  As
        explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE
        attribute must be the last attribute in the AUTH_DATA object,
        and the digital signature covers the entire AUTH_DATA object.
        In the case of PGP, which hash algorithm and public key
        algorithm are used for the digital signature computation is
        described in [19].  In the case of X.509 credentials, the
        situation is more complex because different mechanisms like
        CMS [29] or PKCS#7 [30] may be used for digitally signing the
        message element.  X.509 only provides the standard for the
        certificate layout, which seems to provide insufficient
        information for this purpose.  Therefore, X.509 certificates
        are supported, for example, by CMS or PKCS#7. [7], however,
        does not make any statements about the usage of CMS or PKCS#7.
        Currently, there is no support for CMS or for PKCS#7 [7],
        which provides more than just public-key-based authentication
        (e.g., CRL distribution, key transport, key agreement, etc.).
        Furthermore, the use of PGP in RSVP is vaguely defined,
        because there are different versions of PGP (including OpenPGP
        [19]), and no indication is given as to which should be used.
        Supporting public-key-based mechanisms in RSVP might increase
        the risks of denial-of-service attacks.  The large processing,
        memory, and bandwidth requirements should also be considered.
        Fragmentation might also be an issue here.
        If the INTEGRITY object is not included in the POLICY_DATA
        element or not sent to the PDP, then we have to make the
        following observations:
           For the digital signature case, only the replay protection
           provided by the digital signature algorithm can be used.
           It is not clear, however, whether this usage was
           anticipated or not.  Hence, we might assume that replay

Tschofenig & Graveman Informational [Page 22] RFC 4230 RSVP Security Properties December 2005

           protection is based on the availability of the RSVP
           INTEGRITY object used with a security association that is
           established by other means.
           Including only the Kerberos session ticket is insufficient,
           because freshness is not provided (because the Kerberos
           Authenticator is missing).  Obviously there is no guarantee
           that the user actually followed the Kerberos protocol and
           was able to decrypt the received TGS_REP (or, in rare
           cases, the AS_REP if a session ticket is requested with the
           initial AS_REQ).
 (3) Replay Protection
     Figure 5 shows the interfaces relevant for replay protection of
     signaling messages in a more complicated architecture.  In this
     case, the client uses the policy data element with PEP2, because
     PEP1 is not policy-aware.  The interfaces between the client and
     PEP1 and between PEP1 and PEP2 are protected with the RSVP
     INTEGRITY object.  The link between the PEP2 and the PDP is
     protected, for example, by using the COPS built-in INTEGRITY
     object.  The dotted line between the Client and the PDP indicates
     the protection provided by the AUTH_DATA element, which has no
     RSVP INTEGRITY object included.
                      AUTH_DATA                         +----+
    +---------------------------------------------------+PDP +-+
    |                                                   +----+ |
    |                                                          |
    |                                                          |
    |                                                 COPS     |
    |                                                 INTEGRITY|
    |                                                          |
    |                                                          |
    |                                                          |
 +--+---+   RSVP INTEGRITY  +----+    RSVP INTEGRITY    +----+ |
 |Client+-------------------+PEP1+----------------------+PEP2+-+
 +--+---+                   +----+                      +-+--+
    |                                                     |
    +-----------------------------------------------------+
                     POLICY_DATA INTEGRITY
                     Figure 5: Replay Protection.
     Host authentication with the RSVP INTEGRITY object and user
     authentication with the INTEGRITY object inside the POLICY_DATA
     element both use the same anti-replay mechanism.  The length of

Tschofenig & Graveman Informational [Page 23] RFC 4230 RSVP Security Properties December 2005

     the Sequence Number field, sequence number rollover, and the
     Integrity Handshake have already been explained in Section 3.1.
     Section 9 of [7] states: "RSVP INTEGRITY object is used to
     protect the policy object containing user identity information
     from security (replay) attacks."  When using public-key-based
     authentication, RSVP-based replay protection is not supported,
     because the digital signature does not cover the POLICY_DATA
     INTEGRITY object with its Sequence Number field.  The digital
     signature covers only the entire AUTH_DATA object.
     The use of public key cryptography within the AUTH_DATA object
     complicates replay protection.  Digital signature computation
     with PGP is described in [31] and in [19].  The data structure
     preceding the signed message digest includes information about
     the message digest algorithm used and a 32-bit timestamp of when
     the signature was created ("Signature creation time").  The
     timestamp is included in the computation of the message digest.
     The IETF standardized version of OpenPGP [19] contains more
     information and describes the different hash algorithms (MD2,
     MD5, SHA-1, RIPEMD-160) supported. [7] does not make any
     statements as to whether the "Signature creation time" field is
     used for replay protection.  Using timestamps for replay
     protection requires different synchronization mechanisms in the
     case of clock-skew.  Traditionally, these cases assume "loosely
     synchronized" clocks but also require specifying a replay window.
     If the "Signature creation time" is not used for replay
     protection, then a malicious, policy-ignorant node can use this
     weakness to replace the AUTH_DATA object without destroying the
     digital signature.  If this was not simply an oversight, it is
     therefore assumed that replay protection of the user credentials
     was not considered an important security requirement, because the
     hop-by-hop processing of the RSVP message protects the message
     against modification by an adversary between two communicating
     nodes.
     The lifetime of the Kerberos ticket is based on the fields
     starttime and endtime of the EncTicketPart structure in the
     ticket, as described in Section 5.3.1 of [8].  Because the ticket
     is created by the KDC located at the network of the verifying
     entity, it is not difficult to have the clocks roughly
     synchronized for the purpose of lifetime verification.
     Additional information about clock-synchronization and Kerberos
     can be found in [32].

Tschofenig & Graveman Informational [Page 24] RFC 4230 RSVP Security Properties December 2005

     If the lifetime of the Kerberos ticket expires, then a new ticket
     must be requested and used.  Rekeying is implemented with this
     procedure.
 (4) (User Identity) Confidentiality
     This section discusses privacy protection of identity information
     transmitted inside the policy element.  User identity
     confidentiality is of particular interest because there is no
     built-in RSVP mechanism for encrypting the POLICY_DATA object or
     the AUTH_DATA elements.  Encryption of one of the attributes
     inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
     discussed.
     To protect the user's privacy, it is important not to reveal the
     user's identity to an adversary located between the user's host
     and the first-hop router (e.g., on a wireless link).
     Furthermore, user identities should not be transmitted outside
     the domain of the visited network provider.  That is, the user
     identity information inside the policy data element should be
     removed or modified by the PDP to prevent revealing its contents
     to other (unauthorized) entities along the signaling path.  It is
     not possible (with the offered mechanisms) to hide the user's
     identity in such a way that it is not visible to the first
     policy-aware RSVP node (or to the attached network in general).
     The ASCII or Unicode distinguished name of the user or
     application inside the POLICY_LOCATOR attribute of the AUTH_DATA
     element may be encrypted as specified in Section 3.3.1 of [7].
     The user (or application) identity is then encrypted with either
     the Kerberos session key or with the private key in case of
     public-key-based authentication.  When the private key is used,
     we usually speak of a digital signature that can be verified by
     everyone possessing the public key.  Because the certificate with
     the public key is included in the message itself, decryption is
     no obstacle.  Furthermore, the included certificate together with
     the additional (unencrypted) information in the RSVP message
     provides enough identity information for an eavesdropper.  Hence,
     the possibility of encrypting the policy locator in case of
     public-key-based authentication is problematic.  To encrypt the
     identities using asymmetric cryptography, the user's host must be
     able somehow to retrieve the public key of the entity verifying
     the policy element (i.e., the first policy-aware router or the
     PDP).  Then, this public key could be used to encrypt a symmetric
     key, which in turn encrypts the user's identity and certificate,
     as is done, e.g., by PGP.  Currently, no such mechanism is
     defined in [7].

Tschofenig & Graveman Informational [Page 25] RFC 4230 RSVP Security Properties December 2005

     The algorithm used to encrypt the POLICY_LOCATOR with the
     Kerberos session key is assumed to be the same as the one used
     for encrypting the service ticket.  The information about the
     algorithm used is available in the etype field of the
     EncryptedData ASN.1 encoded message part.  Section 6.3 of [8]
     lists the supported algorithms. [33] defines newer encryption
     algorithms (Rijndael, Serpent, and Twofish).
     Evaluating user identity confidentiality also requires looking at
     protocols executed outside of RSVP (for example, the Kerberos
     protocol).  The ticket included in the CREDENTIAL attribute may
     provide user identity protection by not including the optional
     cname attribute inside the unencrypted part of the Ticket.
     Because the Authenticator is not transmitted with the RSVP
     message, the cname and the crealm of the unencrypted part of the
     Authenticator are not revealed.  In order for the user to request
     the Kerberos session ticket for inclusion in the CREDENTIAL
     attribute, the Kerberos protocol exchange must be executed.  Then
     the Authenticator sent with the TGS_REQ reveals the identity of
     the user.  The AS_REQ must also include the user's identity to
     allow the Kerberos Authentication Server to respond with an
     AS_REP message that is encrypted with the user's secret key.
     Using Kerberos, it is therefore only possible to hide the content
     of the encrypted policy locator, which is only useful if this
     value differs from the Kerberos principal name.  Hence, using
     Kerberos it is not "entirely" possible to provide user identity
     confidentiality.
     It is important to note that information stored in the policy
     element may be changed by a policy-aware router or by the policy
     decision point.  Which parts are changed depends upon whether
     multicast or unicast is used, how the policy server reacts, where
     the user is authenticated, whether the user needs to be re-
     authenticated in other network nodes, etc.  Hence, user-specific
     and application-specific information can leak after the messages
     leave the first hop within the network where the user's host is
     attached.  As mentioned at the beginning of this section, this
     information leakage is assumed to be intentional.
 (5) Authorization
     In addition to the description of the authorization steps of the
     Host-to-Router interface, user-based authorization is performed
     with the policy element providing user credentials.  The
     inclusion of user and application specific information enables
     policy-based admission control with special user policies that
     are likely to be stored at a dedicated server.  Hence, a Policy
     Decision Point can query, for example, an LDAP server for a

Tschofenig & Graveman Informational [Page 26] RFC 4230 RSVP Security Properties December 2005

     service level agreement that states the amount of resources a
     certain user is allowed to request.  In addition to the user
     identity information, group membership and other non-security-
     related information may contribute to the evaluation of the final
     policy decision.  If the user is not registered to the currently
     attached domain, then there is the question of how much
     information the home domain of the user is willing to exchange.
     This also impacts the user's privacy policy.
     In general, the user may not want to distribute much of this
     policy information.  Furthermore, the lack of a standardized
     authorization data format may create interoperability problems
     when exchanging policy information.  Hence, we can assume that
     the policy decision point may use information from an initial
     authentication and key agreement protocol (which may have already
     required cross-realm communication with the user's home domain,
     if only to show that the home domain knows the user and that the
     user is entitled to roam), to forward accounting messages to this
     domain.  This represents the traditional subscriber-based
     accounting scenario.  Non-traditional or alternative means of
     access might be deployed in the near future that do not require
     any type of inter-domain communication.
     Additional discussions are required to determine the expected
     authorization procedures. [34] and [35] discuss authorization
     issues for QoS signaling protocols.  Furthermore, a number of
     mobility implications for policy handling in RSVP are described
     in [36].
 (6) Performance
     If Kerberos is used for user authentication, then a Kerberos
     ticket must be included in the CREDENTIAL Section of the
     AUTH_DATA element.  The Kerberos ticket has a size larger than
     500 bytes, but it only needs to be sent once because a
     performance optimization allows the session key to be cached as
     noted in Section 7.1 of [1].  It is assumed that subsequent RSVP
     messages only include the POLICY_DATA INTEGRITY object with a
     keyed message digest that uses the Kerberos session key.
     However, this assumes that the security association required for
     the POLICY_DATA INTEGRITY object is created (or modified) to
     allow the selection of the correct key.  Otherwise, it difficult
     to say which identifier is used to index the security
     association.
     If Kerberos is used as an authentication system then, from a
     performance perspective, the message exchange to obtain the
     session key needs to be considered, although the exchange only

Tschofenig & Graveman Informational [Page 27] RFC 4230 RSVP Security Properties December 2005

     needs to be done once in the lifetime of the session ticket.
     This is particularly true in a mobile environment with a fast
     roaming user's host.
     Public-key-based authentication usually provides the best
     scalability characteristics for key distribution, but the
     protocols are performance demanding.  A major disadvantage of the
     public-key-based user authentication in RSVP is the lack of a
     method to derive a session key.  Hence, every RSVP PATH or RESV
     message includes the certificate and a digital signature, which
     is a huge performance and bandwidth penalty.  For a mobile
     environment with low power devices, high latency, channel noise,
     and low-bandwidth links, this seems to be less encouraging.  Note
     that a public key infrastructure is required to allow the PDP (or
     the first-hop router) to verify the digital signature and the
     certificate.  To check for revoked certificates, certificate
     revocation lists or protocols like the Online Certificate Status
     Protocol [27] and the Simple Certificate Validation Protocol [28]
     are needed.  Then the integrity of the AUTH_DATA object can be
     verified via the digital signature.

4.4. Communication between RSVP-Aware Routers

 (1) Authentication
     RSVP signaling messages have data origin authentication and are
     protected against modification and replay with the RSVP INTEGRITY
     object.  The RSVP message flow between routers is protected based
     on the chain of trust, and hence each router needs only a
     security association with its neighboring routers.  This
     assumption was made because of performance advantages and because
     of special security characteristics of the core network to which
     no user hosts are directly attached.  In the core network the
     network structure does not change frequently and the manual
     distribution of shared secrets for the RSVP INTEGRITY object may
     be acceptable.  The shared secrets may be either manually
     configured or distributed by using appropriately secured network
     management protocols like SNMPv3.
     Independent of the key distribution mechanism, host
     authentication with built-in RSVP mechanisms is accomplished
     using the keyed message digest in the RSVP INTEGRITY object,
     computed using the previously exchanged symmetric key.
 (2) Integrity Protection
     Integrity protection is accomplished with the RSVP INTEGRITY
     object with the variable length Keyed Message Digest field.

Tschofenig & Graveman Informational [Page 28] RFC 4230 RSVP Security Properties December 2005

 (3) Replay Protection
     Replay protection with the RSVP INTEGRITY object is extensively
     described in previous sections.  To enable crashed hosts to learn
     the latest sequence number used, the Integrity Handshake
     mechanism is provided in RSVP.
 (4) Confidentiality
     Confidentiality is not provided by RSVP.
 (5) Authorization
     Depending on the RSVP network, QoS resource authorization at
     different routers may need to contact the PDP again.  Because the
     PDP is allowed to modify the policy element, a token may be added
     to the policy element to increase the efficiency of the re-
     authorization procedure.  This token is used to refer to an
     already computed policy decision.  The communications interface
     from the PEP to the PDP must be properly secured.
 (6) Performance
     The performance characteristics for the protection of the RSVP
     signaling messages is largely determined by the key exchange
     protocol, because the RSVP INTEGRITY object is only used to
     compute a keyed message digest of the transmitted signaling
     messages.
     The security associations within the core network, that is,
     between individual routers (in comparison with the security
     association between the user's host and the first-hop router or
     with the attached network in general), can be established more
     easily because of the normally strong trust assumptions.
     Furthermore, it is possible to use security associations with an
     increased lifetime to avoid frequent rekeying.  Hence, there is
     less impact on the performance compared with the user-to-network
     interface.  The security association storage requirements are
     also less problematic.

5. Miscellaneous Issues

 This section describes a number of issues that illustrate some of the
 shortcomings of RSVP with respect to security.

Tschofenig & Graveman Informational [Page 29] RFC 4230 RSVP Security Properties December 2005

5.1. First-Hop Issue

 In case of end-to-end signaling, an end host starts signaling to its
 attached network.  The first-hop communication is often more
 difficult to secure because of the different requirements and a
 missing trust relationship.  An end host must therefore obtain some
 information to start RSVP signaling:
     o  Does this network support RSVP signaling?
     o  Which node supports RSVP signaling?
     o  To which node is authentication required?
     o  Which security mechanisms are used for authentication?
     o  Which algorithms are required?
     o  Where should the keys and security associations come from?
     o  Should a security association be established?
 RSVP, as specified today, is used as a building block.  Hence, these
 questions have to be answered as part of overall architectural
 considerations.  Without answers to these questions, ad hoc RSVP
 communication by an end host roaming to an unknown network is not
 possible.  A negotiation of security mechanisms and algorithms is not
 supported for RSVP.

5.2. Next-Hop Problem

 Throughout the document it was assumed that the next RSVP node along
 the path is always known.  Knowing the next hop is important to be
 able to select the correct key for the RSVP Integrity object and to
 apply the proper protection.  In the case in which an RSVP node
 assumes it knows which node is the next hop, the following protocol
 exchange can occur:

Tschofenig & Graveman Informational [Page 30] RFC 4230 RSVP Security Properties December 2005

                    Integrity
                        (A<->C)               +------+
                                    (3)       | RSVP |
                               +------------->+ Node |
                               |              |  B   |
                  Integrity    |              +--+---+
                   (A<->C)     |                 |
        +------+    (2)     +--+----+            |
   (1)  | RSVP +----------->+Router |            |  Error
  ----->| Node |            | or    +<-----------+ (I am B)
        |  A   +<-----------+Network|       (4)
        +------+    (5)     +--+----+
                   Error       .
                  (I am B)     .              +------+
                               .              | RSVP |
                               ...............+ Node |
                                              |  C   |
                                              +------+
                       Figure 6: Next-Hop Issue.
 When RSVP node A in Figure 6 receives an incoming RSVP Path message,
 standard RSVP message processing takes place.  Node A then has to
 decide which key to select to protect the signaling message.  We
 assume that some unspecified mechanism is used to make this decision.
 In this example, node A assumes that the message will travel to RSVP
 node C.  However, for some reasons (e.g., a route change, inability
 to learn the next RSVP hop along the path, etc.) the message travels
 to node B via a non-RSVP supporting router that cannot verify the
 integrity of the message (or cannot decrypt the Kerberos service
 ticket).  The processing failure causes a PathErr message to be
 returned to the originating sender of the Path message.  This error
 message also contains information about the node that recognized the
 error.  In many cases, a security association might not be available.
 Node A receiving the PathErr message might use the information
 returned with the PathErr message to select a different security
 association (or to establish one).
 Figure 6 describes a behavior that might help node A learn that an
 error occurred.  However, the description in Section 4.2 of [1]
 states in step (5) that a signaling message is silently discarded if
 the receiving host cannot properly verify the message: "If the
 calculated digest does not match the received digest, the message is
 discarded without further processing."  For RSVP Path and similar
 messages, this functionality is not really helpful.

Tschofenig & Graveman Informational [Page 31] RFC 4230 RSVP Security Properties December 2005

 The RSVP Path message therefore provides a number of functions: path
 discovery, detecting route changes, discovery of QoS capabilities
 along the path using the Adspec object (with some interpretation),
 next-hop discovery, and possibly security association establishment
 (for example, in the case of Kerberos).
 From a security point of view, there are conflicts between:
 o  Idempotent message delivery and efficiency
    The RSVP Path message especially performs a number of functions.
    Supporting idempotent message delivery somehow contradicts with
    security association establishment, efficient message delivery,
    and message size.  For example, a "real" idempotent signaling
    message would contain enough information to perform security
    processing without depending on a previously executed message
    exchange.  Adding a Kerberos ticket with every signaling message
    is, however, inefficient.  Using public-key-based mechanisms is
    even more inefficient when included in every signaling message.
    With public-key-based protection for idempotent messages, there is
    the additional risk of introducing denial-of-service attacks.
 o  RSVP Path message functionality and next-hop discovery
    To protect an RSVP signaling message (and an RSVP Path message in
    particular) it is necessary to know the identity of the next
    RSVP-aware node (and some other parameters).  Without a mechanism
    for next-hop discovery, an RSVP Path message is also responsible
    for this task.  Without knowing the identity of the next hop, the
    Kerberos principal name is also unknown.  The so-called Kerberos
    user-to-user authentication mechanism, which would allow the
    receiver to trigger the process of establishing Kerberos
    authentication, is not supported.  This issue will again be
    discussed in relationship with the last-hop problem.
    It is fair to assume that an RSVP-supporting node might not have
    security associations with all immediately neighboring RSVP nodes.
    Especially for inter-domain signaling, IntServ over DiffServ, or
    some new applications such as firewall signaling, the next RSVP-
    aware node might not be known in advance.  The number of next RSVP
    nodes might be considerably large if they are separated by a large
    number of non-RSVP aware nodes.  Hence, a node transmitting an
    RSVP Path message might experience difficulties in properly
    protecting the message if it serves as a mechanism to detect both
    the next RSVP node (i.e., Router Alert Option added to the
    signaling message and addressed to the destination address) and to
    detect route changes.  It is fair to note that, in the intra-

Tschofenig & Graveman Informational [Page 32] RFC 4230 RSVP Security Properties December 2005

    domain case with a dense distribution of RSVP nodes, protection
    might be possible with manual configuration.
    Nothing prevents an adversary from continuously flooding an RSVP
    node with bogus PathErr messages, although it might be possible to
    protect the PathErr message with an existing, available security
    association.  A legitimate RSVP node would believe that a change
    in the path took place.  Hence, this node might try to select a
    different security association or try to create one with the
    indicated node.  If an adversary is located somewhere along the
    path, and either authentication or authorization is not performed
    with the necessary strength and accuracy, then it might also be
    possible to act as a man-in-the-middle.  One method of reducing
    susceptibility to this attack is as follows: when a PathErr
    message is received from a node with which no security association
    exists, attempt to establish a security association and then
    repeat the action that led to the PathErr message.

5.3. Last-Hop Issue

 This section tries to address practical difficulties when
 authentication and key establishment are accomplished with a two-
 party protocol that shows some asymmetry in message processing.
 Kerberos is such a protocol and also the only supported protocol that
 provides dynamic session key establishment for RSVP.  For first-hop
 communication, authentication is typically done between a user and
 some router (for example the access router).  Especially in a mobile
 environment, it is not feasible to authenticate end hosts based on
 their IP or MAC address.  To illustrate this problem, the typical
 processing steps for Kerberos are shown for first-hop communication:
 (1) The end host A learns the identity (i.e., Kerberos principal
     name) of some entity B.  This entity B is either the next RSVP
     node, a PDP, or the next policy-aware RSVP node.
 (2) Entity A then requests a ticket granting ticket for the network
     domain.  This assumes that the identity of the network domain is
     known.
 (3) Entity A then requests a service ticket for entity B, whose name
     was learned in step (1).
 (4) Entity A includes the service ticket with the RSVP signaling
     message (inside the policy object).  The Kerberos session key is
     used to protect the integrity of the entire RSVP signaling
     message.

Tschofenig & Graveman Informational [Page 33] RFC 4230 RSVP Security Properties December 2005

 For last-hop communication, this processing theoretically has to be
 reversed: entity A is then a node in the network (for example, the
 access router) and entity B is the other end host (under the
 assumption that RSVP signaling is accomplished between two end hosts
 and not between an end host and an application server).  However, the
 access router in step (1) might not be able to learn the user's
 principal name because this information might not be available.
 Entity A could reverse the process by triggering an IAKERB exchange.
 This would cause entity B to request a service ticket for A as
 described above.  However, IAKERB is not supported in RSVP.

5.4. RSVP- and IPsec-Protected Data Traffic

 QoS signaling requires flow information to be established at routers
 along a path.  This flow identifier installed at each device tells
 the router which data packets should receive QoS treatment.  RSVP
 typically establishes a flow identifier based on the 5-tuple (source
 IP address, destination IP address, transport protocol type, source
 port, and destination port).  If this 5-tuple information is not
 available, then other identifiers have to be used.  ESP-encrypted
 data traffic is such an example where the transport protocol and the
 port numbers are not accessible.  Hence, the IPsec SPI is used as a
 substitute for them. [12] considers these IPsec implications for RSVP
 and is based on three assumptions:
 (1) An end host that initiates the RSVP signaling message exchange
     has to be able to retrieve the SPI for a given flow.  This
     requires some interaction with the IPsec security association
     database (SAD) and security policy database (SPD) [3].  An
     application usually does not know the SPI of the protected flow
     and cannot provide the desired values.  It can provide the
     signaling protocol daemon with flow identifiers.  The signaling
     daemon would then need to query the SAD by providing the flow
     identifiers as input parameters and receiving the SPI as an
     output parameter.
 (2) [12] assumes end-to-end IPsec protection of the data traffic.  If
     IPsec is applied in a nested fashion, then parts of the path do
     not experience QoS treatment.  This can be treated as a problem
     of tunneling that is initiated by the end host.  The following
     figure better illustrates the problem in the case of enforcing
     secure network access:

Tschofenig & Graveman Informational [Page 34] RFC 4230 RSVP Security Properties December 2005

  +------+          +---------------+      +--------+          +-----+
  | Host |          | Security      |      | Router |          | Host|
  |  A   |          | Gateway (SGW) |      |   Rx   |          |  B  |
  +--+---+          +-------+-------+      +----+---+          +--+--+
     |                      |                   |                 |
     |IPsec-Data(           |                   |                 |
     | OuterSrc=A,          |                   |                 |
     | OuterDst=SGW,        |                   |                 |
     | SPI=SPI1,            |                   |                 |
     | InnerSrc=A,          |                   |                 |
     | InnerDst=B,          |                   |                 |
     | Protocol=X,          |IPsec-Data(        |                 |
     | SrcPort=Y,           | SrcIP=A,          |                 |
     | DstPort=Z)           | DstIP=B,          |                 |
     |=====================>| Protocol=X,       |IPsec-Data(      |
     |                      | SrcPort=Y,        | SrcIP=A,        |
     | --IPsec protected->  | DstPort=Z)        | DstIP=B,        |
     |    data traffic      |------------------>| Protocol=X,     |
     |                      |                   | SrcPort=Y,      |
     |                      |                   | DstPort=Z)      |
     |                      |                   |---------------->|
     |                      |                   |                 |
     |                      |     --Unprotected data traffic--->  |
     |                      |                   |                 |
            Figure 7: RSVP and IPsec protected data traffic.
     Host A, transmitting data traffic, would either indicate a 3-
     tuple <A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>.  In any case,
     it is not possible to make a QoS reservation for the entire path.
     Two similar examples are remote access using a VPN and protection
     of data traffic between a home agent (or a security gateway in
     the home network) and a mobile node.  The same problem occurs
     with a nested application of IPsec (for example, IPsec between A
     and SGW and between A and B).
     One possible solution to this problem is to change the flow
     identifier along the path to capture the new flow identifier
     after an IPsec endpoint.
     IPsec tunnels that neither start nor terminate at one of the
     signaling end points (for example between two networks) should be
     addressed differently by recursively applying an RSVP signaling
     exchange for the IPsec tunnel.  RSVP signaling within tunnels is
     addressed in [13].

Tschofenig & Graveman Informational [Page 35] RFC 4230 RSVP Security Properties December 2005

 (3) It is assumed that SPIs do not change during the lifetime of the
     established QoS reservation.  If a new IPsec SA is created, then
     a new SPI is allocated for the security association.  To reflect
     this change, either a new reservation has to be established or
     the flow identifier of the existing reservation has to be
     updated.  Because IPsec SAs usually have a longer lifetime, this
     does not seem to be a major issue.  IPsec protection of SCTP data
     traffic might more often require an IPsec SA (and SPI) change to
     reflect added and removed IP addresses from an SCTP association.

5.5. End-to-End Security Issues and RSVP

 End-to-end security for RSVP has not been discussed throughout the
 document.  In this context, end-to-end security refers to credentials
 transmitted between the two end hosts using RSVP.  It is obvious that
 care must be taken to ensure that routers along the path are able to
 process and modify the signaling messages according to prescribed
 processing procedures.  However, some objects or mechanisms could be
 used for end-to-end protection.  The main question, however, is the
 benefit of such end-to-end security.  First, there is the question of
 how to establish the required security association.  Between two
 arbitrary hosts on the Internet, this might turn out to be quite
 difficult.  Second, the usefulness of end-to-end security depends on
 the architecture in which RSVP is deployed.  If RSVP is used only to
 signal QoS information into the network, and other protocols have to
 be executed beforehand to negotiate the parameters and to decide
 which entity is charged for the QoS reservation, then no end-to-end
 security is likely to be required.  Introducing end-to-end security
 to RSVP would then cause problems with extensions like RSVP proxy
 [37], Localized RSVP [38], and others that terminate RSVP signaling
 somewhere along the path without reaching the destination end host.
 Such a behavior could then be interpreted as a man-in-the-middle
 attack.

5.6. IPsec Protection of RSVP Signaling Messages

 It is assumed throughout that RSVP signaling messages can also be
 protected by IPsec [3] in a hop-by-hop fashion between two adjacent
 RSVP nodes.  RSVP, however, uses special processing of signaling
 messages, which complicates IPsec protection.  As explained in this
 section, IPsec should only be used for protection of RSVP signaling
 messages in a point-to-point communication environment (i.e., an RSVP
 message can only reach one RSVP router and not possibly more than
 one).  This restriction is caused by the combination of signaling
 message delivery and discovery into a single message.  Furthermore,
 end-to-end addressing complicates IPsec handling considerably.  This
 section describes at least some of these complications.

Tschofenig & Graveman Informational [Page 36] RFC 4230 RSVP Security Properties December 2005

 RSVP messages are transmitted as raw IP packets with protocol number
 46.  It might be possible to encapsulate them in UDP as described in
 Appendix C of [6].  Some RSVP messages (Path, PathTear, and ResvConf)
 must have the Router Alert IP Option set in the IP header.  These
 messages are addressed to the (unicast or multicast) destination
 address and not to the next RSVP node along the path.  Hence, an
 IPsec traffic selector can only use these fields for IPsec SA
 selection.  If there is only a single path (and possibly all traffic
 along it is protected) then there is no problem for IPsec protection
 of signaling messages.  This type of protection is not common and
 might only be used to secure network access between an end host and
 its first-hop router.  Because the described RSVP messages are
 addressed to the destination address instead of the next RSVP node,
 it is not possible to use IPsec ESP [17] or AH [16] in transport
 mode--only IPsec in tunnel mode is possible.
 If an RSVP message can taket more than one possible path, then the
 IPsec engine will experience difficulties protecting the message.
 Even if the RSVP daemon installs a traffic selector with the
 destination IP address, still, no distinguishing element allows
 selection of the correct security association for one of the possible
 RSVP nodes along the path.  Even if it possible to apply IPsec
 protection (in tunnel mode) for RSVP signaling messages by
 incorporating some additional information, there is still the
 possibility that the tunneled messages do not recognize a path change
 in a non-RSVP router.  In this case the signaling messages would
 simply follow a different path than the data.
 RSVP messages like RESV can be protected by IPsec, because they
 contain enough information to create IPsec traffic selectors that
 allow differentiation between various next RSVP nodes.  The traffic
 selector would then contain the protocol number and the source and
 destination address pair of the two communicating RSVP nodes.
 One benefit of using IPsec is the availability of key management
 using either IKE [39], KINK [40] or IKEv2 [41].

5.7. Authorization

 [34] describes two trust models (NJ Turnpike and NJ Parkway) and two
 authorization models (per-session and per-channel financial
 settlement).  The NJ Turnpike model gives a justification for hop-by-
 hop security protection.  RSVP focuses on the NJ Turnpike model,
 although the different trust models are not described in detail.
 RSVP supports the NJ Parkway model and per-channel financial
 settlement only to a certain extent.  Authentication of the user (or
 end host) can be provided with the user identity representation

Tschofenig & Graveman Informational [Page 37] RFC 4230 RSVP Security Properties December 2005

 mechanism, but authentication might, in many cases, be insufficient
 for authorization.  The communication procedures defined for policy
 objects [42] can be improved to support the more efficient per-
 channel financial settlement model by avoiding policy handling
 between inter-domain networks at a signaling message granularity.
 Additional information about expected behavior of policy handling in
 RSVP can also be obtained from [43].
 [35] and [36] provide additional information on authorization.  No
 good and agreed mechanism for dealing with authorization of QoS
 reservations in roaming environments is provided.  Price distribution
 mechanisms are only described in papers and never made their way
 through standardization.  RSVP focuses on receiver-initiated
 reservations with authorization for the QoS reservation by the data
 receiver, which introduces a fair amount of complexity for mobility
 handling as described, for example, in [36].

6. Conclusions

 RSVP was the first QoS signaling protocol that provided some security
 protection.  Whether RSVP provides appropriate security protection
 heavily depends on the environment where it is deployed.  RSVP as
 specified today should be viewed as a building block that has to be
 adapted to a given architecture.
 This document aims to provide more insight into the security of RSVP.
 It cannot be interpreted as a pass or fail evaluation of the security
 provided by RSVP.
 Certainly this document is not a complete description of all security
 issues related to RSVP.  Some issues that require further
 consideration are RSVP extensions (for example [12]), multicast
 issues, and other security properties like traffic analysis.
 Additionally, the interaction with mobility protocols (micro- and
 macro-mobility) demands further investigation from a security point
 of view.
 What can be learned from practical protocol experience and from the
 increased awareness regarding security is that some of the available
 credential types have received more acceptance than others.  Kerberos
 is a system that is integrated into many IETF protocols today.
 Public-key-based authentication techniques are, however, still
 considered to be too heavy-weight (computationally and from a
 bandwidth perspective) to be used for per-flow signaling.  The
 increased focus on denial of service attacks puts additional demands
 on the design of public-key-based authentication.

Tschofenig & Graveman Informational [Page 38] RFC 4230 RSVP Security Properties December 2005

 The following list briefly summarizes a few security or architectural
 issues that deserve improvement:
 o  Discovery and signaling message delivery should be separated.
 o  For some applications and scenarios, it cannot be assumed that
    neighboring RSVP-aware nodes know each other.  Hence, some in-path
    discovery mechanism should be provided.
 o  Addressing for signaling messages should be done in a hop-by-hop
    fashion.
 o  Standard security protocols (IPsec, TLS, or CMS) should be used
    whenever possible.  Authentication and key exchange should be
    separated from signaling message protection.  In general, it is
    necessary to provide key management to establish security
    associations dynamically for signaling message protection.
    Relying on manually configured keys between neighboring RSVP nodes
    is insufficient.  A separate, less frequently executed key
    management and security association establishment protocol is a
    good place to perform entity authentication, security service
    negotiation and selection, and agreement on mechanisms,
    transforms, and options.
 o  The use of public key cryptography in authorization tokens,
    identity representations, selective object protection, etc. is
    likely to cause fragmentation, the need to protect against denial
    of service attacks, and other problems.
 o  Public key authentication and user identity confidentiality
    provided with RSVP require some improvement.
 o  Public-key-based user authentication only provides entity
    authentication.  An additional security association is required to
    protect signaling messages.
 o  Data origin authentication should not be provided by non-RSVP
    nodes (such as the PDP).  Such a procedure could be accomplished
    by entity authentication during the authentication and key
    exchange phase.
 o  Authorization and charging should be better integrated into the
    base protocol.
 o  Selective message protection should be provided.  A protected
    message should be recognizable from a flag in the header.

Tschofenig & Graveman Informational [Page 39] RFC 4230 RSVP Security Properties December 2005

 o  Confidentiality protection is missing and should therefore be
    added to the protocol.  The general principle is that protocol
    designers can seldom foresee all of the environments in which
    protocols will be run, so they should allow users to select from a
    full range of security services, as the needs of different user
    communities vary.
 o  Parameter and mechanism negotiation should be provided.

7. Security Considerations

 This document discusses security properties of RSVP and, as such, it
 is concerned entirely with security.

8. Acknowledgements

 We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu,
 Guenther Schaefer, Marc De Vuyst, Bob Grillo, and Jukka Manner for
 their comments.  Additionally, Hannes would like to thank Robert and
 Jorge for their time discussing various issues.
 Finally, we would like to thank Allison Mankin and John Loughney for
 their guidance and input.

9. References

9.1. Normative References

 [1]   Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
       Authentication", RFC 2747, January 2000.
 [2]   Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
       January 2000.
 [3]   Kent, S. and R. Atkinson, "Security Architecture for the
       Internet Protocol", RFC 2401, November 1998.
 [4]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
       for Message Authentication", RFC 2104, February 1997.
 [5]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
       1992.
 [6]   Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
       "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
       Specification", RFC 2205, September 1997.

Tschofenig & Graveman Informational [Page 40] RFC 4230 RSVP Security Properties December 2005

 [7]   Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
       Herzog, S., and R. Hess, "Identity Representation for RSVP",
       RFC 3182, October 2001.
 [8]   Kohl, J. and C. Neuman, "The Kerberos Network Authentication
       Service (V5)", RFC 1510, September 1993.  Obsoleted by RFC
       4120.
 [9]   Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
       "Diameter Base Protocol", RFC 3588, September 2003.
 [10]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
       Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
       2748, January 2000.
 [11]  Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
       Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
 [12]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
       Flows", RFC 2207, September 1997.
 [13]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
       Operation Over IP Tunnels", RFC 2746, January 2000.

9.2. Informative References

 [14]  Hess, R. and S. Herzog, "RSVP Extensions for Policy Control",
       Work in Progress, June 2001.
 [15]  "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal
       Information Processing Society, April 1995.
 [16]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
       November 1998.
 [17]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
       (ESP)", RFC 2406, November 1998.
 [18]  Fowler, D., "Definitions of Managed Objects for the DS1, E1,
       DS2 and E2 Interface Types", RFC 2495, January 1999.
 [19]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
       "OpenPGP Message Format", RFC 2440, November 1998.
 [20]  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
       Realm Information with DNS", Work in Progress, July 2002.

Tschofenig & Graveman Informational [Page 41] RFC 4230 RSVP Security Properties December 2005

 [21]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
       strengthened version of RIPEMD in Fast Software Encryption",
       LNCS vol. 1039, pp. 71-82, 1996.
 [22]  Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
       Laboratories CryptoBytes, vol. 2, no. 2, 1996.
 [23]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
       Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
       3748, June 2004.
 [24]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
       Authentication Dial In User Service (RADIUS)", RFC 2865, June
       2000.
 [25]  "Microsoft Authorization Data Specification v. 1.0 for
       Microsoft Windows 2000 Operating Systems", April 2000.
 [26]  Cable Television Laboratories, Inc., "PacketCable Security
       Specification, PKT-SP-SEC-I01-991201", website:
       http://www.PacketCable.com/, June 2003.
 [27]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
       "X.509 Internet Public Key Infrastructure Online Certificate
       Status Protocol - OCSP", RFC 2560, June 1999.
 [28]  Malpani, A., Housley, R., and T. Freeman, "Simple Certificate
       Validation Protocol (SCVP)", Work in Progress, October 2005.
 [29]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
       August 2002.
 [30]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
       1.5", RFC 2315, March 1998.
 [31]  "Specifications and standard documents", website:
       http://www.PacketCable.com/, March 2002.
 [32]  Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History,
       Protocols and Implementation", USENIX Computing Systems, vol 9
       no. 1, Winter 1996.
 [33]  Raeburn, K., "Encryption and Checksum Specifications for
       Kerberos 5", RFC 3961, February 2005.
 [34]  Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
       Schulzrinne, "NSIS Authentication, Authorization and Accounting
       Issues", Work in Progress, March 2003.

Tschofenig & Graveman Informational [Page 42] RFC 4230 RSVP Security Properties December 2005

 [35]  Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne,
       H., and T. Chen, "QoS NSLP Authorization Issues", Work in
       Progress, June 2003.
 [36]  Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work
       in Progress, October 2002.
 [37]  Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP
       Proxy", Work in Progress, March 2002.
 [38]  Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K.
       Raatikainen, "Localized RSVP", Work in Progress, September
       2004.
 [39]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
       RFC 2409, November 1998.
 [40]  Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)",
       Work in Progress, October 2005.
 [41]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
       4306, November 2005.
 [42]  Herzog, S., "Accounting and Access Control in RSVP", PhD
       Dissertation, USC, Work in Progress, November 1995.
 [43]  Herzog, S., "Accounting and Access Control for Multicast
       Distributions: Models and Mechanisms", June 1996.
 [44]  Pato, J., "Using Pre-Authentication to Avoid Password Guessing
       Attacks", Open Software Foundation DCE Request for Comments,
       December 1992.
 [45]  Tung, B. and L. Zhu, "Public Key Cryptography for Initial
       Authentication in Kerberos", Work in Progress, November 2005.
 [46]  Wu, T., "A Real-World Analysis of Kerberos Password Security",
       in Proceedings of the 1999 Internet Society Network and
       Distributed System Security Symposium, San Diego, February
       1999.
 [47]  Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP
       Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64,
       1999.
 [48]  Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For
       Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia
       Security Workshop), November 2000.

Tschofenig & Graveman Informational [Page 43] RFC 4230 RSVP Security Properties December 2005

 [49]  Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure
       RSVP Protocol", International Conf on Multimedia and
       Exposition, Tokyo, Japan, August 2001.
 [50]  Jablon, D., "Strong Password-only Authenticated Key Exchange",
       ACM Computer Communication Review, 26(5), pp. 5-26, October
       1996.

Tschofenig & Graveman Informational [Page 44] RFC 4230 RSVP Security Properties December 2005

Appendix A. Dictionary Attacks and Kerberos

 Kerberos might be used with RSVP as described in this document.
 Because dictionary attacks are often mentioned in relationship with
 Kerberos, a few issues are addressed here.
 The initial Kerberos AS_REQ request (without pre-authentication,
 without various extensions, and without PKINIT) is unprotected.  The
 response message AS_REP is encrypted with the client's long-term key.
 An adversary can take advantage of this fact by requesting AS_REP
 messages to mount an off-line dictionary attack.  Pre-authentication
 ([44]) can be used to reduce this problem.  However, pre-
 authentication does not entirely prevent dictionary attacks by an
 adversary who can still eavesdrop on Kerberos messages along the path
 between a mobile node and a KDC.  With mandatory pre-authentication
 for the initial request, an adversary cannot request a Ticket
 Granting Ticket for an arbitrary user.  On-line password guessing
 attacks are still possible by choosing a password (e.g., from a
 dictionary) and then transmitting an initial request that includes a
 pre-authentication data field.  An unsuccessful authentication by the
 KDC results in an error message and thus gives the adversary a hint
 to restart the protocol and try a new password.
 There are, however, some proposals that prevent dictionary attacks.
 The use of Public Key Cryptography for initial authentication [45]
 (PKINIT) is one such solution.  Other proposals use strong-password-
 based authenticated key agreement protocols to protect the user's
 password during the initial Kerberos exchange. [46] discusses the
 security of Kerberos and also discusses mechanisms to prevent
 dictionary attacks.

Appendix B. Example of User-to-PDP Authentication

 The following Section describes an example of user-to-PDP
 authentication.  Note that the description below is not fully covered
 by the RSVP specification and hence it should only be viewed as an
 example.
 Windows 2000, which integrates Kerberos into RSVP, uses a
 configuration with the user authentication to the PDP as described in
 [25].  The steps for authenticating the user to the PDP in an intra-
 realm scenario are the following:
 o  Windows 2000 requires the user to contact the KDC and to request a
    Kerberos service ticket for the PDP account AcsService in the
    local realm.

Tschofenig & Graveman Informational [Page 45] RFC 4230 RSVP Security Properties December 2005

 o  This ticket is then embedded into the AUTH_DATA element and
    included in either the PATH or the RESV message.  In the case of
    Microsoft's implementation, the user identity encoded as a
    distinguished name is encrypted with the session key provided with
    the Kerberos ticket.  The Kerberos ticket is sent without the
    Kerberos authdata element that contains authorization information,
    as explained in [25].
 o  The RSVP message is then intercepted by the PEP, which forwards it
    to the PDP. [25] does not state which protocol is used to forward
    the RSVP message to the PDP.
 o  The PDP that finally receives the message and decrypts the
    received service ticket.  The ticket contains the session key used
    by the user's host to
  • Encrypt the principal name inside the policy locator field of

the AUTH_DATA object and to

  • Create the integrity-protected Keyed Message Digest field in

the INTEGRITY object of the POLICY_DATA element. The

       protection described here is between the user's host and the
       PDP.  The RSVP INTEGRITY object on the other hand is used to
       protect the path between the user's host and the first-hop
       router, because the two message parts terminate at different
       nodes, and different security associations must be used.  The
       interface between the message-intercepting, first-hop router
       and the PDP must be protected as well.
  • The PDP does not maintain a user database, and [25] describes

how the PDP may query the Active Directory (a LDAP based

       directory service) for user policy information.

Appendix C. Literature on RSVP Security

 Few documents address the security of RSVP signaling.  This section
 briefly describes some important documents.
 Improvements to RSVP are proposed in [47] to deal with insider
 attacks.  Insider attacks are caused by malicious RSVP routers that
 modify RSVP signaling messages in such a way that they cause harm to
 the nodes participating in the signaling message exchange.
 As a solution, non-mutable RSVP objects are digitally signed by the
 sender.  This digital signature is added to the RSVP PATH message.
 Additionally, the receiver attaches an object to the RSVP RESV
 message containing a "signed" history.  This value allows

Tschofenig & Graveman Informational [Page 46] RFC 4230 RSVP Security Properties December 2005

 intermediate RSVP routers (by examining the previously signed value)
 to detect a malicious RSVP node.
 A few issues are, however, left open in this document.  Replay
 attacks are not covered, and it is therefore assumed that timestamp-
 based replay protection is used.  To identify a malicious node, it is
 necessary that all routers along the path are able to verify the
 digital signature.  This may require a global public key
 infrastructure and also client-side certificates.  Furthermore, the
 bandwidth and computational requirements to compute, transmit, and
 verify digital signatures for each signaling message might place a
 burden on a real-world deployment.
 Authorization is not considered in the document, which might have an
 influence on the implications of signaling message modification.
 Hence, the chain-of-trust relationship (or this step in a different
 direction) should be considered in relationship with authorization.
 In [48], the above-described idea of detecting malicious RSVP nodes
 is improved by addressing performance aspects.  The proposed solution
 is somewhere between hop-by-hop security and the approach in [47],
 insofar as it separates the end-to-end path into individual networks.
 Furthermore, some additional RSVP messages (e.g., feedback messages)
 are introduced to implement a mechanism called "delayed integrity
 checking."  In [49], the approach presented in [48] is enhanced.

Authors' Addresses

 Hannes Tschofenig
 Siemens
 Otto-Hahn-Ring 6
 Munich, Bavaria  81739
 Germany
 EMail: Hannes.Tschofenig@siemens.com
 Richard Graveman
 RFG Security
 15 Park Avenue
 Morristown, NJ  07960
 USA
 EMail: rfg@acm.org

Tschofenig & Graveman Informational [Page 47] RFC 4230 RSVP Security Properties December 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

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

Tschofenig & Graveman Informational [Page 48]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4230.txt · Last modified: 2005/12/20 01:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki