Internet Draft                                     Hannes Tschofenig
                                                       Richard Graveman
                                                           RFG Security
   Expires: December 2003                                     June April 2002                                     October 2003

                         RSVP Security Properties

 Status of this Memo

  This document is an Internet-Draft and is in full conformance
  with all provisions of Section 10 of RFC2026.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress".

  The list of current Internet-Drafts can be accessed at
  The list of Internet-Draft Shadow Directories can be accessed at


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

 Table of Contents

   1. Introduction...................................................2
   2. Terminology and Architectural Assumptions......................3
   3. Overview.......................................................5
      3.1 The RSVP INTEGRITY Object..................................5
      3.2 Security Associations......................................6 Associations......................................7
      3.3 RSVP Key Management Assumptions............................7 Assumptions............................8
      3.4 Identity Representation....................................7 Representation....................................8
      3.5 RSVP Integrity Handshake..................................12
   4. Detailed Security Property Discussion.........................13
      4.1 Discussed Network Topology................................13 Topology..........................................13
      4.2 Host/Router...............................................13 Host/Router...............................................14
      4.3 User to PEP/PDP...........................................17 PEP/PDP...........................................18
      4.4 Communication between RSVP aware routers..................25 RSVP-Aware Routers..................26
   5. Miscellaneous Issues..........................................26 Issues..........................................27
      5.1 First Hop Issue...........................................26 Issue...........................................28
      5.2 Next-Hop Problem..........................................27 Problem..........................................28
      5.3 Last-Hop Issue............................................29 Issue............................................31
      5.4 RSVP and IPsec protected data traffic.....................30 traffic.....................32
      5.5 End-to-End Security Issues and RSVP.......................32 RSVP.......................34
      5.6 IPsec protection of RSVP signaling messages...............32 messages...............34
      5.7 Authorization.............................................33 Authorization.............................................35
   6. Conclusions...................................................34 Conclusions...................................................36
   7. Security Considerations.......................................35 Considerations.......................................37
   8. IANA considerations...........................................35 considerations...........................................37
   9. Acknowledgments...............................................35 Acknowledgments...............................................37
   10. Normative References.........................................38 References.........................................40
   11. Informative References.......................................39 References.......................................41
   Author's Contact Information.....................................42 Information.....................................44
   Full Copyright Statement.........................................42 Statement.........................................44

 1. Introduction

  As the work of the NSIS working group has begun begun, there are also
  concerns about security and its implication implications for the design of a
  signaling protocol. In order to understand the security properties
  and available options of RSVP a number of documents have to be read.
  This document summarize summarizes the security properties of RSVP and is part
  of the overall process of analyzing other signaling protocols and to
  learning from their design considerations. This document should also
  provide a starting point for further discussions.

  The content of this document is organized as follows:

  Section 3 provides an overview of the security mechanisms provided by
  RSVP including the INTEGRITY object, a description of the identity
  representation within the POLICY_DATA object (i.e. (i.e., user
  authentication), and the RSVP Integrity Handshake mechanism.

                      RSVP Security Properties              June 2003

  Section 4 provides a more detailed discussion of the mechanisms used mechanism
  and tries to describe in detail the mechanisms provided in detail. provided.

  Finally a number of miscellaneous issues are described described, which address
  first-hop, next-hop next-hop, and last-hop issues. Furthermore the problem of
  IPsec security protection of data traffic and RSVP signaling message messages
  is discussed.

 2.  Terminology and Architectural Assumptions

  This section describes some important terms and explains some
  architectural assumptions:

  - Chain-of-Trust

  The security mechanisms supported by RSVP [RFC2747] heavily relies 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 RSVP-supporting network
  elements. Additionally Additionally, there is the notion of policy aware policy-aware network
  elements that additionally understand the POLICY_DATA element within the RSVP
  message. Since Because this element also includes an INTEGRITY
  object object,
  there is an additional hop-by-hop security mechanism that provides
  security between policy aware policy-aware nodes. Policy ignorant Policy-ignorant nodes are not
  affected by the inclusion of this object in the POLICY_DATA
  element since element,
  because they do not try to interpret it.

  To protect signaling messages that are possibly modified by each RSVP
  router along the path path, it must be assumed that each incoming request
  is authenticated, integrity protected, and replay protected. This
  provides protection against unauthorized nodes nodes' injecting bogus
  Furthermore Furthermore, each RSVP-router is assumed to behave in the
  expected manner. Outgoing messages transmitted to the next hop
  network element
  experience receive protection according RSVP security

  Using the above described mechanisms mechanisms, a chain-of-trust is created
  whereby a signaling message transmitted by router A via router B and
  received by router C is supposed to be secure if router routers A and B and
  routers B and C share a security association associations and all routers behave
  expectedly. 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 as good as no better than the weakest link in the

  If one router is malicious (for example because an adversary has
  control over this router) router), then it can arbitrarily modify messages and messages,
  cause unexpected behavior behavior, and mount a number of attacks not limited
  restricted to QoS signaling. Additionally Additionally, it must be mentioned that

                      RSVP Security Properties              June 2003 some
  protocols demand more protection than others (this (which depends
  between in part
  on which nodes these protocols are executed). executing these protocols). For example example, edge
  devices, where end-users are attached, may more likely be attacked in
  comparison to with the more secure core network of a service provider.
  In some cases a network service provider may choose not to use the RSVP
  RSVP-provided security mechanisms inside the core network because a
  different security protection is deployed.

  Section 6 of [RFC2750] mentions the term chain-of-trust in the
  context of RSVP integrity protection. In Section 6 of [HH01] the same
  term is used in the context of user authentication with the INTEGRITY
  object inside the POLICY_DATA element. Unfortunately the term is not
  explained in detail and the assumption is assumptions behind it are not clearly

  - Host and User Authentication

  The presence of the RSVP protection and a separate user identity
  representation leads to the fact that both user- user-identity and the host-
  identity are used for RSVP protection. Therefore user Therefore, user-based security
  and host
  based host-based security is investigated separately are covered separately, because of the
  different authentication mechanisms provided. To avoid confusion
  about the different concepts concepts, Section 3.4 will describe describes the concept of
  user authentication in more detail.

  - Key Management


  It is assumed that most of the security associations required for the
  protection of RSVP signaling messages it is assumed that they are already available available, and
  hence key management was done in advance. There is however is, however, an
  exception with the respect to support for Kerberos. Using Kerberos Kerberos, an
  entity is able to distribute a session key used for RSVP signaling


  RSVP uses the an INTEGRITY object in two places of the in a message. The first usage
  is in the RSVP message itself and covers the entire RSVP message as
  defined in [RFC2747] whereas the latter [RFC2747]. The second is included in the POLICY_DATA
  object and defined in [RFC2750]. In order to To differentiate the two objects
  regarding their scope of protection protection, the two terms RSVP INTEGRITY and
  POLICY_DATA INTEGRITY object are used. used, respectively. The data
  structure of the two objects however objects, however, is the same.

  - Hop vs. versus Peer
  In the past there was considerable discussion about past, the terminology
  of a for nodes that are addressed by RSVP. RSVP has been
  discussed considerably. In particular particular, two favorites favorite terms have been
  used: hop and peer. This document uses the term hop hop, which is
  different to from an IP hop. Two neighboring RSVP nodes communicating

                      RSVP Security Properties              June 2003 each other are not necessarily neighboring IP nodes (i.e. (i.e., they
  may be more than one IP hop away).

 3.  Overview

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

 3.1  The RSVP INTEGRITY Object

  The RSVP INTEGRITY object is the major component of the RSVP security
  protection. This object is used to provide integrity and replay
  protection for the content of the signaling message between two RSVP
  participating router. Furthermore routers. Furthermore, the RSVP INTEGRITY object
  provides data origin authentication. The attributes of the object are
  briefly described:

  - Flags field

  The Handshake Flag is the only defined flag and flag. It is used to
  synchronize sequence numbers if the communication gets out-of-sync
  (i.e. for out of sync
  (e.g., it allows a restarting host to recover the most recent
  sequence number). Setting this flag to one indicates that the sender
  is willing to respond to an Integrity Challenge message. This flag
  can therefore be seen as a capability negotiation capability transmitted within
  each INTEGRITY object.

  - Key Identifier

  The Key Identifier selects the key used for verification of the Keyed
  Message Digest field and hence and, hence, must be unique for the sender. Its
  length is It
  has a fixed with 48-bit. 48-bit length. The generation of this Key Identifier
  field is mostly a decision of the local host. [RFC2747] describes
  this field as a combination of an address, the sending interface interface, and
  a 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 (i.e. (e.g., as it is the case with security association
  that have 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 might may be confusing. The sender selects the security
  association based on the receiver's IP address (of (i.e., the address of
  the next
  RSVP capable RSVP-capable router). To determine The process of determining which node
  is the next capable

                      RSVP Security Properties              June 2003

  RSVP RSVP-capable router is not further specified and is
  likely to be statically configured.

  - Sequence Number

  The sequence number used by the INTEGRITY object is 64-bits 64 bits in length
  length, and the starting value can be selected arbitrarily. The
  length of the sequence number field was chosen to avoid exhaustion
  during the lifetime of a security association as stated in Section 3
  of [RFC2747]. In order for the receiver to distinguish between a new
  and a replayed message, the sequence number each value must be monotonically
  incremented modulo 2^64. 2^64 for each message. We assume that the first
  sequence number seen
  (i.e. (i.e., the starting sequence number) is stored
  somewhere. The modulo-
  operation modulo-operation is required because the starting
  sequence number may be an arbitrary number. The receiver therefore
  only accepts packets with a sequence number larger (modulo 2^64) than
  the previous packet. As explained in [RFC2747] this process is
  started by handshaking and agreeing on an initial sequence number. If
  no such handshaking is available then the initial sequence number
  must be part of the establishment of the security association.

  The generation and storage of sequence numbers is an important step
  in preventing replay attacks and is largely determined by the
  capabilities of the system in presence of system crashes, failures
  and restarts. Section 3 of [RFC2747] explains some of the most
  important considerations.

  - Keyed Message However, the description of how the
  receiver distinguishes proper from improper sequence numbers is
  incomplete--it implicitly assumes that gaps large enough to cause the
  sequence number to wrap around cannot occur.

  If delivery in order were guaranteed, the following procedure would
  work: The receiver keeps track of the first sequence number received,
  INIT-SEQ, and most recent sequence number received, LAST-SEQ, for
  each key identifier in a security association. When the first message
  is received, set INIT-SEQ = LAST-SEQ = value received and accept.
  When a subsequent message is received, if its sequence number is
  strictly between LAST-SEQ and INIT-SEQ, modulo 2^64, accept and
  update LAST-SEQ with the value just received. If it is between INIT-
  SEQ and LAST-SEQ, inclusive, modulo 2^64, reject and leave the value
  of LAST-SEQ unchanged. Because delivery in order is not guaranteed,
  the above rules need to be combined with a method of allowing a fixed
  sized window in the neighborhood of LAST-SEQ for out-of-order
  delivery, for example, as described in Appendix C of [RFC2401].

  - Keyed Message Digest

  The Keyed Message Digest is an RSVP built-in a security mechanism built into RSVP and
  used to provide integrity protection of the a signaling messages. message
  (including its sequence number). Prior to computing the value for the
  Keyed Message Digest field 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 HMAC-MD5 is used used, then the output
  value is 16 bytes long. The keyed hash function HMAC-MD5 [RFC2104] is
  required for a RSVP implementation as noted in Section 1 of
  [RFC2747]. Hash algorithms other than MD5 [RFC1321] like SHA SHA-1 [SHA]
  may also be supported.

  The key used for computing this Keyed Message Digest may be obtained
  from the pre-shared secret secret, which is either manually distributed or
  the result of a key management protocol. No key management protocol,
  however, is specified to create the desired security associations.
  Also, no guidelines for key length are given. It should be
  recommended that HMAC-MD5 keys be 128 bits and SHA-1 key 160 bits, as
  in IPsec AH [RFC2402]and ESP [RFC2406].

 3.2  Security Associations

  Different attributes are stored for security associations of sending
  and receiving systems (i.e. (i.e., unidirectional security associations).

                      RSVP Security Properties              June 2003
  The sending system needs to maintain the following attributes in such
  a security association [RFC2747]:

  - Authentication algorithm and algorithm mode
  - Key
  - Key Lifetime
  - Sending Interface
  - Latest sequence number (sent with this key identifier)

  The receiving system has to store the following fields:

  - Authentication algorithm and algorithm mode
  - Key
  - Key Lifetime
  - Source address of the sending system
  - List of last n sequence numbers (received with this key identifier)

  Note that the security associations need to have additional fields to
  indicate their state. It is necessary to have an overlapping lifetime
  of security associations to avoid interrupting an ongoing
  communication because of expired security associations. During such a
  period of overlapping lifetime it is necessary to authenticate either
  one or both active keys. As mentioned in [RFC2747] [RFC2747], a sender and a
  receiver might may have multiple active keys simultaneously.
  If more than one algorithm is supported then the algorithm used must
  be specified for a security association.

 3.3  RSVP Key Management Assumptions

  [RFC2205] assumes that security associations are already available.
  An implementation must provide manual key distribution must be provided by an implementation as noted in
  Section 5.2 of [RFC2747]. Manual key distribution however distribution, however, has
  different requirements to a for key storage -                                              - a storage-ûa simple plaintext ASCII file
  may be sufficient in some cases. If multiple security associations
  with different lifetimes should need to be supported at the same
  time time, then
  a key engine would be more appropriate. Further security requirements
  listed in Section 5.2 of [RFC2747] are the following:

  - The manual deletion of security associations must be supported.
  - The key storage should persist a system restart.
  - Each key must be assigned a specific lifetime and a specific Key

 3.4  Identity Representation

  In addition to host-based authentication with the INTEGRITY object
  inside the RSVP message message, user-based authentication is available as
  introduced with in [RFC2750]. Section 2 of [RFC3182] stated states that

                      RSVP Security Properties              June 2003
  "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 user's host and transmitted inside the RSVP
  message. The structure of the POLICY_DATA element is described in
  [RFC2750]. Network nodes like the PDP policy decision point (PDP) then
  use the information contained in the AUTH_DATA element to
  authenticate the user and to allow policy-based admission control to
  be executed. As mentioned in
  [RFC3182] [RFC3182], the policy element is
  processed and the policy decision
  point PDP replaces the old element with a new one for
  forwarding to the next hop router.

  A detailed description of the POLICY_DATA element can be found in
  [RFC2750]. The attributes contained in the authentication data policy
  element AUTH_DATA, which is defined in [RFC3182], are briefly
  explained in this Section. Figure 1 shows the abstract structure of
  the RSVP message with its security relevant security-relevant objects and the scope of
  protection. The RSVP INTEGRITY object (outer object) covers the
  entire RSVP message message, whereas the POLICY_DATA INTEGRITY object only
  covers objects within the POLICY_DATA element.

   | RSVP Message                                           |
   | INTEGRITY +-------------------------------------------+|
   | Object    |POLICY_DATA Object                         ||
   |           +-------------------------------------------+|
   |           | INTEGRITY +------------------------------+||
   |           | Object    | AUTH_DATA Object             |||
   |           |           +------------------------------+||
   |           |           | Various Authentication       |||
   |           |           | Attributes                   |||
   |           |           +------------------------------+||
   |           +-------------------------------------------+|

     Figure 1: Security relevant Relevant Objects and Elements within the RSVP

  The AUTH_DATA object contains information for identifying users and
  applications together with credentials for those identities. The main
  purpose of those these identities seems to be the usage for policy based policy-based
  admission control and not for authentication and key management. As noted
  in Section 6.1 of [RFC3182] [RFC3182], an RSVP message may contain more than
  one POLICY_DATA object and each of them may contain more than one
  AUTH_DATA object. As indicated in the Figure above 1 and in [RFC3182] [RFC3182], one
  AUTH_DATA object contains may contain more than one authentication attribute.
  A typical configuration for a Kerberos-based user authentication

                      RSVP Security Properties              June 2003
  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 Additionally, other information such as time-
  time-of-day, application type, location information, group membership
  membership, etc. may be relevant for a to implement an access control

  The following attributes are defined for the usage in the AUTH_DATA

  a) Policy Locator

  The policy locator string that is a an X.500 distinguished name (DN)
  used to locate the user and/or or application specific policy information. The
  following types of X.500 DNs are listed:


  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 user's digital certificate
  (i.e., digitally signed). The term encrypted together with a digital
  signature is easy to misconceive. If user identity confidentiality
  shall be provided is
  provided, then the policy locator has to be encrypted with the public
  key of the recipient. How to obtain this public key is not described
  in the document. Such an issue may be specified in a concrete
  architecture where RSVP is used.

  b) Credentials

  Two cryptographic credentials are currently defined for a user:
  Authentication with Kerberos V5 [RFC1510], and authentication with
  the help of digital signatures based on X.509 [RFC2495] and PGP
  [RFC2440]. The following list contains all defined credential types
  currently available and defined in [RFC3182]:

                      RSVP Security Properties              June 2003

  | Credential   |  Description                   |
  |    Type      |                                |
  | ASCII_ID     |  User or application identity  |
  |              |  encoded as an ASCII string    |
  | UNICODE_ID   |  User or application identity  |
  |              |  encoded as an a Unicode string   |
  | KERBEROS_TKT |  Kerberos V5 session ticket    |
  | X509_V3_CERT |  X.509 V3 certificate          |
  | PGP_CERT     |  PGP certificate               |

                  Table 1: Credentials Supported in RSVP

  The first two credentials only contain only a plaintext string string, and
  therefore they do not provide cryptographic user authentication.
  These plaintext strings may be used to identify applications, which
  are included for policy-based admission control. Note that these
  plain-text identifiers may, however, be protected if either the RSVP
  INTEGRITY and/or or the INTEGRITY object of the POLICY_DATA element is
  present. Note that the two INTEGRITY objects can terminate at
  different entities depending on the network structure. The digital
  signature may also provide protection of application identifiers. A
  protected application identity (and the entire content of the
  POLICY_DATA element) cannot be modified as long as no policy ignorant
  nodes are used encountered in between.

  A Kerberos session ticket, as previously mentioned, is the ticket of
  a Kerberos AP_REQ message [RFC1510] without the Authenticator.
  Normally, the AP_REQ message is used by a client to authenticate to a
  server. The INTEGRITY object (e.g. (e.g., of the POLICY_DATA element)
  provides the functionality of the Kerberos Authenticator, namely
  protecting against replay protection and shows showing that the user was able to
  retrieve the session key following the Kerberos protocol. This is,
  however, only the case if the Kerberos session was used for the keyed
  message digest field of the INTEGRITY object. Section 7 of [RFC2747]
  discusses some issues for establishment of keys for the INTEGRITY
  object. The establishment of the security association for the RSVP
  INTEGRITY object with the inclusion of the Kerberos Ticket within the
  AUTH_DATA element may be complicated by the fact that the ticket can
  be decrypted by node B whereas the RSVP INTEGRITY object terminates
  at a different host C. The Kerberos session ticket contains, among
  many other fields, the session key. The Policy Locator may also be

                      RSVP Security Properties              June 2003
  encrypted with the same session key. The protocol steps that need to
  be executed to obtain such a Kerberos service ticket are not
  described in [RFC3182] and may involve several roundtrips depending
  on many Kerberos related Kerberos-related factors. The Kerberos ticket does not need
  to be included in every RSVP message as an optimisation optimization, as described
  in Section 7.1 of [RFC2747]. Thus the receiver must store the
  received service ticket. If the lifetime of the ticket is expired has expired,
  then a new service ticket must be sent. If the receiver lost his its
  state information (because of a crash or restart) then he 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 element, then a digital signature must be added. The digital
  signature computed over the entire AUTH_DATA object provides
  authentication and integrity protection. The SubType of the digital
  signature authentication attribute is set to zero before computing
  the digital signature. Whether or not a guarantee of freshness with
  replay protection (either timestamps or sequence numbers) is provided
  by the digital signature is an open issue as discussed in Section

  c) Digital Signature

  The digital signature computed over the data of the AUTH_DATA object
  must be the last attribute. The algorithm used to compute the digital
  signature depends on the authentication mode listed in the
  credential. This is only partially true since true, because, for example 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 to
  allow of
  allowing the verification of the signature computed by the
  certificate authority (except for the case of self-signed

  d) Policy Error Object

  The Policy Error Object is used in the case of a failure of the
  policy policy-
  based admission control or other credential verification. Currently
  available error messages allow to notify notification if the credentials are
  expired (EXPIRED_CREDENTIALS), if the authorization process
  disallowed the resource request (INSUFFICIENT_PRIVILEGES) and (INSUFFICIENT_PRIVILEGES), or if the
  given set of credentials is not supported
  (UNSUPPORTED_CREDENTIAL_TYPE). The latter 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 Furthermore, it is unlikely that a user supports
  different types of credentials. The purpose of the error

                      RSVP Security Properties              June 2003 message
  IDENTITY_CHANGED is unclear. The Also, the protection of the error
  message is not discussed in [RFC3182].

 3.5  RSVP Integrity Handshake

  The Integrity Handshake is a protocol that was designed to allow a crashed or
  restarted host to obtain the latest valid challenge value stored at
  the receiving host. Due to the absent absence of key management 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 Hence, if there is a steady
  flow of RSVP protected messages between the two hosts hosts, an attacker
  may find it difficult to inject old messages since new messages, because new,
  authenticated messages with high higher sequence numbers arrive and get
  stored immediately.

  The following description explains the details of the a RSVP Integrity
  Handshake that is started by Node A after recovering from a
  synchronization failure:

                     Integrity Challenge
                 (1) Message (including
   +----------+      a Cookie)            +----------+
   |          |-------------------------->|          |
   |  Node A  |                           |  Node B  |
   |          |<--------------------------|          |
   +----------+      Integrity Response   +----------+
                 (2) Message (including
                     the Cookie and the
                     INTEGRITY object)

                    Figure 2: RSVP Integrity Handshake

  The details of the messages are described below:

  CHALLENGE= (Key as follows:

  CHALLENGE:=(Key Identifier, Challenge Cookie)
  Integrity Challenge Message:=(Common Header, CHALLENGE)
  Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)

  The "Challenge Cookie" is suggested to be a MD5 hash of a local
  secret and a timestamp [RFC2747].

  The Integrity Challenge message is not protected with an INTEGRITY
  object as show shown in the protocol flow above. As explained in Section

                      RSVP Security Properties              June 2003 of [RFC2747] this was done to avoid problems in situations where
  communication communicating parties do not have a valid starting sequence

  It is recommended to use

  Using the RSVP Integrity Handshake protocol is recommended although
  it is not mandatory (since it may not be needed in all network

 4.  Detailed Security Property Discussion

  The purpose of this section is to describe the security protection of the RSVP provided
  RSVP-provided mechanisms individually for authentication,
  authorization, integrity and replay protection, user identity
  confidentiality, and confidentiality of the signaling messages.

 4.1  Discussed  Network Topology

  The main purpose of this paragraph is to show the basic interface of interfaces in
  a simple RSVP network architecture. The architecture below assumes
  that there is only a very single domain and that two routers are RSVP and
  policy aware. These assumptions are relaxed in the individual
  paragraphs as necessary. Layer 2 devices between the clients and
  their corresponding first hop routers are not shown. Other network
  elements like a Kerberos Key Distribution Center and for example an a
  LDAP server where server, from which the PDP retrieves his 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  |
                     +----+Point   +---+
                     |    +--------+   |
                     |                 |
                     |                 |
                     |                 |
    +------+       +-+----+        +---+--+          +------+
    |Client|       |Router|        |Router|          |Client|
    |  A   +-------+  1   +--------+  2   +----------+  B   |
    +------+       +------+        +------+          +------+

                    Figure 3: Simple RSVP Architecture

 4.2  Host/Router

  When talking about considering authentication in RSVP it is very important to make a
  distinction between user and host authentication of the

                      RSVP Security Properties              June 2003 signaling
  messages. By using the RSVP INTEGRITY object the host is
  authenticated while credentials inside the AUTH_DATA object can be
  used to authenticate the user. In this section the focus is on host
  authentication whereas the next section covers user authentication.

  a) Authentication

  We use the

  The term host authentication above since is used above, because the selection of
  the security association is bound to the hostÆs host's IP address as
  mentioned in Section Sections 3.1 and 3.2. Depending on the key management
  protocol used to create this security association and the identity used
  used, it is also possible to bind a user identity to this security
  association. Since Because the key management protocol is not specified specified, it
  is difficult to evaluate this part and hence we speak about data
  origin authentication based on the hostÆs 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 the keyed hash value
  computed over the entire RSVP message excluding the keyed message
  digest field itself. The security association used between the userÆs user's
  host and the first-hop router is, as previously mentioned, not
  established by RSVP and must therefore be available before the signaling
  is started.

  - Kerberos for the RSVP INTEGRITY object

  As described in Section 7 of [RFC2747] [RFC2747], Kerberos may be used to
  create the key for the RSVP INTEGRITY object. How to learn the
  principal name (and realm information) of the other node is outside
  the scope of [RFC2747]. Section 4.2.1 of [RFC2747] states that the
  required identities can be obtained statically or dynamically via a
  directory service or DHCP. [HA01] describes a way to distribute
  principal and realm information via DNS DNS, which can be used for this
  purpose (assuming that the FQDN or the IP address of the other node is known
  for which this information is desired). It desired is known). All that is only required
  is to encapsulate the Kerberos ticket inside the policy element. It
  is furthermore mentioned that Kerberos tickets with expired lifetime
  must not be used and the initiator is responsible for requesting and
  exchanging a new service ticket before expiration.

  RSVP multicast processing in combination with Kerberos requires
  additional thoughts: considerations:

  Section 7 of [RFC2747] states that in the multicast case all
  receivers must share a single key with the Kerberos Authentication
  Server i.e.
  Server, i.e., a single principal used for all receivers). From a
  personal discussion with Rodney Hess it seems that there is currently

                      RSVP Security Properties              June 2003
  no other solution available in the context of Kerberos. Multicast
  handling therefore leaves some questions open questions in this context.

  In the case that where one entity crashed 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 request, then a reply message
  must be returned.

  b) Integrity Protection

  Integrity protection between the userÆs user's host and the first hop router
  is based on the RSVP INTEGRITY object. HMAC-MD5 is the preferred preferred,
  although other keyed hash functions may also be used within the RSVP
  INTEGRITY object. In any case case, both communicating entities must have
  a security association which that indicates the algorithm to use. This may may,
  however, be however difficult since there is difficult, because no negotiation protocol is defined to
  agree on a specific algorithm. Hence Hence, if RSVP is used in a mobile
  environment, it is very likely that HMAC-
  MD5 HMAC-MD5 is the only usable algorithm
  for the RSVP INTEGRITY object if
  RSVP is used in a mobile environment and only object. Only in local environments
  it may it be
  useful to switch to a different keyed hash algorithm. The other
  possible alternative is that every implementation must support the
  most important keyed hash algorithms for example MD5, SHA-1,
  160, etc. HMAC-MD5 was mainly chosen because of the its performance
  characteristics. The weaknesses of MD5 [DBP96] are known and
  described in [Dob96]. Other algorithms like SHA-1 [SHA] and RIPEMD-
  160 [DBP96] provide better have stronger security properties.

  c) Replay Protection

  The main mechanism used for replay protection in RSVP is based on
  sequence numbers numbers, whereby the sequence number is included in the RSVP
  INTEGRITY object. The properties of this sequence number mechanism
  are described in Section 3.1. The fact that the receiver stores a
  list of sequence numbers is an indicator for a window mechanism. This
  somehow conflicts with the requirement that the receiver only has to
  store the highest number given in Section 3 of [RFC2747]. We assume
  that this is a typo. Section 4.1 of [RFC2747] gives a few comments
  about the out-of-order delivery and the ability of an implementation
  to specify the replay window. Appendix C of [RFC2401] describes a
  window mechanism for handling out-of-sequence delivery.

  - Integrity Handshake

  The mechanism of the Integrity Handshake is explained in Section 3.5.
  The Cookie value is suggested to be hash of a local secret and a
  timestamp. The Cookie value is not verified by the receiver. The
  mechanism used by the Integrity Handshake is a simple
  Challenge/Response message message, which assumes that the key shared between

                      RSVP Security Properties              June 2003
  the two hosts survives the crash. If If, however, the security
  association is
  however dynamically created created, then this assumption may not be

  In Section 10 of [RFC2747] the authors note that an adversary can
  create a faked Integrity Handshake message including challenge
  cookies. Subsequently he would it could store the received response. Later he tries 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 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 the adversary have "discovered" the cookie
  generation mechanism (for example by knowing the local secret). The
  collection of Challenge/Response pairs is even more
  difficult since difficult,
  because they depend on the Cookie value, on the sequence number included
  in the response message message, and on the shared key which is used by the INTEGRITY

  d) Confidentiality

  Confidentiality is not considered to be a security requirement for
  RSVP. Hence it is not supported by RSVP. RSVP, except as described in
  paragraph d) of Section 4.3. This assumption may not hold, however,
  for enterprises or carriers who want to protect, in addition to
  users' identities, also billing data, network usage patterns, or
  network configurations from eavesdropping and traffic analysis.
  Confidentiality may also help make certain other attacks more
  difficult. For example, the PathErr attack described in Section 5.2
  is harder to carry out if the attacker cannot observe the Path
  message to which the PathErr corresponds.

  e) Authorization

  The task of authorization consists of two subcategories: Network network
  access authorization and RSVP request authorization. Access
  authorization is provided when a node is authenticated to the network
  network, e.g., using EAP [RFC2284] in combination with AAA protocols
  (for example using RADIUS [RFC2865] or DIAMETER [CA+02]). Issues
  related to network access authentication and authorization are
  outside the scope of RSVP.

  The second authorization refers to RSVP itself. Depending on the
  network configuration configuration:
  - the router either forwards the received RSVP request to the policy
    decision point e.g. point, e.g., by using COPS (see [RFC2748] and [RFC2749]) and [RFC2749]),
    to request that an admission control procedure to be executed or
  - the router supports the functionality of a PDP and therefore there
    is no need to forward the request or
  - the router may already be configured with the appropriate policy
    information to decide locally whether to grant this request or not.

  Based on the result of the admission control control, the request may be
  granted or rejected. Information about the resource requesting resource-requesting entity
  must be available to provide policy-based admission control.

  f) Performance

                      RSVP Security Properties              June 2003

  The computation of the keyed message digest for a RSVP INTEGRITY
  object does not represent a performance problem. The protection of
  signaling messages is usually not a problem since problem, because these messages
  are transmitted at a low rate. Even a high number volume of messages does
  not cause performance problems for a RSVP routers due to the
  efficiency of the keyed message digest routine.

  Dynamic key management, which is computationally more demanding, is
  more important for scalability. Since Because RSVP does not specify a
  particular key exchange protocol to be used protocol, it is difficult to estimate the
  effort to create the required security associations.
  Furthermore 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 protocol, etc.  In a stationary environment with a
  single administrative domain the domain, manual security association distribution
  establishment may be acceptable and provides may provide the best performance
  characteristics. In a mobile environment environment, asymmetric authentication
  methods are likely to be used with a key exchange
  protocol 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 section, both user user-based and host based host-based
  authentication is are supported by RSVP. Using RSVP, a user may
  authenticate to the first hop router or to the PDP as specified in
  [RFC2747], depending on the infrastructure provided by the network
  domain or on the architecture used (e.g. (e.g., the integration of RSVP and
  Kerberos V5 into the Windows 2000 Operating System [MADS01]). Another
  architecture where in which RSVP is tightly integrated is the one specified
  by the PacketCable organization. The interested reader is referred to
  [PKTSEC] for a discussion of their security architecture.

  a) Authentication

  When a user sends a RSVP PATH or RESV message then message, this message may
  include some information to authenticate the user. [RFC3182]
  describes how user and application information is embedded into the
  RSVP message (AUTH_DATA object) and how to protect it. A router
  receiving such a message can use this information to authenticate the
  client and forward the user/application 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. In order to To be able to
  authenticate the user, to verify the integrity integrity, and to check for
  replays, the entire POLICY_DATA element has to be forwarded from the
  router to the PDP e.g. PDP, e.g., by including the element into a COPS

                      RSVP Security Properties              June 2003 It is assumed assumed, although not clearly specified in [RFC3182],
  that the INTEGRITY object within the POLICY_DATA element is sent to
  the PDP along with all other attributes although
  not clearly specified in [RFC3182]. attributes.

  Certificate Verification

  Using the policy element as described in [RFC3182] it is not possible
  to provide a certificate revocation list or other information to
  prove the validity of the certificate inside the policy element. A
  specific mechanism for certificate verification is not discussed in
  [RFC3182] and hence a number of them can be used for this purpose.
  For certificate verification verification, the network element (a router or the
  policy decision point), which has to authenticate the user, could
  frequently download certificate revocation lists or should use a protocol
  like the Online Certificate Status Protocol (OCSP) [RFC2560] and the
  Simple Certificate Validation Protocol (SCVP) [MHHF01] to determine
  the current status of a digital certificate.

  User Authentication to the PDP

  This alternative authentication procedure uses the PDP to
  authenticate the user instead of the first hop router. In Section
  4.2.1 in of [RFC3182] the choice is given for the user to either obtain a
  session ticket either for the next hop router or for the PDP. As
  noted in the same Section Section, the identity of the PDP or the next hop
  router is statically configured or dynamically retrieved. Subsequently
  Subsequently, user authentication to the PDP is considered.

  Kerberos-based Authentication to the PDP

  If Kerberos is used to authenticate the user user, then first a session ticket
  for the PDP needs to be requested. If the requested first. A user who roams between
  different routers in the same administrative domain then he does not need to
  request a new service ticket since ticket, because the PDP is likely to be used by
  most or all first-hop routers within the same administrative domain.
  This is different if from the case in which a session ticket for a
  router has to be obtained and authentication to a router is required.
  The router therefore plays a passive role of forwarding the request
  only to the PDP and executing the policy decision returned by the

  Appendix B describes one example of user-to-PDP authentication.

  User authentication with the policy element only provides unilateral
  authentication where whereby the client authenticates to the router or to
  the PDP. If a RSVP message is sent to the userÆs user's host and public keyed key
  based authentication is used used, then the message does not contain a
  certificate and digital signature. Hence no mutual authentication can
  be assumed. In case of Kerberos Kerberos, mutual authentication may be
  accomplished if the PDP or the router transmits a policy element with

                      RSVP Security Properties              June 2003
  an INTEGRITY object computed with the session key retrieved from the
  Kerberos ticket or if the Kerberos ticket included in the policy
  element is also used for the RSVP INTEGRITY object as described in
  Section 4.2. This procedure only works if a previous message was
  transmitted from the end host to the network and such key is already
  established. [RFC3182] does not discuss this issue and therefore
  there is no particular requirement dealing with transmitting network network-
  specific credentials back to the end-user's host.

  b) Integrity Protection

  The integrity

  Integrity protection of is applied separately to the RSVP message and
  the POLICY_DATA element are protected separately as shown in Figure 1. In case of a
  policy policy-
  ignorant node along the path path, the RSVP INTEGRITY object and the
  INTEGRITY object inside the policy element terminate at different
  nodes. Basically Basically, the same is true for the credentials of the user credentials if they
  are verified at the policy decision point instead of the first hop

  - Kerberos

  If Kerberos is used to authenticate the user to the first hop router router,
  then the session key included in the Kerberos ticket may be used to
  compute the INTEGRITY object of the policy element. It is the keyed
  message digest that provides the authentication. The existence of the
  Kerberos service ticket inside the AUTH_DATA object does not provide
  authentication and a guarantee of freshness for the receiving host.
  Authentication and guarantee of freshness is are provided by the keyed
  hash value of the INTEGRITY object inside the POLICY_DATA element.
  The user thereby
  This shows that he the user actively participated in the Kerberos
  protocol and that he was able to obtain the session key to compute the keyed
  message digest. The Authenticator used in the Kerberos V5 protocol
  provides similar functionality functionality, but replay protection is based on
  timestamps (or based on a sequence number if the optional seq-
  number seq-number field
  inside the Authenticator is used for KRB_PRIV/KRB_SAFE messages as
  described in Section 5.3.2 of [RFC1510]).

  - Digital Signature

  If public key based authentication is provided provided, then user
  authentication is accomplished with the a digital signature. As explained
  in Section 3.3.3 of [RFC3182] [RFC3182], the DIGITAL_SIGNATURE attribute must
  be the last attribute in the AUTH_DATA object object, and the digital
  signature covers the entire AUTH_DATA object. Which hash algorithm
  and public key algorithm is are used for the digital signature
  computation is described in [RFC2440] in the case of PGP. In the case
  of X.509 credentials the situation is more complex since complex, because different
  mechanisms like CMS [RFC2630] or PKCS#7 [RFC2315] may be used for the

                      RSVP Security Properties              June 2003
  digitally signing the message element. X.509 only provides the
  standard for the certificate layout layout, which seems to provide
  insufficient information for this purpose. Therefore Therefore, X.509
  certificates are supported for example by CMS and PKCS#7. [RFC3182],
  however, does not make any statements about the usage of CMS and
  PKCS#7. Currently there is no support for CMS or PKCS#7 described in
  [RFC3182], which provides more than only just public key based
  authentication (e.g. (e.g., CRL distribution, key transport, key agreement,
  etc.). Furthermore Furthermore, the usage use of PGP in RSVP is vague since vaguely defined,
  because there are different versions of PGP (including OpenPGP [RFC2440])
  [RFC2440]), and there has
  been no indication is given as to which version should be used.

  Supporting public key based mechanisms in RSVP might increase the
  risks of denial of service attacks. Additionally Additionally, the large
  processing, memory memory, and bandwidth utilization should be considered.
  Fragmentation might also be an issue here.

  If the INTEGRITY object is not included in the POLICY_DATA element or
  not sent to the PDP PDP, then we have to make the following observation: observations:

  a) For the digital signature case case, only the replay protection
     provided by the digital signature algorithm can be used. It is however not
     clear, however, whether this usage was anticipated or not. Hence Hence,
     we might assume that the replay protection is based on the
     availability of the RSVP INTEGRITY object used with a security
     association that is established by other means.

  b) Including only the Kerberos session ticket is insufficient since insufficient,
     because freshness is not provided (since the Kerberos
     Authenticator is missing). Obviously there is no guarantee that
     the user actually followed the Kerberos protocol and was able to
     decrypt the received TGS_REP (or in rare cases the AS_REP if a
     session ticket is requested with the initial AS_REQ).

  c) Replay Protection

  Figure 4 shows the interfaces relevant for replay protection of
  signaling messages in a more complicated architecture. The In this case,
  the client
  therefore uses the policy data element with PEP2 since PEP2, because PEP1 is
  not policy aware. The interfaces between the client and the PEP1 and
  between the PEP1 and PEP2 are protected with the RSVP INTEGRITY object.
  The link between the PEP2 and the PDP is protected protected, for
  example 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
  element, which has no RSVP INTEGRITY object included.

                      RSVP Security Properties              June 2003

                           AUTH_DATA                      +----+
     +- - - - - - - - - - - - - - - - - - - - - - - - - -+PDP +-+
                                                         +----+ |
     |                                                          |
     |                                                 COPS     |
     |                                                          |
     |                                                          |
  +--+---+   RSVP INTEGRITY  +----+    RSVP INTEGRITY    +----+ |
  +--+---+                   +----+                      +-+--+
     |                                                     |
                      POLICY_DATA INTEGRITY

                       Figure 4: Replay Protection

  Host authentication with the RSVP INTEGRITY object and user
  authentication with the INTEGRITY object inside the POLICY_DATA
  element both use the same replay anti-replay mechanism. The length of the
  Sequence Number field, sequence number rollover rollover, and the Integrity
  Handshake is have already been explained in Section 3.1.

  Section 9 in of [RFC3182] states states: "RSVP INTEGRITY object is used to
  protect the policy object containing user identity information from
  security (replay) attacks.". Using attacks." When using public key based authentication
  authentication, RSVP based replay protection is not supported since 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 only. object.

  The usage use of public key cryptography within the AUTH_DATA object
  complicates replay protection. Digital signature computation with PGP
  is described in [PGP] and in [RFC2440]. The data structure preceding
  the signed message digest includes information about the message
  digest algorithm used and a 32-bit timestamp of when the signature
  was created ("Signature creation time"). The timestamp is included in
  the computation of the message digest. The IETF standardized OpenPGP
  version [RFC2440] contains more information and describes the
  different hash algorithms (MD2, MD5, SHA-1, RIPEMD-160) provided. supported.
  [RFC3182] does not make any statements as to whether the "Signature
  creation time" field is used for replay protection. Using timestamps
  for replay protection requires different synchronization mechanisms
  in the case of clock-screws. Traditionally "loosely" synchronized clocks
  are assumed in those clock-skew. Traditionally, these cases assume "loosely
  synchronized" clocks but also requires require specifying a replay-

                      RSVP Security Properties              June 2003 replay-window.

  If the "Signature creation time" is not used for replay protection protection,
  then a malicious policy ignorant malicious, policy-ignorant node can use this weakness to
  replace the AUTH_DATA object without destroying the digital
  signature. It If this was not simply an oversight, it is therefore
  assumed that replay protection of the user credentials is was not
  considered as an important security requirement
  since 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 of in the ticket ticket, as
  described in Section 5.3.1 of [RFC1510]. Since Because the ticket is
  created by the KDC located at the network of the verifying entity entity, it
  is not difficult to have the clocks roughly synchronized for the
  purpose of lifetime verification. Additional information about clock-synchronization clock-
  synchronization and Kerberos can be found at in [DG96].

  If the lifetime of the Kerberos ticket expires expires, then a new ticket
  must be requested and used. Rekeying is implemented with this

  d) (User Identity) Confidentiality

  This section discusses privacy protection of identity information
  transmitted inside the policy element. Especially user 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 - of element, the
  POLICY_LOCATOR attribute attribute, is discussed.

  To protect the users user's privacy it is important not to reveal the users
  user's identity to an adversary located between the userÆs user's host and
  the first-hop router (e.g. (e.g., on a wireless link). User identities
  should furthermore not be transmitted outside the domain of the
  visited network provider i.e. provider, i.e., the user identity information inside
  the policy data element should be removed or modified by the PDP to
  prevent revealing information its contents to other (non-authorized) entities
  along the signaling path. It is not possible (with the offered
  mechanisms) to hide the user user's identity in such a way that it is not
  visible to the first policy aware policy-aware RSVP node (or to the attached
  network in general).

  The ASCII or Unicode distinguished name of user or application inside
  the POLICY_LOCATOR attribute of the AUTH_DATA element may be
  encrypted as specified in Section 3.3.1 of [RFC3182].  The user (or
  application) identity is then encrypted with either the Kerberos
  session key or with the private key in case of public key based
  authentication. Since When the private key is used used, we usually speak of a
  digital signature which that can be verified by everyone possessing the
  public key. Since Because the certificate with the public key is included

                      RSVP Security Properties              June 2003 the message itself this itself, decryption is no obstacle. Furthermore Furthermore, the
  included certificate provides enough identity information for an eavesdropper together with the additional (unencrypted)
  information provided in the RSVP message. Hence message provides enough identity information
  for an eavesdropper. Hence, the possibility of encrypting the policy
  locator in case of public key based authentication is less obvious. problematic. To
  encrypt the identities using asymmetric cryptography cryptography, the userÆs user's host
  must be able to somehow to retrieve the public key of the entity
  verifying the policy element (i.e. (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

  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 used algorithm used is
  available in the etype field of the EncryptedData ASN.1 encoded
  message part. Section 6.3 of [RFC1510] lists the supported
  algorithms. [Rae01] defines new encryption algorithms (Rijndael,
  Serpent, and Twofish).

  Evaluating user identity confidentiality requires also looking at
  protocols executed outside of RSVP (for example to look at 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. Since Because the
  Authenticator is not transmitted with the RSVP message 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 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 not 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

  It is important to note that information stored in the policy element
  may be changed by a policy aware 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 and
  authenticated, whether he the user needs to be re-authenticated in other
  network nodes nodes, etc. Hence Hence, user 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 section, this information leakage is assumed to be intentional.

  e) Authorization

                      RSVP Security Properties              June 2003


  In addition to the description of the authorization steps of the
  Host-to-Router interface, user based user-based authorization is added 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 query, for example
  example, a LDAP server for a service level agreement stating the
  amount of resources a certain user is allowed to request. Additional In addition
  to the user identity information information, group membership and other non-security
  related 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 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 general, the user may not want to
  distribute much of his this policy information. Furthermore Furthermore, the missing lack of
  a standardized authorization data format may create interoperability
  problems when exchanging policy information. Hence Hence, we can assume
  that the policy decision point may use information from an initial
  authentication and key agreement protocol protocol, which may have already
  required cross-realm communication with the user's home domain to if
  only to assume that the home domain knows the user and that the user
  is entitled to roam and to be able to forward accounting messages to
  this domain. This represents the traditional subscriber based subscriber-based
  accounting scenario. Non-traditional or alternative means of access
  might be deployed in the near future that do not require the any type of
  inter-domain communication.

  Additional discussions are required to determine the expected
  authorization procedures. [TB+03a] and [TB+03b] discuss authorization
  issues for QoS signaling protocols. Furthermore Furthermore, a number of
  mobililty implications for the policy handling in RSVP are described in

  f) Performance

  If Kerberos is used for user authentication authentication, then a Kerberos ticket
  must be included in the CREDENTIAL Section of the AUTH_DATA element.
  The Kerberos ticket has a size larger than 500 bytes but only needs
  to be sent once since once, because a performance optimization allows the
  session key to be cached as noted in Section 7.1 of [RFC2747]. It is
  assumed that subsequent RSVP messages only include the POLICY_DATA
  INTEGRITY object with a keyed message digest that uses the Kerberos
  session key. This however This, however, assumes that the security association
  required for the POLICY_DATA INTEGRITY object is created after (or
  modified) to allow the selection of the correct key. Otherwise Otherwise, it
  difficult to say which identifier is used to index the security

                      RSVP Security Properties              June 2003

  When Kerberos is used as an authentication system then, from a
  performance perspective, then the message exchange to obtain the session
  key needs to be considered considered, although the exchange only needs to be
  done once in a long time frame depending on 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 distribution, but the protocols are
  performance demanding. A major disadvantage of the public key based
  user authentication in RSVP is the non-existing possibility 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 performance power devices,
  high latency latency, channel noise, and low bandwidth links links, this seems to
  be less encouraging. Note that a public key infrastructure is
  required to allow the PDP (or the first-hop router) to verify the
  digital signature and the certificate. To check for revoked
  certificates, certificate revocation lists or protocols like the
  Online Certificate Status Protocol [RFC2560] and the Simple
  Certificate Validation Protocol [MHHF01]. [MHHF01] are needed. Then the
  integrity of the AUTH_DATA object via the digital signature is can be

 4.4 Communication between RSVP aware routers RSVP-Aware Routers

  a) Authentication

  RSVP signaling messages are data origin authenticated and protected
  against modification and replay using the RSVP INTEGRITY object. The
  RSVP message flow between routers is protected based on the chain of
  trust and hence each router only needs to have a security association
  with its neighboring routers. This assumption was made because of
  performance advantages and because of special security
  characteristics of the core network where no user hosts are directly
  attached. In the core network the network structure does not change
  frequently and the manual distribution of shared secrets for the RSVP
  INTEGRITY object may be acceptable. The shared secrets may be either
  manually configured or distributed by using appropriately secured
  network management protocols like SNMP. SNMPv3.

  Independent of the key distribution mechanism mechanism, host authentication
  with RSVP built-in mechanisms is accomplished with the keyed message
  digest in the RSVP INTEGRITY object computed using the previously
  exchanged symmetric key.

  b) Integrity Protection

  Integrity protection is accomplished with the RSVP INTEGRITY object
  with the variable length Keyed Message Digest field.

                      RSVP Security Properties              June 2003

  c) Replay Protection

  Replay protection with the RSVP INTEGRITY object is extensively
  described in previous sections.

  To enable crashed hosts to learn the latest sequence number used used, the
  Integrity Handshake mechanism is used provided in RSVP.

  d) Confidentiality

  Confidentiality is not provided by RSVP.

  e) Authorization

  Depending on the RSVP network network, QoS resource authorization at
  different routers may need to contact the PDP again. Since Because the PDP
  is allowed to modify the policy element, a token may be added to the
  policy element to increase the efficiency of the re-authorization
  procedure. This token is used to refer to an already computed policy
  decision. The communications interface from the PEP to the PDP must
  be properly secured.

  f) Performance

  The performance characteristics for the protection of the RSVP
  signaling messages is largely determined by the key exchange protocol since
  protocol, because the RSVP INTEGRITY object is only used to compute a
  keyed message digest of the transmitted signaling messages.

  The security associations within the core network i.e. network, i.e., between
  individual routers (in comparison to with the security association
  between the userÆs 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 Furthermore, it is possible to use
  security associations with an increased lifetime to avoid too frequent
  rekeying. Hence Hence, there is less impact for on the performance compared to
  with the user to network user-to-network interface. The security association storage
  requirements are also less problematic.

 5. Miscellaneous Issues

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

 5.1 First Hop Issue

   In case of end-to-end signaling signaling, an end host starts signaling to its
   attached network. The first-hop communication is often more difficult

                      RSVP Security Properties              June 2003
   to secure because of the different requirements and a missing trust
   relationship. An end host must therefore obtain some information to
   start RSVP signaling:

   - Does this network support RSVP signaling?
   - Which node supports RSVP signaling?
   - To which node is authentication required?
   - Which security mechanisms are used for authentication?
   - Which algorithms have to be used?
   - Where should the keys/security keys and security association come from?
   - Should a security association be established?

   RSVP, as specified today, is used as a building block. Hence Hence, these
   questions have to be answered as part of overall architectural
   considerations. Without giving an answer to this question "ad-hoc" question, ad hoc
   RSVP communication by an end host roaming to an unknown network is
   not possible. A negotiation of security mechanisms and algorithms is
   not supported for RSVP.

 5.2 Next-Hop Problem

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

                                    (A<->C)    +------+
                                     (3)       | RSVP |
                                +------------->+ Node |
                                |              |  B   |
                   Integrity    |              +--+---+
                    (A<->C)     |                 |
         +------+    (2)     +--+----+            |
    (1)  | RSVP +----------->+Router |            |  Error
   ----->| Node |            | or    +<-----------+ (I am B)
         |  A   +<-----------+Network|       (4)
         +------+    (5)     +--+----+
                    Error       .
                   (I am B)     .              +------+
                                .              | RSVP |
                                ...............+ Node |
                                               |  C   |
                         Figure 5: Next-Hop Issue

                      RSVP Security Properties              June 2003

  When RSVP node A in Figure 5 receives an incoming RSVP Path message
  then 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 which is not further specified is used to make this decision.
  In this example node A assumes that the message will travel to RSVP
  node C. However However, because of some reasons (e.g. a route change,
  inability to learn the next RSVP hop along the path, etc.) the
  message travels to node B via a non-RSVP supporting router
  which that
  cannot verify the integrity of the message (or cannot decrypt the
  Kerberos service ticket). The processing failure causes a PathErr
  message to be returned to the originating sender of the Path message.
  This error message also contains information about the node
  recognizing the error. In many cases a security association might not
  be available. Node A receiving the PathErr message might use the
  information returned with the PathErr message to select a different
  security association (or to establish one).

   Figure 5 describes a behavior which that might help node A to learn that an
   error occured. occurred. However, the description of Section 4.2 of [RFC2747]
   describes in step (5) that a signaling message is silently discarded
   if the receiving host cannot properly verify the message: "If the
   calculated digest does not match the received digest, the message is
   discarded without further processing." For RSVP Path alike and similar
   messages this functionality is not really helpful.

   The RSVP Path message therefore provides a number of functions: path
   discovery, detecting route changes, learning of QoS capabilities
   along the path using the Adspec object, (with some interpretation)
   next-hop discovery discovery, and possibly security association establishment
   (for example example, in the case of Kerberos).

  From a security point of view there is a conflict between

  - Idempotent messages message delivery and efficiency

  Especially the

  The RSVP Path message especially performs a number of functions.
  Supporting idempotent message delivery somehow contradicts with
  security association establishment and establishment, efficient message delivery delivery, and
  message size. For example 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, very
  inefficient. Using public key based mechanisms is even more
  inefficient when included in every signaling message. With public key
  based protection for idempotent messages messages, there is additionally a
  risk of introducing denial of service attacks.

  - RSVP Path message functionality and next-hop discovery

                      RSVP Security Properties              June 2003

  To protect an RSVP signaling message (and a RSVP Path message in
  particular) it is necessary to know the identity of the next RSVP RSVP-
  aware node (and some other parameters). Without a mechanism for next-
  hop discovery discovery, an RSVP Path message is also responsible for this
  task. Without knowing the identity of the next hop hop, the Kerberos
  principal name is also unknown. The so-called Kerberos user-to-user
  authentication mechanism is not supported mechanism, which would allow the receiver to trigger
  the process of establishing Kerberos
  authentication authentication, is not
  supported. This issue will again be discussed in relationship with
  the last-hop problem.

  It is fair to assume that a RSVP supporting RSVP-supporting node might not have a
  security association associations with all immediately neighboring RSVP nodes.
  Especially for inter-domain signaling, IntServ over DiffServ DiffServ, or for some
  new applications such as firewall signaling signaling, the next RSVP aware 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 non-
  RSVP aware nodes. Hence Hence, a node transmitting a RSVP Path message
  might experience difficulties to in properly protect protecting the message if
  it serves as a mechanism to detect both the next RSVP node (i.e. (i.e.,
  Router Alert Option added to the signaling message and addressed to
  the destination address) and to detect route changes. It is fair to
  note that in an intra-domain case this might be possible due to
  manual configuration in case of with a dense distribution of RSVP nodes.

  There is nothing which
  nodes this might be possible with manual configuration.

  Nothing prevents an adversary from continuously flooding an RSVP node
  with bogus PathErr messages. It messages, although it might be possible to protect
  the PathErr message with an existing existing, available security
  association if available. association.

  A legitimate RSVP node would believe that a change in the path took
  place. Hence Hence, this node would might try to select a different security
  association or try to create one with the indicated node. Hence an adversary can send a PathErr message at any
  time to confuse an RSVP 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 adversary if either authentication or authorization
  man-in-the-middle. One method of reducing susceptibility to this
  attack is not
  performed 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 necessary accuracy. action that led to the
  PathErr message.

 5.3 Last-Hop Issue

  This section tries to address practical difficulties when
  authentication and key establishment is are accomplished with a two-
  party protocol
  which that shows some asymmetry in message processing when executed
  between two nodes. processing.
  Kerberos is such a protocol and also the only supported protocol which that
  provides dynamic session key establishment for RSVP. For first-hop communication
  communication, authentication is typically done between a user and
  some network in the network router (for example the access router). Especially in a mobile environment
  environment, it is not feasible to authenticate end hosts based on
  their IP or MAC address. To show

                      RSVP Security Properties              June 2003

  the problem illustrate this problem, the typical
  processing steps for Kerberos are shown for first-hop communication:

  a) The end host A learns the identity (i.e. (i.e., Kerberos principal name)
  of some entity B. This entity B is either the next RSVP node or node, a PDP PDP,
  or the next policy aware policy-aware RSVP node.

  b) Entity A then requests a ticket granting ticket for the network
  domain. This assumes that the identity of the network domain is

  c) Entity A then requests a service ticket for entity B which B, whose name
  was learned in step (a).

  d) Entity A includes the service ticket to with the RSVP signaling
  message (inside the policy object). The Kerberos session key is used
  to protect the integrity of the entire RSVP signaling message.

  For last-hop communication this processing step theoretically has to
  be reversed; entity A is then a node in the network (for example the
  access router) and entity B is the other end host. This assumes host (under the
  assumption that RSVP signaling is accomplished between two end hosts
  and not between an end host and a application server. server). The access
  router might however might, however, in step (a) not be able to learn the identity of the user's
  name since 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. IAKERB is however not supported. 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 experience receive QoS treatment. RSVP
   typically establishes a flow identifier based on the 5-tuple (source
   IP address, destination IP address, transport protocol type, source
   port, and destination port). If this 5-tuple information is not
   available, then other identifiers have to be used. IPsec protected IPsec-protected
   data traffic is such an example where the transport protocol and the
   port numbers are not accessible. Hence the IPsec SPI is used as a
   substitute for them. RFC 2207 considers these IPsec implications for
   RSVP and is based on three assumptions:

   a) An end host, which initiates the RSVP signaling message exchange,
   has to be able to retrieve the SPI for given flow. This requires some
   interaction with the IPsec SADB security association database (SAD) and SPD.
   security policy database (SPD) [RFC2401]. An application usually does
   not know the SPI of the protected flow and cannot provide the desired
   values. It can provide the signaling protocol daemon with flow
   identifiers. The signaling daemon would then need to query the IPsec

                      RSVP Security Properties              June 2003

   security association database signaling daemon would then need to query the SAD by
   providing the flow identifiers as input parameters and the SPI as an
   output parameter.

   b) RFC 2207 assumes an end-to-end IPsec protection of the data traffic. In
   If IPsec is applied in a nested fashion fashion, then parts of the path do
   not experience QoS treatment. This problem can be treated as a tunneling problem
   problem, but it is initiated by the end host. A figure better
   illustrates the problem in the case of enforcing secure network

   +------+          +---------------+      +--------+          +------+
   | Host |          | Security      |      | Router |          | Host |
   |  A   |          | Gateway (SGW) |      |   Rx   |          |  B   |
   +--+---+          +-------+-------+      +----+---+          +--+---+
      |                      |                   |                 |
      |IPsec-Data(           |                   |                 |
      | OuterSrc=A,          |                   |                 |
      | OuterDst=SGW,        |                   |                 |
      | SPI=SPI1,            |                   |                 |
      | InnerSrc=A,          |                   |                 |
      | OuterDst=B,          |                   |                 |
      | Protocol=X,          |IPsec-Data(        |                 |
      | SrcPort=Y,           | SrcIP=A,          |                 |
      | DstPort=Z)           | DstIP=B,          |                 |
      |=====================>| Protocol=X,       |IPsec-Data(      |
      |                      | SrcPort=Y,        | SrcIP=A,        |
      | --IPsec protected->  | DstPort=Z)        | DstIP=B,        |
      |    data traffic      |------------------>| Protocol=X,     |
      |                      |                   | SrcPort=Y,      |
      |                      |                   | DstPort=Z)      |
      |                      |                   |---------------->|
      |                      |                   |                 |
      |                      |     --Unprotected data traffic->    |
      |                      |                   |                 |
              Figure 6: RSVP and IPsec protected data traffic

   Host A transmitting data traffic would either indicate a 3-tuple <A,
   SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. In any case it is not
   possible to make a QoS reservation for the entire path. Similar Two similar
   examples are remote access using a VPN, VPN and protection of data traffic
   between the a home agent (or a security gateway in the home network) and the
   a mobile node and other. node. With a nested application of IPsec (for example example, IPsec
   between A and SGW and between A and B) the same problem occurs.

   One possible solution to this problem is to change the flow
   identifier along the path to capture the new flow identifier after an
   IPsec endpoint.

                      RSVP Security Properties              June 2003

   IPsec tunnels which that neither start nor terminate at one of the
   signaling end points (for example between two networks) should be
   addressed differently by recursively applying an RSVP signaling
   exchange for the IPsec tunnel. RSVP signaling within tunnels is
   addressed in [RFC2746].

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

 5.5 End-to-End Security Issues and RSVP

  End-to-end security for RSVP has not been discussed throughout the
  document. In this context end-to-end security refers to credentials
  transmitted between the two end hosts using RSVP. It is obvious that
  care must be taken to ensure that routers along the path are able to
  process and modify the signaling messages according to the prescribed
  procedure. procedures. Some objects however or mechanisms, however, could be
  used for end-to-end protection. The main question however is what the
  benefit of such an end-to-end security is. First First, there is the
  question of how to establish the required security association.
  Between two arbitrary hosts on the Internet this might turn out to be
  quite difficult. Furthermore it Furthermore, te usefulness of end-to-end security
  depends on an the architecture where in which RSVP is deployed whether it is
  useful to provide end-to-end security. deployed. If RSVP is
  only used to signal QoS information into the network network, and other
  protocols have to be executed beforehand to negotiate the parameters
  and to decide which entity is charged for the QoS reservation reservation, then
  no end-to-end security is likely to be required. Introducing end-to-end end-to-
  end security to RSVP would then cause problems with extensions like
  RSVP proxy [GD+02], Localized RSVP [MS+02] [MS+02], and others which 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

   In this document it was

   It is assumed throughout that RSVP signaling messages can also be
   protected by IPsec [RFC2401] in a hop-by-hop fashion between two
   adjacent RSVP nodes. RSVP RSVP, however, uses a special processing of
   messages messages, which complicates IPsec protection. As we explain explained
   in this
   section section, IPsec should only be used for protection of RSVP
   signaling messages in a point-to-point communication environment (i.e.
   (i.e., a RSVP message can only reach one RSVP router and not possibly
   more than

                      RSVP Security Properties              June 2003 one). This circumstance restriction is caused by the combination of
   signaling message delivery and discovery into a single message. Furthermore the
   Furthermore, end-to-end addressing complicates IPsec handling
   considerably. This section tries to describe describes at least some of these

   RSVP messages are transmitted as raw IP packets with protocol number
   46. It might be possible to encapsulate them in UDP as described in
   Appendix C of [RFC2205]. Some RSVP messages (Path, PathTear, and
   ResvConf) must have the Router Alert IP Option set in the IP header.
   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 every 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. Since Because the described RSVP messages
   are addressed to the destination address instead of the next RSVP node
   node, it is not possible to use IPsec ESP [RFC2406] or AH [RFC2402]
   in transport
   mode - only mode--only IPsec in tunnel mode is possible.

   If there is more than one possible path which an RSVP message can
   take take,
   then the IPsec engine will experience difficulties to protect protecting the
   message. Even if the RSVP daemon installs a traffic selector with the
   destination IP address then still there is address, still, no distinguishing element which allows to select
   selection of the correct security association of for one of the possible
   RSVP nodes along. along the path. Even if it possible to apply IPsec
   protection (in tunnel mode) for RSVP signaling messages by
   incorporating some additional information then information, there is still the
   possibility that the tunneled messages do not recognize a path change
   in a non-RSVP router. Then In this case the signaling messages would
   simply follow a different path than the data.

   RSVP messages like RESV can be protected by IPsec since IPsec, because they are
   contain enough information to create IPsec traffic selectors which
   allow a allowing
   differentiation between different various next RSVP nodes. A 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 available availability of key management
  using either IKE [RFC2409], KINK [FH+01] or IKEv2 [IKEv2].

 5.7 Authorization


  [TB+03a] describes two trust models (NJ Turnpike and NJ Parkway model) Parkway) and
  two authorization models (per-session and per-channel financial
  settlement). The NJ Turnpike model gives a justification for the hop-
  by-hop hop-by-
  hop security protection. RSVP supports the NJ Parkway model and
  per-channel per-
  channel financial settlement only to some extend only. a certain extent. The

                      RSVP Security Properties              June 2003
  communication procedures defined for policy object objects [Her95] can be
  improved to support the more efficient per-channel financial
  settlement model by avoiding policy handling between inter-domain
  networks at a signaling message granularity. Additional information
  about expected behavior of policy handling in RSVP can also be
  obtained in from [Her96].

  [TB+03b] and [Tho02] provide additional information on authorization.

 6.  Conclusions

  RSVP was the first QoS signaling protocol which that provided some security
  protection. Whether RSVP provides enough security protection heavily
  depends on the environment where it is deployed. As RSVP is as specified
  today should be seen as a building block that has to be adapted to a
  given architecture.

  This document aims to provide more insights into the security of
  RSVP. It cannot not be interpreted as a pass or fail evaluation of
  the security provided by RSVP.

  Certainly this document is not a complete to describe description of all security
  issues related to RSVP. Some issues that require further
  consideration are RSVP extensions (for example [RFC2207]), multicast
  issues, and other security properties like traffic analysis etc.
  Additionally analysis.
  Additionally, the interaction with mobility protocols (micro- and
  macro-mobility) from a security point of view demands further

  What can be learned from a practical protocol experience and from the
  increased awareness regarding security is that some of the available
  credential types have received more acceptance. acceptance than others. Kerberos
  is such a system which that is integrated in 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 a per-flow signaling. The
  increased focus on denial of service attacks additionally put additional demands a
  closer look
  on the design of public key based authentication.

  The following list briefly summarizes a few security or architectural
  issues which desire that deserve improvement:

  * Discovery and signaling message delivery should be separated.

  * For some applications and scenarios it cannot be assumed that
    neighboring RSVP aware RSVP-aware nodes know each other. Hence some in-path
    discovery mechanism should be provided.

                      RSVP Security Properties              June 2003

  * Addressing for signaling messages should be done in a hop-by-hop

  * 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 general, it is
    necessary to provide key management to dynamically establish a security
    associations dynamically for signaling message protection. Relying
    on manually
  configured keys between neighboring RSVP nodes is insufficient. manually configured keys between neighboring RSVP nodes is
    insufficient. A separate, less frequently executed key management
    and security association establishment protocol is a good place to
    perform entity authentication, security service negotiation and
    selection, and agreement on mechanisms, transforms, and options.

  * The usage use of public key cryptography for in authorization tokens,
    identity representation, representations, selective object protection, etc. is
    likely to cause fragmentation fragmentation, the need to protect against denial
    of service attacks, and other problems.

  * Public key authentication and user identity confidentiality
    provided with RSVP require some improvement.

  * Public key based user authentication only provides entity
    authentication. An additional security association is required to
    protect the signaling message. messages.

  * Data origin authentication should not be provided by non-RSVP nodes
    (such as the PDP). Such a procedure could be accomplished by entity
    authentication during the authentication and key exchange phase.

  * Authorization and charging should be better integrated in into the
    base protocol.

  * Selective message protection should be provided. A protected
    message should be recognizable from a flag in the header.

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

  * Parameter and mechanism negotiation should be provided.

 7.  Security Considerations

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

 8.  IANA considerations

  This document does not address any IANA considerations.

 9. Acknowledgments


  We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu and Fu,
  Guenther Schaefer Schaefer, Marc De Vuyst and Jukka Manner for their valuable
  comments. Additionally I Additionally, we would

                      RSVP Security Properties              June 2003 like to thank Robert and Jorge for
  their time to discuss various issues with me. Furthermore I

  Finally we would like to thank Marc De Vuyst Allison Mankin and
  Jukka Manner John Loughney for their comments to this draft. comments.

 Appendix A: Dictionary Attacks and Kerberos

  Kerberos might be used with RSVP as described in this document. Since
  Because dictionary attacks are often mentioned in relationship with Kerberos
  Kerberos, a few issues are addressed. addressed here.

  The initial Kerberos AS_REQ request (without pre-authentication,
  without various extensions 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. Using pre-
  authentication Pre-authentication
  ([Pat92]) can be used to reduce this problem.
  However pre-authentication However, pre-
  authentication does not entirely prevent dictionary attacks by an
  adversary since he who can still eavesdrop on Kerberos messages if being located at along the path
  between the a mobile node and the a KDC. With mandatory pre-authentication
  for the initial request 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. (e.g., from a
  dictionary) and then transmitting an initial request including pre-authentication a pre-
  authentication data field. An unsuccessful authentication by the KDC
  results in an error message and the gives the adversary a hint to try a new password and
  restart the protocol again. and try a new password.

  There are however are, however, some proposals that prevent dictionary attacks from
  happening. attacks.
  The use of Public Key Cryptography for initial authentication [TN+01]
  (PKINIT) is one such solution. Other proposals use strong-password strong-password-
  based authenticated key agreement protocols to protect the user's
  password during the initial Kerberos exchange. In [Wu99] Tom Wu discusses the
  security of Kerberos and also discusses mechanisms to prevent
  dictionary attacks.

 Appendix B: Example of User-to-PDP Authentication

  The following Section describes an example of user-to-PDP
  authentication. Note that the description below is not fully covered
  by the RSVP specification and hence it should only be seen as an

  Windows 2000, which integrates Kerberos into RSVP, uses a
  configuration with the user authentication to the PDP as described in
  [MADS01]. The steps for authenticating the user to the PDP in an
  intra-realm scenario are the following:

                      RSVP Security Properties              June 2003

  - Windows 2000 requires the user to contact the KDC and to request a
    Kerberos service ticket for the PDP account AcsService in the local

  - This ticket is then embedded in into the AUTH_DATA element and
    included in either the PATH or the RESV message. In case of MicrosoftÆs
    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 information,
    as explained in [MADS01].

  - The RSVP message is then intercepted by the PEP who PEP, which forwards it
    to the PDP. [MADS01] does not state which protocol is used to
    forward the RSVP message to the PDP.

  - The PDP who that finally receives the message decrypts the received
    service ticket. The ticket contains the session key which was used by the
    user's host to
    a) Encrypt the principal name inside the policy locator field of
       the AUTH_DATA object and to
    b) Create the integrity protected 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
  users user's host and the first-hop router since router, because the
       two message parts terminate at a different node nodes and a different
       security association associations must be used. The interface between the message intercepting first-
       message-intercepting, first-hop router and the PDP must be
       protected as well.
    c) The PDP does not maintain a user database database, and [MADS01]
  that how the PDP may query the Active Directory (a LDAP
       based directory service) for user policy information.

 Appendix C: Literature on RSVP Security

  Very few

  Few documents address the security of RSVP signaling. This section
  briefly describes some important documents.

  Improvements to RSVP are proposed in [WW+99] to deal with insider
  attacks. Insider attacks are caused by malicious RSVP routers
  modifying 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-mutuable solution, non-mutable RSVP objects are digitally signed by the
  sender. This digital signature is added to the RSVP PATH message.
  Additionally, the receiver attaches an object to the RSVP RESV
  message containing a "signed" history. This value allows intermediate
  RSVP routers (together with (by examining the previously signed value) to detect a
  malicious RSVP node.

                      RSVP Security Properties              June 2003

  A few issues are, however, left open in the document. Replay attacks
  are not covered covered, and it is therefore assumed that timestamp-based
  replay protection is used. In order to To detect a malicious node node, it is
  necessary that all routers along the path are able to verify the
  digital signature. This requires may require a global public key
  infrastructure and also a client-side PKI. certificates. Furthermore the
  bandwidth and computational requirements to verify compute, transmit, and compute
  verify digital signatures with for each signaling message might place a
  burden on a real-world deployment.

  Authorization is not considered in the document document, which might have an
  influence on the implication implications of signaling message modification. Hence
  Hence, the chain-of-trust relationship (or this step towards in a different
  direction) should be considered in relationship with authorization.

  In [TN00] [TN00], the above described above-described idea of detecting malicious RSVP nodes
  is improved by addressing the performance aspects. The proposed solution
  is somewhat somewhere between hop-by-hop security and the above
  described approach by separating in [WW+99],
  insofar as it separates the end-to-end path into individual networks. Furthermore
  Furthermore, some additional RSVP messages (i.e. (e.g., feedback messages)
  are introduced to implement a mechanism call called "delayed integrity checking".
  checking." In [TN+01] [TN+01], the approach presented with in [TN00] is enhanced.

 10. Normative References

  [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
  Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 3182,
  October, 2001.

  [RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC 2750,
  January, 2000.

  [RFC2747] Baker, F., Lindell, B., Talwar, M.: "RSVP Cryptographic
  Authentication", RC 2747, January, 2000.

  [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
  Sastry, A.: "The COPS(Common Open Policy Service) Protocol", RFC
  2748, January, 2000.

  [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
  Sastry, A.: "COPS usage for RSVP", RFC 2749, January, 2000.

  [RFC2207] Berger, L., OÆMalley, T.: "RSVP Extensions for IPSEC Data
  Flows", RFC 2207, September 1997.

  [RFC1321] Rivest, R.: "The MD5 Message-Digest Algorithm", RFC 1321,
  April, 1992.

                      RSVP Security Properties              June 2003

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

  [RFC2104] Krawczyk, H., Bellare, M., Canetti, R.: "HMAC: Keyed-
  Hashing for Message Authentication", RFC 2104, February, 1997.

  [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.:
  "Resource ReSerVation Protocol (RSVP) - Version 1 Functional
  Specification", RFC 2205, September 1997.

 11. Informative References

  [CA+02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G., Loughney, J.:
  "DIAMETER Base Protocol", <draft-ietf-aaa-diameter-17.txt>, (work in
  progress), December, 2002.

  [DBP96] Dobbertin, H., Bosselaers, A., Preneel, B.: "RIPEMD-160: A
  strengthened version of RIPEMD", in "Fast Software Encryption, LNCS
  Vol 1039, pp. 71-82", 1996.

  [DG96] Davis, D., Geer, D.: "Kerberos With Clocks Adrift: History,
  Protocols and Implementation", in "USENIX Computing Systems Volume 9
  no. 1, Winter", 1996.

  [Dob96] Dobbertin, H.: "The Status of Md5 After a Recent Attack," RSA
  Laboratories' CryptoBytes, Volume 2, Number 2, 1996.

  [GD+02]  Gai, S., Dutt, D., Elfassy, N., Bernet, Y.: "RSVP Proxy",
  <draft-ietf-rsvp-proxy-03.txt>, (expired), March, 2002.

  [HA01] Hornstein, K., Altman, J.: "Distributing Kerberos KDC and
  Realm Information with DNS", <draft-ietf-krb-wg-krb-dns-locate-
  03.txt>, (expired), July, 2002.

  [HH01] Hess, R., Herzog, S.: "RSVP Extensions for Policy Control",
  <draft-ietf-rap-new-rsvp-ext-00.txt>, (expired), June, 2001.

  [Jab96] Jablon, D.: "Strong password-only authenticated key
  exchange", Computer Communication Review, 26(5), pp. 5-26, October,

  [MADS01] "Microsoft Authorization Data Specification v. 1.0 for
  Microsoft Windows 2000 Operating Systems", April, 2000.

  [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
  Protocol (EAP)", RFC 2284, March 1998.

                      RSVP Security Properties              June 2003

  [MHHF01] Malpani, A., Hoffman, P., Housley, R., Freeman, T.: "Simple
  Certificate Validation Protocol (SCVP)", <draft-ietf-pkix-
  scvp-11.txt>, <draft-ietf-pkix-scvp-
  11.txt>, (work in progress), December, 2002.

  [MS+02] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., Raatikainen,
  K.: "Localized RSVP", <draft-manner-lrsvp-00.txt>, (expired), May,

  [Pat92] Pato, J., "Using Pre-Authentication to Avoid Password
  Guessing Attacks", Open Software Foundation DCE Request for Comments
  26, December, 1992.

  [PGP] "Specifications and standard documents",
  http://www.pgpi.org/doc/specs/ (March, 2002).

  [PKTSEC] PacketCable Security Specification, PKT-SP-SEC-I01-991201,
  Cable Television Laboratories, Inc., December 1, 1999,
  http://www.PacketCable.com/ (June, 2003).

   [Rae01] Raeburn, K.: " Encryption "Encryption and Checksum Specifications for
   Kerberos 5", <draft-ietf-krb-wg-crypto-05.txt>, (work in progress),
   June, 2003.

  [RFC2315] Kaliski, B.: " PKCS "PKCS #7: Cryptographic Message Syntax Version
  1.5", RFC 2315, March, 1998.

  [RFC2440] Callas, J.,  Donnerhacke, L., Finney, H., Thayer, R.:
  "OpenPGP Message Format", RFC 2440, November, 1998.

  [RFC2495] Housley, R., Ford, W., Polk, W., Solo, D.: "Internet X.509
  Public Key Infrastructure Certificate and CRL Profile", RFC 2459,
  January, 1999.

  [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams,
  C.: "X.509 Internet Public Key Infrastructure Online Certificate
  Status Protocol -                  - û OCSP", RFC 2560, June, 1999.

  [RFC2630] Housley, R.: "Cryptographic Message Syntax", RFC 2630,
  June, 1999.

  [RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.: "Remote
  Authentication Dial In User Service (RADIUS)", RFC 2865, June, 2000.

  [SHA] NIST, FIPS PUB 180-1, "Secure Hash Standard", April, 1995.

  [TN+01] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S.,
  Wray, J., Trostle, J.: "Public Key Cryptography for Initial
  Authentication in Kerberos", <draft-ietf-cat-kerberos-pk-init-
  16.txt>, (expired), October, 2001.

                      RSVP Security Properties              June 2003

  [Wu99] Wu, T.: "A Real-World Analysis of Kerberos Password Security",
  in "Proceedings of the 1999 Network and Distributed System Security",
  February, 1999.

  [TB+03a] H. Tschofenig, M. Buechli, S. Van den Bosch, H. Schulzrinne:
  "NSIS Authentication, Authorization and Accounting Issues", <draft-tschofenig-nsis-aaa-issues-01.txt>, <draft-
  tschofenig-nsis-aaa-issues-01.txt>, (work in progress), March, 2003.

  [TB+03b] H. Tschofenig, M. Buechli, S. Van den Bosch, H. Schulzrinne,
  T. Chen: "QoS NSLP Authorization Issues", <draft-
  tschofenig-nsis-qos-authz-issues-00.txt>, <draft-tschofenig-nsis-qos-
  authz-issues-00.txt>, (work in progress), June, 2003.

  [Her95] Herzog, S.: "Accounting and Access Control in RSVP",
  <draft-ietf-rsvp-lpm-arch-00.txt>, <draft-
  ietf-rsvp-lpm-arch-00.txt>, (expired), November, 1995.

   [Her96] S. Herzog: "Accounting and Access Control for Multicast
   Distributions: Models and Mechanisms", PhD Dissertation, University
   of Southern California, June 1996, available at:
   http://www.policyconsulting.com/publications/USC%20thesis.pdf, (June,

   [Tho02] M. Thomas: "Analysis of Mobile IP and RSVP Interactions",
   <draft-thomas-nsis-rsvp-analysis-00.txt>, (work in progress), October

  [FH+01] Thomas, M., Vilhuber, J.: "Kerberized Internet Negotiation of
  Keys (KINK)", <draft-ietf-kink-kink-05.txt>, (work in progress),
  January, 2003.

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

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

  [RFC2409] Harkins, D., Carrel, D.: "The Internet Key Exchange (IKE)",
  RFC 2409, November, 1998.

   [IKEv2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol",
   Internet Draft, <draft-ietf-ipsec-ikev2-08.txt>, (work in progress),
   June, 2003.

   [WW+99] Wu, T., Wu, F. and Gong, F.: "Securing QoS: Threats to RSVP
   Messages and Their Countermeasures", in "IEEE IWQoS, pp. 62-64, 1999.

                      RSVP Security Properties              June 2003

   [TN00] Talwar, V. and Nahrstedt, K.: "Securing RSVP For Multimedia
   Applications", in "Proceedings of ACM Multimedia (Multimedia Security
   Workshop)", Los Angeles, November, 2000.

   [TN+01] Talwar, V., Nath, S., Nahrstedt, K.: "RSVP-SQoS : A Secure
   RSVP Protocol", in "International Conference on Multimedia and
   Exposition", Tokyo , Japan,  August 2001.

 Author's Contact Information

  Hannes Tschofenig
  Siemens AG
  Otto-Hahn-Ring 6
  81739 Munich
  Email: Hannes.Tschofenig@siemens.com

  Richard Graveman
  RFG Security, LLC
  15 Park Avenue
  Morristown, NJ 07960 USA
  email: rfg@acm.org

 Full Copyright Statement

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

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

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

  This document and the information contained herein is provided on an


                      RSVP Security Properties              June 2003

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