in Index   Prev   Next

RFC 4230

RSVP Security Properties

Pages: 48
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC4230 - Page 1
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).


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.
Top   ToC   RFC4230 - Page 2

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
Top   ToC   RFC4230 - Page 3

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.
Top   ToC   RFC4230 - Page 4
      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.
Top   ToC   RFC4230 - Page 5
   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.


      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
Top   ToC   RFC4230 - Page 6
       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.
Top   ToC   RFC4230 - Page 7
       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].
Top   ToC   RFC4230 - Page 8

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
Top   ToC   RFC4230 - Page 9
   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

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.
Top   ToC   RFC4230 - Page 10
   | 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

Top   ToC   RFC4230 - Page 11
         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

      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
Top   ToC   RFC4230 - Page 12
         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
Top   ToC   RFC4230 - Page 13
         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

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
Top   ToC   RFC4230 - Page 14
   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