<pre>Network Working Group                                      H. Tschofenig
Request for Comments: 4230                                       Siemens
Category: Informational                                      R. Graveman
                                                            RFG Security
                                                           December 2005


                        <span class="h1">RSVP Security Properties</span>

Status of This Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

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



























<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


Table of Contents

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



















<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

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

   The content of this document is organized as follows.  <a href="#section-2">Section 2</a>
   introduces the terminology used throughout the document.  <a href="#section-3">Section 3</a>
   provides an overview of the security mechanisms provided by RSVP
   including the INTEGRITY object, a description of the identity
   representation within the POLICY_DATA object (i.e., user
   authentication), and the RSVP Integrity Handshake mechanism.  <a href="#section-4">Section</a>
   <a href="#section-4">4</a> provides a more detailed discussion of the mechanisms used and
   tries to describe in detail the mechanisms provided.  Several
   miscellaneous issues are covered in <a href="#section-5">Section 5</a>.

   RSVP also supports multicast, but this document does not address
   security aspects for supporting multicast QoS signaling.  Multicast
   is currently outside the scope of the NSIS working group.

   Although a variation of RSVP, namely RSVP-TE, is used in the context
   of MPLS to distribute labels for a label switched path, its usage is
   different from the usage scenarios envisioned for NSIS.  Hence, this
   document does not address RSVP-TE or its security properties.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology and Architectural Assumptions</span>

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

   o  Chain-of-Trust:

      The security mechanisms supported by RSVP [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>] heavily rely on
      optional hop-by-hop protection, using the built-in INTEGRITY
      object.  Hop-by-hop security with the INTEGRITY object inside the
      RSVP message thereby refers to the protection between RSVP-
      supporting network elements.  Additionally, there is the notion of
      policy-aware nodes that understand the POLICY_DATA element within
      the RSVP message.  Because this element also includes an INTEGRITY
      object, there is an additional hop-by-hop security mechanism that
      provides security between policy-aware nodes.  Policy-ignorant
      nodes are not affected by the inclusion of this object in the
      POLICY_DATA element, because they do not try to interpret it.



<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


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

      Using the mechanisms described above, a chain-of-trust is created
      whereby a signaling message that is transmitted by router A via
      router B and received by router C is supposed to be secure if
      routers A and B and routers B and C share security associations
      and all routers behave as expected.  Hence, router C trusts router
      A although router C does not have a direct security association
      with router A.  We can therefore conclude that the protection
      achieved with this hop-by-hop security for the chain-of-trust is
      no better than the weakest link in the chain.

      If one router is malicious (for example, because an adversary has
      control over this router), then it can arbitrarily modify
      messages, cause unexpected behavior, and mount a number of attacks
      that are not limited to QoS signaling.  Additionally, it must be
      mentioned that some protocols demand more protection than others
      (which depends, in part, on which nodes are executing these
      protocols).  For example, edge devices, where end-users are
      attached, may be more likely to be attacked in comparison with the
      more secure core network of a service provider.  In some cases, a
      network service provider may choose not to use the RSVP-provided
      security mechanisms inside the core network because a different
      security protection is deployed.

      Section 6 of [<a href="#ref-2" title="&quot;RSVP Extensions for Policy Control&quot;">2</a>] mentions the term chain-of-trust in the context
      of RSVP integrity protection.  In Section 6 of [<a href="#ref-14" title="&quot;RSVP Extensions for Policy Control&quot;">14</a>] the same term
      is used in the context of user authentication with the INTEGRITY
      object inside the POLICY_DATA element.  Unfortunately, the term is
      not explained in detail and the assumptions behind it are not
      clearly specified.

   o  Host and User Authentication:

      The presence of RSVP protection and a separate user identity
      representation leads to the fact that both user-identity and host-
      identity are used for RSVP protection.  Therefore, user-based
      security and host-based security are covered separately, because
      of the different authentication mechanisms provided.  To avoid
      confusion about the different concepts, <a href="#section-3.4">Section 3.4</a> describes the
      concept of user authentication in more detail.



<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   o  Key Management:

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

   o  RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:

      RSVP uses an INTEGRITY object in two places in a message.  The
      first is in the RSVP message itself and covers the entire RSVP
      message as defined in [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  The second is included in the
      POLICY_DATA object and defined in [<a href="#ref-2" title="&quot;RSVP Extensions for Policy Control&quot;">2</a>].  To differentiate the two
      objects by their scope of protection, the two terms RSVP INTEGRITY
      and POLICY_DATA INTEGRITY object are used, respectively.  The data
      structure of the two objects, however, is the same.

   o  Hop versus Peer:

      In the past, the terminology for nodes addressed by RSVP has been
      discussed considerably.  In particular, two favorite terms have
      been used: hop and peer.  This document uses the term hop, which
      is different from an IP hop.  Two neighboring RSVP nodes
      communicating with each other are not necessarily neighboring IP
      nodes (i.e., they may be more than one IP hop away).

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Overview</span>

   This section describes the security mechanisms provided by RSVP.
   Although use of IPsec is mentioned in Section 10 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>], the other
   security mechanisms primarily envisioned for RSVP are described.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  The RSVP INTEGRITY Object</span>

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

   o  Flags field:

       The Handshake Flag is the only defined flag.  It is used to
       synchronize sequence numbers if the communication gets out of
       sync (e.g., it allows a restarting host to recover the most



<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       recent sequence number).  Setting this flag to one indicates that
       the sender is willing to respond to an Integrity Challenge
       message.  This flag can therefore be seen as a negotiation
       capability transmitted within each INTEGRITY object.

   o  Key Identifier:

       The Key Identifier selects the key used for verification of the
       Keyed Message Digest field and, hence, must be unique for the
       sender.  It has a fixed 48-bit length.  The generation of this
       Key Identifier field is mostly a decision of the local host. [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>]
       describes this field as a combination of an address, sending
       interface, and key number.  We assume that the Key Identifier is
       simply a (keyed) hash value computed over a number of fields,
       with the requirement to be unique if more than one security
       association is used in parallel between two hosts (e.g., as is
       the case with security associations having overlapping
       lifetimes).  A receiving system uniquely identifies a security
       association based on the Key Identifier and the sender's IP
       address.  The sender's IP address may be obtained from the
       RSVP_HOP object or from the source IP address of the packet if
       the RSVP_HOP object is not present.  The sender uses the outgoing
       interface to determine which security association to use.  The
       term "outgoing interface" may be confusing.  The sender selects
       the security association based on the receiver's IP address
       (i.e., the address of the next RSVP-capable router).  The process
       of determining which node is the next RSVP-capable router is not
       further specified and is likely to be statically configured.

   o  Sequence Number:

       The sequence number used by the INTEGRITY object is 64 bits in
       length, and the starting value can be selected arbitrarily.  The
       length of the sequence number field was chosen to avoid
       exhaustion during the lifetime of a security association as
       stated in Section 3 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  In order for the receiver to
       distinguish between a new and a replayed message, the sequence
       number must be monotonically incremented (modulo 2^64) for each
       message.  We assume that the first sequence number seen (i.e.,
       the starting sequence number) is stored somewhere.  The modulo-
       operation is required because the starting sequence number may be
       an arbitrary number.  The receiver therefore only accepts packets
       with a sequence number larger (modulo 2^64) than the previous
       packet.  As explained in [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>] 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.




<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       The generation and storage of sequence numbers is an important
       step in preventing replay attacks and is largely determined by
       the capabilities of the system in the presence of system crashes,
       failures, and restarts.  Section 3 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>] explains some of the
       most important considerations.  However, the description of how
       the receiver distinguishes proper from improper sequence numbers
       is incomplete: it implicitly assumes that gaps large enough to
       cause the sequence number to wrap around cannot occur.

       If delivery in order were guaranteed, the following procedure
       would work: the receiver keeps track of the first sequence number
       received, INIT-SEQ, and the most recent sequence number received,
       LAST-SEQ, for each key identifier in a security association.
       When the first message is received, set INIT-SEQ = LAST-SEQ =
       value received and accept.  When a subsequent message is
       received, if its sequence number is strictly between LAST-SEQ and
       INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the
       value just received.  If it is between INIT-SEQ and LAST-SEQ,
       inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ
       unchanged.  Because delivery in order is not guaranteed, the
       above rules need to be combined with a method of allowing a fixed
       sized window in the neighborhood of LAST-SEQ for out-of-order
       delivery, for example, as described in <a href="#appendix-C">Appendix C</a> of [<a href="#ref-3" title="&quot;Security Architecture for the Internet Protocol&quot;">3</a>].

   o  Keyed Message Digest:

       The Keyed Message Digest is a security mechanism built into RSVP
       that used to provide integrity protection of a signaling message
       (including its sequence number).  Prior to computing the value
       for the Keyed Message Digest field, the Keyed Message Digest
       field itself must be set to zero and a keyed hash computed over
       the entire RSVP packet.  The Keyed Message Digest field is
       variable in length but must be a multiple of four octets.  If
       HMAC-MD5 is used, then the output value is 16 bytes long.  The
       keyed hash function HMAC-MD5 [<a href="#ref-4" title="&quot;HMAC: Keyed-Hashing for Message Authentication&quot;">4</a>] is required for an RSVP
       implementation, as noted in Section 1 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  Hash algorithms
       other than MD5 [<a href="#ref-5" title="&quot;The MD5 Message-Digest Algorithm&quot;">5</a>], like SHA-1 [<a href="#ref-15" title="&quot;Secure Hash Standard, NIST, FIPS PUB 180-1&quot;">15</a>], may also be supported.

       The key used for computing this Keyed Message Digest may be
       obtained from the pre-shared secret, which is either manually
       distributed or the result of a key management protocol.  No key
       management protocol, however, is specified to create the desired
       security associations.  Also, no guidelines for key length are
       given.  It should be recommended that HMAC-MD5 keys be 128 bits
       and SHA-1 keys 160 bits, as in IPsec AH [<a href="#ref-16" title="&quot;IP Authentication Header&quot;">16</a>] and ESP [<a href="#ref-17" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">17</a>].






<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Security Associations</span>

   Different attributes are stored for security associations of sending
   and receiving systems (i.e., unidirectional security associations).
   The sending system needs to maintain the following attributes in such
   a security association [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>]:

      o  Authentication algorithm and algorithm mode

      o  Key

      o  Key Lifetime

      o  Sending Interface

      o  Latest sequence number (received with this key identifier)

   The receiving system has to store the following fields:

      o  Authentication algorithm and algorithm mode

      o  Key

      o  Key Lifetime

      o  Source address of the sending system

      o  List of last n sequence numbers (received with this key
         identifier)

   Note that the security associations need to have additional fields to
   indicate their state.  It is necessary to have overlapping lifetimes
   of security associations to avoid interrupting an ongoing
   communication because of expired security associations.  During such
   a period of overlapping lifetime it is necessary to authenticate with
   either one or both active keys.  As mentioned in [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>], a sender and a
   receiver may have multiple active keys simultaneously.  If more than
   one algorithm is supported, then the algorithm used must be specified
   for a security association.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  RSVP Key Management Assumptions</span>

   <a href="./rfc2205">RFC 2205</a> [<a href="#ref-6" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">6</a>] assumes that security associations are already
   available.  An implementation must support manual key distribution as
   noted in Section 5.2 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  Manual key distribution, however, has
   different requirements for key storage; a simple plaintext ASCII file
   may be sufficient in some cases.  If multiple security associations
   with different lifetimes need to be supported at the same time, then



<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   a key engine would be more appropriate.  Further security
   requirements listed in Section 5.2 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>] are the following:

   o  The manual deletion of security associations must be supported.

   o  The key storage should persist during a system restart.

   o  Each key must be assigned a specific lifetime and a specific Key
      Identifier.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Identity Representation</span>

   In addition to host-based authentication with the INTEGRITY object
   inside the RSVP message, user-based authentication is available as
   introduced in [<a href="#ref-2" title="&quot;RSVP Extensions for Policy Control&quot;">2</a>].  Section 2 of [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>] states that "Providing policy
   based admission control mechanism based on user identities or
   application is one of the prime requirements."  To identify the user
   or the application, a policy element called AUTH_DATA, which is
   contained in the POLICY_DATA object, is created by the RSVP daemon at
   the user's host and transmitted inside the RSVP message.  The
   structure of the POLICY_DATA element is described in [<a href="#ref-2" title="&quot;RSVP Extensions for Policy Control&quot;">2</a>].  Network
   nodes acting as policy decision points (PDPs) then use the
   information contained in the AUTH_DATA element to authenticate the
   user and to allow policy-based admission control to be executed.  As
   mentioned in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], the policy element is processed and the PDP
   replaces the old element with a new one for forwarding to the next
   hop router.

   A detailed description of the POLICY_DATA element can be found in
   [<a href="#ref-2" title="&quot;RSVP Extensions for Policy Control&quot;">2</a>].  The attributes contained in the authentication data policy
   element AUTH_DATA, which is defined in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], are briefly explained in
   this Section.  Figure 1 shows the abstract structure of the RSVP
   message with its security-relevant objects and the scope of
   protection.  The RSVP INTEGRITY object (outer object) covers the
   entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
   covers objects within the POLICY_DATA element.















<span class="grey">Tschofenig &amp; Graveman        Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


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

               Figure 1: Security Relevant Objects and Elements
                         within the RSVP Message.

   The AUTH_DATA object contains information for identifying users and
   applications together with credentials for those identities.  The
   main purpose of these identities seems to be usage for policy-based
   admission control and not authentication and key management.  As
   noted in Section 6.1 of [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], an RSVP message may contain more than
   one POLICY_DATA object and each of them may contain more than one
   AUTH_DATA object.  As indicated in Figure 1 and in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], one AUTH_DATA
   object may contain more than one authentication attribute.  A typical
   configuration for Kerberos-based user authentication includes at
   least the Policy Locator and an attribute containing the Kerberos
   session ticket.

   Successful user authentication is the basis for executing policy-
   based admission control.  Additionally, other information such as
   time-of-day, application type, location information, group
   membership, etc. may be relevant to the implementation of an access
   control policy.

   The following attributes are defined for use in the AUTH_DATA object:

      o  Policy Locator

         *  ASCII_DN

         *  UNICODE_DN

         *  ASCII_DN_ENCRYPT

         *  UNICODE_DN_ENCRYPT





<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


         The policy locator string is an X.500 distinguished name (DN)
         used to locate user or application-specific policy information.
         The four types of X.500 DNs are listed above.  The first two
         types are the ASCII and the Unicode representation of the user
         or application DN identity.  The two "encrypted" distinguished
         name types are either encrypted with the Kerberos session key
         or with the private key of the user's digital certificate
         (i.e., digitally signed).  The term "encrypted together with a
         digital signature" is easy to misconceive.  If user identity
         confidentiality is provided, then the policy locator has to be
         encrypted with the public key of the recipient.  How to obtain
         this public key is not described in the document.  This detail
         may be specified in a concrete architecture in which RSVP is
         used.

      o  Credentials

         Two cryptographic credentials are currently defined for a user:
         authentication with Kerberos V5 [<a href="#ref-8" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">8</a>], and authentication with
         the help of digital signatures based on X.509 [<a href="#ref-18" title="&quot;Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types&quot;">18</a>] and PGP
         [<a href="#ref-19" title="&quot;OpenPGP Message Format&quot;">19</a>].  The following list contains all defined credential types
         currently available and defined in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>]:

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

                    Figure 2: Credentials Supported in RSVP.

         The first two credentials contain only a plaintext string, and
         therefore they do not provide cryptographic user
         authentication.  These plaintext strings may be used to
         identify applications, that are included for policy-based
         admission control.  Note that these plain-text identifiers may,
         however, be protected if either the RSVP INTEGRITY or the



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


         INTEGRITY object of the POLICY_DATA element is present.  Note
         that the two INTEGRITY objects can terminate at different
         entities depending on the network structure.  The digital
         signature may also provide protection of application
         identifiers.  A protected application identity (and the entire
         content of the POLICY_DATA element) cannot be modified as long
         as no policy-ignorant nodes are encountered in between.

         A Kerberos session ticket, as previously mentioned, is the
         ticket of a Kerberos AP_REQ message [<a href="#ref-8" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">8</a>] without the
         Authenticator.  Normally, the AP_REQ message is used by a
         client to authenticate to a server.  The INTEGRITY object
         (e.g., of the POLICY_DATA element) provides the functionality
         of the Kerberos Authenticator, namely protecting against replay
         and showing that the user was able to retrieve the session key
         following the Kerberos protocol.  This is, however, only the
         case if the Kerberos session was used for the keyed message
         digest field of the INTEGRITY object.  Section 7 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>]
         discusses some issues for establishment of keys for the
         INTEGRITY object.  The establishment of the security
         association for the RSVP INTEGRITY object with the inclusion of
         the Kerberos Ticket within the AUTH_DATA element may be
         complicated by the fact that the ticket can be decrypted by
         node B, whereas the RSVP INTEGRITY object terminates at a
         different host C.

         The Kerberos session ticket contains, among many other fields,
         the session key.  The Policy Locator may also be encrypted with
         the same session key.  The protocol steps that need to be
         executed to obtain such a Kerberos service ticket are not
         described in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>] and may involve several roundtrips, depending
         on many Kerberos-related factors.  As an optimization, the
         Kerberos ticket does not need to be included in every RSVP
         message, as described in Section 7.1 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  Thus, the
         receiver must store the received service ticket.  If the
         lifetime of the ticket has expired, then a new service ticket
         must be sent.  If the receiver lost its state information
         (because of a crash or restart) then it may transmit an
         Integrity Challenge message to force the sender to re-transmit
         a new service ticket.

         If either the X.509 V3 or the PGP certificate is included in
         the policy element, then a digital signature must be added.
         The digital signature computed over the entire AUTH_DATA object
         provides authentication and integrity protection.  The SubType
         of the digital signature authentication attribute is set to
         zero before computing the digital signature.  Whether or not a
         guarantee of freshness with replay protection (either



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


         timestamps or sequence numbers) is provided by the digital
         signature is an open issue as discussed in <a href="#section-4.3">Section 4.3</a>.

      o  Digital Signature

         The digital signature computed over the contents of the
         AUTH_DATA object must be the last attribute.  The algorithm
         used to compute the digital signature depends on the
         authentication mode listed in the credential.  This is only
         partially true, because, for example, PGP again allows
         different algorithms to be used for computing a digital
         signature.  The algorithm identifier used for computing the
         digital signature is not included in the certificate itself.
         The algorithm identifier included in the certificate only
         serves the purpose of allowing the verification of the
         signature computed by the certificate authority (except for the
         case of self-signed certificates).

      o  Policy Error Object

         The Policy Error Object is used in the case of a failure of
         policy-based admission control or other credential
         verification.  Currently available error messages allow
         notification if the credentials are expired
         (EXPIRED_CREDENTIALS), if the authorization process disallowed
         the resource request (INSUFFICIENT_PRIVILEGES), or if the given
         set of credentials is not supported
         (UNSUPPORTED_CREDENTIAL_TYPE).  The last error message returned
         by the network allows the user's host to discover the type of
         credentials supported.  Particularly for mobile environments
         this might be quite inefficient.  Furthermore, it is unlikely
         that a user supports different types of credentials.  The
         purpose of the error message IDENTITY_CHANGED is unclear.
         Also, the protection of the error message is not discussed in
         [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>].

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  RSVP Integrity Handshake</span>

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



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   is a steady flow of RSVP-protected messages between the two hosts, an
   attacker may find it difficult to inject old messages, because new,
   authenticated messages with higher sequence numbers arrive and get
   stored immediately.

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

                     Integrity Challenge

                  (1) Message (including
    +----------+      a Cookie)            +----------+
    |          |--------------------------&gt;|          |
    |  Node A  |                           |  Node B  |
    |          |&lt;--------------------------|          |
    +----------+      Integrity Response   +----------+
                  (2) Message (including
                      the Cookie and the
                      INTEGRITY object)

                    Figure 3: RSVP Integrity Handshake.

   The details of the messages are as follows:

      CHALLENGE:=(Key Identifier, Challenge Cookie)

      Integrity Challenge Message:=(Common Header, CHALLENGE)

      Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)

   The "Challenge Cookie" is suggested to be a MD5 hash of a local
   secret and a timestamp [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].

   The Integrity Challenge message is not protected with an INTEGRITY
   object as shown in the protocol flow above.  As explained in <a href="#section-10">Section</a>
   <a href="#section-10">10</a> of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>] this was done to avoid problems in situations where both
   communicating parties do not have a valid starting sequence number.

   Using the RSVP Integrity Handshake protocol is recommended although
   it is not mandatory (because it may not be needed in all network
   environments).









<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Detailed Security Property Discussion</span>

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

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Network Topology</span>

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

                            +--------+
                            | Policy |
                       +----|Decision|
                       |    | Point  +---+
                       |    +--------+   |
                       |                 |
                       |                 |
     +------+       +-+----+        +---+--+          +------+
     |Client|       |Router|        |Router|          |Client|
     |  A   +-------+  1   +--------+  2   +----------+  B   |
     +------+       +------+        +------+          +------+

                     Figure 4: Simple RSVP Architecture.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Host/Router</span>

   When considering authentication in RSVP, it is important to make a
   distinction between user and host authentication of the signaling
   messages.  The host is authenticated using the RSVP INTEGRITY object,
   whereas credentials inside the AUTH_DATA object can be used to
   authenticate the user.  In this section, the focus is on host
   authentication, whereas the next section covers user authentication.

   (1) Authentication

       The term "host authentication" is used above, because the
       selection of the security association is bound to the host's IP



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       address, as mentioned in <a href="#section-3.1">Section 3.1</a> and <a href="#section-3.2">Section 3.2</a>.  Depending
       on the key management protocol used to create this security
       association and the identity used, it is also possible to bind a
       user identity to this security association.  Because the key
       management protocol is not specified, it is difficult to evaluate
       this part, and hence we speak about data-origin authentication
       based on the host's identity for RSVP INTEGRITY objects.  The
       fact that the host identity is used for selecting the security
       association has already been described in <a href="#section-3.1">Section 3.1</a>.

       Data-origin authentication is provided with a keyed hash value
       computed over the entire RSVP message, excluding the keyed
       message digest field itself.  The security association used
       between the user's host and the first-hop router is, as
       previously mentioned, not established by RSVP, and it must
       therefore be available before signaling is started.

       *  Kerberos for the RSVP INTEGRITY object

          As described in Section 7 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>], 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 [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>]. [<a href="#ref-20" title="&quot;Distributing Kerberos KDC and Realm Information with DNS&quot;">20</a>] describes a way to
          distribute principal and realm information via DNS, which can
          be used for this purpose (assuming that the FQDN or the IP
          address of the other node for which this information is
          desired is known).  All that is required is to encapsulate the
          Kerberos ticket inside the policy element.  It is furthermore
          mentioned that Kerberos tickets with expired lifetime must not
          be used, and the initiator is responsible for requesting and
          exchanging a new service ticket before expiration.

          RSVP multicast processing in combination with Kerberos
          involves additional considerations.  Section 7 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>] states
          that in the multicast case all receivers must share a single
          key with the Kerberos Authentication Server (i.e., a single
          principal used for all receivers).  From a personal discussion
          with Rodney Hess, it seems that there is currently no other
          solution available in the context of Kerberos.  Multicast
          handling therefore leaves some open questions in this context.

          In the case where one entity crashed, the established security
          association is lost and therefore the other node must
          retransmit the service ticket.  The crashed entity can use an
          Integrity Challenge message to request a new Kerberos ticket
          to be retransmitted by the other node.  If a node receives
          such a request, then a reply message must be returned.




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   (2) Integrity protection

       Integrity protection between the user's host and the first-hop
       router is based on the RSVP INTEGRITY object.  HMAC-MD5 is
       preferred, although other keyed hash functions may also be used
       within the RSVP INTEGRITY object.  In any case, both
       communicating entities must have a security association that
       indicates the algorithm to use.  This may, however, be difficult,
       because no negotiation protocol is defined to agree on a specific
       algorithm.  Hence, if RSVP is used in a mobile environment, it is
       likely that HMAC-MD5 is the only usable algorithm for the RSVP
       INTEGRITY object.  Only in local environments may it be useful to
       switch to a different keyed hash algorithm.  The other possible
       alternative is that every implementation support the most
       important keyed hash algorithms. e.g., MD5, SHA-1, RIPEMD-160,
       etc.  HMAC-MD5 was chosen mainly because of its performance
       characteristics.  The weaknesses of MD5 [<a href="#ref-21" title="&quot;RIPEMD-160: A strengthened version of RIPEMD in Fast Software Encryption&quot;">21</a>] are known and were
       initially described in [<a href="#ref-22" title="&quot;The Status of MD5 After a Recent Attack&quot;">22</a>].  Other algorithms like SHA-1 [<a href="#ref-15" title="&quot;Secure Hash Standard, NIST, FIPS PUB 180-1&quot;">15</a>]
       and RIPEMD-160 [<a href="#ref-21" title="&quot;RIPEMD-160: A strengthened version of RIPEMD in Fast Software Encryption&quot;">21</a>] have stronger security properties.

   (3) Replay Protection

       The main mechanism used for replay protection in RSVP is based on
       sequence numbers, whereby the sequence number is included in the
       RSVP INTEGRITY object.  The properties of this sequence number
       mechanism are described in Section 3.1 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  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 [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  We assume that this is an oversight.  <a href="#section-4.2">Section</a>
       <a href="#section-4.2">4.2</a> of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>] gives a few comments about the out-of-order delivery
       and the ability of an implementation to specify the replay
       window.  <a href="#appendix-C">Appendix C</a> of [<a href="#ref-3" title="&quot;Security Architecture for the Internet Protocol&quot;">3</a>] describes a window mechanism for
       handling out-of-sequence delivery.

   (4) Integrity Handshake

       The mechanism of the Integrity Handshake is explained in <a href="#section-3.5">Section</a>
       <a href="#section-3.5">3.5</a>.  The Cookie value is suggested to be a hash of a local
       secret and a timestamp.  The Cookie value is not verified by the
       receiver.  The mechanism used by the Integrity Handshake is a
       simple Challenge/Response message, which assumes that the key
       shared between the two hosts survives the crash.  If, however,
       the security association is dynamically created, then this
       assumption may not be true.






<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       In Section 10 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>], the authors note that an adversary can
       create a faked Integrity Handshake message that includes
       challenge cookies.  Subsequently, it could store the received
       response and later try to replay these responses while a
       responder recovers from a crash or restart.  If this replayed
       Integrity Response value is valid and has a lower sequence number
       than actually used, then this value is stored at the recovering
       host.  In order for this attack to be successful, the adversary
       must either have collected a large number of challenge/response
       value pairs or have "discovered" the cookie generation mechanism
       (for example by knowing the local secret).  The collection of
       Challenge/Response pairs is even more difficult, because they
       depend on the Cookie value, the sequence number included in the
       response message, and the shared key used by the INTEGRITY
       object.

   (5) Confidentiality

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

   (6) Authorization

       The task of authorization consists of two subcategories: network
       access authorization and RSVP request authorization.  Access
       authorization is provided when a node is authenticated to the
       network, e.g., using EAP [<a href="#ref-23" title="&quot;Extensible Authentication Protocol (EAP)&quot;">23</a>] in combination with AAA protocols
       (for example, RADIUS [<a href="#ref-24" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">24</a>] or DIAMETER [<a href="#ref-9" title="&quot;Diameter Base Protocol&quot;">9</a>]).  Issues related to
       network access authentication and authorization are outside the
       scope of RSVP.

       The second authorization refers to RSVP itself.  Depending on the
       network configuration:

       *  the router either forwards the received RSVP request to the
          policy decision point (e.g., using COPS [<a href="#ref-10" title="&quot;The COPS (Common Open Policy Service) Protocol&quot;">10</a>] and [<a href="#ref-11" title="&quot;COPS usage for RSVP&quot;">11</a>]) to
          request that an admission control procedure be executed, or





<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       *  the router supports the functionality of a PDP and, therefore,
          there is no need to forward the request, or

       *  the router may already be configured with the appropriate
          policy information to decide locally whether to grant this
          request.

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

   (7) Performance

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

       Dynamic key management, which is computationally more demanding,
       is more important for scalability.  Because RSVP does not specify
       a particular key exchange protocol, it is difficult to estimate
       the effort needed to create the required security associations.
       Furthermore, the number of key exchanges to be triggered depends
       on security policy issues like lifetime of a security
       association, required security properties of the key exchange
       protocol, authentication mode used by the key exchange protocol,
       etc.  In a stationary environment with a single administrative
       domain, manual security association establishment may be
       acceptable and may provide the best performance characteristics.
       In a mobile environment, asymmetric authentication methods are
       likely to be used with a key exchange protocol, and some sort of
       public key or certificate verification needs to be supported.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  User to PEP/PDP</span>

   As noted in the previous section, RSVP supports both user-based and
   host-based authentication.  Using RSVP, a user may authenticate to
   the first hop router or to the PDP as specified in [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>], depending on
   the infrastructure provided by the network domain or the architecture
   used (e.g., the integration of RSVP and Kerberos V5 into the Windows
   2000 Operating System [<a href="#ref-25" title="&quot;Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems&quot;">25</a>]).  Another architecture in which RSVP is
   tightly integrated is the one specified by the PacketCable
   organization.  The interested reader is referred to [<a href="#ref-26" title="&quot;PacketCable Security Specification, PKT-SP-SEC-I01-991201&quot;">26</a>] for a
   discussion of their security architecture.




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   (1) Authentication

       When a user sends an RSVP PATH or RESV message, this message may
       include some information to authenticate the user. [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>] describes
       how user and application information is embedded into the RSVP
       message (AUTH_DATA object) and how to protect it.  A router
       receiving such a message can use this information to authenticate
       the client and forward the user or application information to the
       policy decision point (PDP).  Optionally, the PDP itself can
       authenticate the user, which is described in the next section.
       To be able to authenticate the user, to verify the integrity, and
       to check for replays, the entire POLICY_DATA element has to be
       forwarded from the router to the PDP (e.g., by including the
       element into a COPS message).  It is assumed, although not
       clearly specified in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], that the INTEGRITY object within the
       POLICY_DATA element is sent to the PDP along with all other
       attributes.

       *  Certificate Verification

          Using the policy element as described in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], 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 [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>] and hence a number of
          them can be used for this purpose.  For certificate
          verification, the network element (a router or the policy
          decision point) that has to authenticate the user could
          frequently download certificate revocation lists or use a
          protocol like the Online Certificate Status Protocol (OCSP)
          [<a href="#ref-27" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">27</a>] and the Simple Certificate Validation Protocol (SCVP)
          [<a href="#ref-28" title="&quot;Simple Certificate Validation Protocol (SCVP)&quot;">28</a>] to determine the current status of a digital certificate.

       *  User Authentication to the PDP

          This alternative authentication procedure uses the PDP to
          authenticate the user instead of the first-hop router.  In
          Section 4.2.1 of [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], the choice is given for the user to
          obtain a session ticket either for the next hop router or for
          the PDP.  As noted in the same section, the identity of the
          PDP or the next hop router is statically configured or
          dynamically retrieved.  Subsequently, user authentication to
          the PDP is considered.

       *  Kerberos-based Authentication to the PDP

          If Kerberos is used to authenticate the user, then a session
          ticket for the PDP must be requested first.  A user who roams



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


          between different routers in the same administrative domain
          does not need to request a new service ticket, because the
          same PDP is likely to be used by most or all first-hop routers
          within the same administrative domain.  This is different from
          the case in which a session ticket for a router has to be
          obtained and authentication to a router is required.  The
          router therefore plays a passive role of simply forwarding the
          request to the PDP and executing the policy decision returned
          by the PDP.  <a href="#appendix-B">Appendix B</a> describes one example of user-to-PDP
          authentication.

          User authentication with the policy element provides only
          unilateral authentication, whereby the client authenticates to
          the router or to the PDP.  If an RSVP message is sent to the
          user's host and public-key-based authentication is not used,
          then the message does not contain a certificate and digital
          signature.  Hence, no mutual authentication can be assumed.
          In case of Kerberos, mutual authentication may be accomplished
          if the PDP or the router transmits a policy element with an
          INTEGRITY object computed with the session key retrieved from
          the Kerberos ticket, or if the Kerberos ticket included in the
          policy element is also used for the RSVP INTEGRITY object as
          described in <a href="#section-4.2">Section 4.2</a>.  This procedure only works if a
          previous message was transmitted from the end host to the
          network and such key is already established.  Reference [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>]
          does not discuss this issue, and therefore there is no
          particular requirement for transmitting network-specific
          credentials back to the end-user's host.

   (2) Integrity Protection

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

       *  Kerberos

          If Kerberos is used to authenticate the user to the first hop
          router, then the session key included in the Kerberos ticket
          may be used to compute the INTEGRITY object of the policy
          element.  It is the keyed message digest that provides the
          authentication.  The existence of the Kerberos service ticket
          inside the AUTH_DATA object does not provide authentication or
          a guarantee of freshness for the receiving host.



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


          Authentication and guarantee of freshness are provided by the
          keyed hash value of the INTEGRITY object inside the
          POLICY_DATA element.  This shows that the user actively
          participated in the Kerberos protocol and was able to obtain
          the session key to compute the keyed message digest.  The
          Authenticator used in the Kerberos V5 protocol provides
          similar functionality, but replay protection is based on
          timestamps (or on a sequence number if the optional seq-number
          field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
          messages as described in Section 5.3.2 of [<a href="#ref-8" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">8</a>]).

       *  Digital Signature

          If public-key-based authentication is provided, then user
          authentication is accomplished with a digital signature.  As
          explained in Section 3.3.3 of [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], the DIGITAL_SIGNATURE
          attribute must be the last attribute in the AUTH_DATA object,
          and the digital signature covers the entire AUTH_DATA object.
          In the case of PGP, which hash algorithm and public key
          algorithm are used for the digital signature computation is
          described in [<a href="#ref-19" title="&quot;OpenPGP Message Format&quot;">19</a>].  In the case of X.509 credentials, the
          situation is more complex because different mechanisms like
          CMS [<a href="#ref-29" title="&quot;Cryptographic Message Syntax (CMS)&quot;">29</a>] or PKCS#7 [<a href="#ref-30" title="&quot;PKCS #7: Cryptographic Message Syntax Version 1.5&quot;">30</a>] may be used for digitally signing the
          message element.  X.509 only provides the standard for the
          certificate layout, which seems to provide insufficient
          information for this purpose.  Therefore, X.509 certificates
          are supported, for example, by CMS or PKCS#7. [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>], however,
          does not make any statements about the usage of CMS or PKCS#7.
          Currently, there is no support for CMS or for PKCS#7 [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>],
          which provides more than just public-key-based authentication
          (e.g., CRL distribution, key transport, key agreement, etc.).
          Furthermore, the use of PGP in RSVP is vaguely defined,
          because there are different versions of PGP (including OpenPGP
          [<a href="#ref-19" title="&quot;OpenPGP Message Format&quot;">19</a>]), and no indication is given as to which should be used.

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

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

             For the digital signature case, only the replay protection
             provided by the digital signature algorithm can be used.
             It is not clear, however, whether this usage was
             anticipated or not.  Hence, we might assume that replay



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


             protection is based on the availability of the RSVP
             INTEGRITY object used with a security association that is
             established by other means.

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

   (3) Replay Protection

       Figure 5 shows the interfaces relevant for replay protection of
       signaling messages in a more complicated architecture.  In this
       case, the client uses the policy data element with PEP2, because
       PEP1 is not policy-aware.  The interfaces between the client and
       PEP1 and between PEP1 and PEP2 are protected with the RSVP
       INTEGRITY object.  The link between the PEP2 and the PDP is
       protected, for example, by using the COPS built-in INTEGRITY
       object.  The dotted line between the Client and the PDP indicates
       the protection provided by the AUTH_DATA element, which has no
       RSVP INTEGRITY object included.

                        AUTH_DATA                         +----+
      +---------------------------------------------------+PDP +-+
      |                                                   +----+ |
      |                                                          |
      |                                                          |
      |                                                 COPS     |
      |                                                 INTEGRITY|
      |                                                          |
      |                                                          |
      |                                                          |
   +--+---+   RSVP INTEGRITY  +----+    RSVP INTEGRITY    +----+ |
   |Client+-------------------+PEP1+----------------------+PEP2+-+
   +--+---+                   +----+                      +-+--+
      |                                                     |
      +-----------------------------------------------------+
                       POLICY_DATA INTEGRITY

                       Figure 5: Replay Protection.

       Host authentication with the RSVP INTEGRITY object and user
       authentication with the INTEGRITY object inside the POLICY_DATA
       element both use the same anti-replay mechanism.  The length of




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       the Sequence Number field, sequence number rollover, and the
       Integrity Handshake have already been explained in <a href="#section-3.1">Section 3.1</a>.

       Section 9 of [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>] states: "RSVP INTEGRITY object is used to
       protect the policy object containing user identity information
       from security (replay) attacks."  When using public-key-based
       authentication, RSVP-based replay protection is not supported,
       because the digital signature does not cover the POLICY_DATA
       INTEGRITY object with its Sequence Number field.  The digital
       signature covers only the entire AUTH_DATA object.

       The use of public key cryptography within the AUTH_DATA object
       complicates replay protection.  Digital signature computation
       with PGP is described in [<a href="#ref-31" title="&quot;Specifications and standard documents&quot;">31</a>] and in [<a href="#ref-19" title="&quot;OpenPGP Message Format&quot;">19</a>].  The data structure
       preceding the signed message digest includes information about
       the message digest algorithm used and a 32-bit timestamp of when
       the signature was created ("Signature creation time").  The
       timestamp is included in the computation of the message digest.
       The IETF standardized version of OpenPGP [<a href="#ref-19" title="&quot;OpenPGP Message Format&quot;">19</a>] contains more
       information and describes the different hash algorithms (MD2,
       MD5, SHA-1, RIPEMD-160) supported. [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>] does not make any
       statements as to whether the "Signature creation time" field is
       used for replay protection.  Using timestamps for replay
       protection requires different synchronization mechanisms in the
       case of clock-skew.  Traditionally, these cases assume "loosely
       synchronized" clocks but also require specifying a replay window.

       If the "Signature creation time" is not used for replay
       protection, then a malicious, policy-ignorant node can use this
       weakness to replace the AUTH_DATA object without destroying the
       digital signature.  If this was not simply an oversight, it is
       therefore assumed that replay protection of the user credentials
       was not considered an important security requirement, because the
       hop-by-hop processing of the RSVP message protects the message
       against modification by an adversary between two communicating
       nodes.

       The lifetime of the Kerberos ticket is based on the fields
       starttime and endtime of the EncTicketPart structure in the
       ticket, as described in Section 5.3.1 of [<a href="#ref-8" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">8</a>].  Because the ticket
       is created by the KDC located at the network of the verifying
       entity, it is not difficult to have the clocks roughly
       synchronized for the purpose of lifetime verification.
       Additional information about clock-synchronization and Kerberos
       can be found in [<a href="#ref-32" title="&quot;Kerberos With Clocks Adrift: History, Protocols and Implementation&quot;">32</a>].






<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


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

   (4) (User Identity) Confidentiality

       This section discusses privacy protection of identity information
       transmitted inside the policy element.  User identity
       confidentiality is of particular interest because there is no
       built-in RSVP mechanism for encrypting the POLICY_DATA object or
       the AUTH_DATA elements.  Encryption of one of the attributes
       inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
       discussed.

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

       The ASCII or Unicode distinguished name of the user or
       application inside the POLICY_LOCATOR attribute of the AUTH_DATA
       element may be encrypted as specified in Section 3.3.1 of [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>].
       The user (or application) identity is then encrypted with either
       the Kerberos session key or with the private key in case of
       public-key-based authentication.  When the private key is used,
       we usually speak of a digital signature that can be verified by
       everyone possessing the public key.  Because the certificate with
       the public key is included in the message itself, decryption is
       no obstacle.  Furthermore, the included certificate together with
       the additional (unencrypted) information in the RSVP message
       provides enough identity information for an eavesdropper.  Hence,
       the possibility of encrypting the policy locator in case of
       public-key-based authentication is problematic.  To encrypt the
       identities using asymmetric cryptography, the user's host must be
       able somehow to retrieve the public key of the entity verifying
       the policy element (i.e., the first policy-aware router or the
       PDP).  Then, this public key could be used to encrypt a symmetric
       key, which in turn encrypts the user's identity and certificate,
       as is done, e.g., by PGP.  Currently, no such mechanism is
       defined in [<a href="#ref-7" title="&quot;Identity Representation for RSVP&quot;">7</a>].




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       The algorithm used to encrypt the POLICY_LOCATOR with the
       Kerberos session key is assumed to be the same as the one used
       for encrypting the service ticket.  The information about the
       algorithm used is available in the etype field of the
       EncryptedData ASN.1 encoded message part.  Section 6.3 of [<a href="#ref-8" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">8</a>]
       lists the supported algorithms. [<a href="#ref-33" title="&quot;Encryption and Checksum Specifications for Kerberos 5&quot;">33</a>] defines newer encryption
       algorithms (Rijndael, Serpent, and Twofish).

       Evaluating user identity confidentiality also requires looking at
       protocols executed outside of RSVP (for example, the Kerberos
       protocol).  The ticket included in the CREDENTIAL attribute may
       provide user identity protection by not including the optional
       cname attribute inside the unencrypted part of the Ticket.
       Because the Authenticator is not transmitted with the RSVP
       message, the cname and the crealm of the unencrypted part of the
       Authenticator are not revealed.  In order for the user to request
       the Kerberos session ticket for inclusion in the CREDENTIAL
       attribute, the Kerberos protocol exchange must be executed.  Then
       the Authenticator sent with the TGS_REQ reveals the identity of
       the user.  The AS_REQ must also include the user's identity to
       allow the Kerberos Authentication Server to respond with an
       AS_REP message that is encrypted with the user's secret key.
       Using Kerberos, it is therefore only possible to hide the content
       of the encrypted policy locator, which is only useful if this
       value differs from the Kerberos principal name.  Hence, using
       Kerberos it is not "entirely" possible to provide user identity
       confidentiality.

       It is important to note that information stored in the policy
       element may be changed by a policy-aware router or by the policy
       decision point.  Which parts are changed depends upon whether
       multicast or unicast is used, how the policy server reacts, where
       the user is authenticated, whether the user needs to be re-
       authenticated in other network nodes, etc.  Hence, user-specific
       and application-specific information can leak after the messages
       leave the first hop within the network where the user's host is
       attached.  As mentioned at the beginning of this section, this
       information leakage is assumed to be intentional.

   (5) Authorization

       In addition to the description of the authorization steps of the
       Host-to-Router interface, user-based authorization is performed
       with the policy element providing user credentials.  The
       inclusion of user and application specific information enables
       policy-based admission control with special user policies that
       are likely to be stored at a dedicated server.  Hence, a Policy
       Decision Point can query, for example, an LDAP server for a



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       service level agreement that states the amount of resources a
       certain user is allowed to request.  In addition to the user
       identity information, group membership and other non-security-
       related information may contribute to the evaluation of the final
       policy decision.  If the user is not registered to the currently
       attached domain, then there is the question of how much
       information the home domain of the user is willing to exchange.
       This also impacts the user's privacy policy.

       In general, the user may not want to distribute much of this
       policy information.  Furthermore, the lack of a standardized
       authorization data format may create interoperability problems
       when exchanging policy information.  Hence, we can assume that
       the policy decision point may use information from an initial
       authentication and key agreement protocol (which may have already
       required cross-realm communication with the user's home domain,
       if only to show that the home domain knows the user and that the
       user is entitled to roam), to forward accounting messages to this
       domain.  This represents the traditional subscriber-based
       accounting scenario.  Non-traditional or alternative means of
       access might be deployed in the near future that do not require
       any type of inter-domain communication.

       Additional discussions are required to determine the expected
       authorization procedures. [<a href="#ref-34" title="&quot;NSIS Authentication, Authorization and Accounting Issues&quot;">34</a>] and [<a href="#ref-35" title="&quot;QoS NSLP Authorization Issues&quot;">35</a>] discuss authorization
       issues for QoS signaling protocols.  Furthermore, a number of
       mobility implications for policy handling in RSVP are described
       in [<a href="#ref-36" title="&quot;Analysis of Mobile IP and RSVP Interactions&quot;">36</a>].

   (6) Performance

       If Kerberos is used for user authentication, then a Kerberos
       ticket must be included in the CREDENTIAL Section of the
       AUTH_DATA element.  The Kerberos ticket has a size larger than
       500 bytes, but it only needs to be sent once because a
       performance optimization allows the session key to be cached as
       noted in Section 7.1 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>].  It is assumed that subsequent RSVP
       messages only include the POLICY_DATA INTEGRITY object with a
       keyed message digest that uses the Kerberos session key.
       However, this assumes that the security association required for
       the POLICY_DATA INTEGRITY object is created (or modified) to
       allow the selection of the correct key.  Otherwise, it difficult
       to say which identifier is used to index the security
       association.

       If Kerberos is used as an authentication system then, from a
       performance perspective, the message exchange to obtain the
       session key needs to be considered, although the exchange only



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


       needs to be done once in the lifetime of the session ticket.
       This is particularly true in a mobile environment with a fast
       roaming user's host.

       Public-key-based authentication usually provides the best
       scalability characteristics for key distribution, but the
       protocols are performance demanding.  A major disadvantage of the
       public-key-based user authentication in RSVP is the lack of a
       method to derive a session key.  Hence, every RSVP PATH or RESV
       message includes the certificate and a digital signature, which
       is a huge performance and bandwidth penalty.  For a mobile
       environment with low power devices, high latency, channel noise,
       and low-bandwidth links, this seems to be less encouraging.  Note
       that a public key infrastructure is required to allow the PDP (or
       the first-hop router) to verify the digital signature and the
       certificate.  To check for revoked certificates, certificate
       revocation lists or protocols like the Online Certificate Status
       Protocol [<a href="#ref-27" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">27</a>] and the Simple Certificate Validation Protocol [<a href="#ref-28" title="&quot;Simple Certificate Validation Protocol (SCVP)&quot;">28</a>]
       are needed.  Then the integrity of the AUTH_DATA object can be
       verified via the digital signature.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Communication between RSVP-Aware Routers</span>

   (1) Authentication

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

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

   (2) Integrity Protection

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



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   (3) Replay Protection

       Replay protection with the RSVP INTEGRITY object is extensively
       described in previous sections.  To enable crashed hosts to learn
       the latest sequence number used, the Integrity Handshake
       mechanism is provided in RSVP.

   (4) Confidentiality

       Confidentiality is not provided by RSVP.

   (5) Authorization

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

   (6) Performance

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

       The security associations within the core network, that is,
       between individual routers (in comparison with the security
       association between the user's host and the first-hop router or
       with the attached network in general), can be established more
       easily because of the normally strong trust assumptions.
       Furthermore, it is possible to use security associations with an
       increased lifetime to avoid frequent rekeying.  Hence, there is
       less impact on the performance compared with the user-to-network
       interface.  The security association storage requirements are
       also less problematic.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Miscellaneous Issues</span>

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







<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  First-Hop Issue</span>

   In case of end-to-end signaling, an end host starts signaling to its
   attached network.  The first-hop communication is often more
   difficult to secure because of the different requirements and a
   missing trust relationship.  An end host must therefore obtain some
   information to start RSVP signaling:

       o  Does this network support RSVP signaling?

       o  Which node supports RSVP signaling?

       o  To which node is authentication required?

       o  Which security mechanisms are used for authentication?

       o  Which algorithms are required?

       o  Where should the keys and security associations come from?

       o  Should a security association be established?

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

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Next-Hop Problem</span>

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














<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


                      Integrity
                          (A&lt;-&gt;C)               +------+
                                      (3)       | RSVP |
                                 +-------------&gt;+ Node |
                                 |              |  B   |
                    Integrity    |              +--+---+
                     (A&lt;-&gt;C)     |                 |
          +------+    (2)     +--+----+            |
     (1)  | RSVP +-----------&gt;+Router |            |  Error
    -----&gt;| Node |            | or    +&lt;-----------+ (I am B)
          |  A   +&lt;-----------+Network|       (4)
          +------+    (5)     +--+----+
                     Error       .
                    (I am B)     .              +------+
                                 .              | RSVP |
                                 ...............+ Node |
                                                |  C   |
                                                +------+

                         Figure 6: Next-Hop Issue.

   When RSVP node A in Figure 6 receives an incoming RSVP Path message,
   standard RSVP message processing takes place.  Node A then has to
   decide which key to select to protect the signaling message.  We
   assume that some unspecified mechanism is used to make this decision.
   In this example, node A assumes that the message will travel to RSVP
   node C.  However, for some reasons (e.g., a route change, inability
   to learn the next RSVP hop along the path, etc.) the message travels
   to node B via a non-RSVP supporting router that cannot verify the
   integrity of the message (or cannot decrypt the Kerberos service
   ticket).  The processing failure causes a PathErr message to be
   returned to the originating sender of the Path message.  This error
   message also contains information about the node that recognized the
   error.  In many cases, a security association might not be available.
   Node A receiving the PathErr message might use the information
   returned with the PathErr message to select a different security
   association (or to establish one).

   Figure 6 describes a behavior that might help node A learn that an
   error occurred.  However, the description in Section 4.2 of [<a href="#ref-1" title="&quot;RSVP Cryptographic Authentication&quot;">1</a>]
   states in step (5) that a signaling message is silently discarded if
   the receiving host cannot properly verify the message: "If the
   calculated digest does not match the received digest, the message is
   discarded without further processing."  For RSVP Path and similar
   messages, this functionality is not really helpful.






<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


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

   From a security point of view, there are conflicts between:

   o  Idempotent message delivery and efficiency

      The RSVP Path message especially performs a number of functions.
      Supporting idempotent message delivery somehow contradicts with
      security association establishment, efficient message delivery,
      and message size.  For example, a "real" idempotent signaling
      message would contain enough information to perform security
      processing without depending on a previously executed message
      exchange.  Adding a Kerberos ticket with every signaling message
      is, however, inefficient.  Using public-key-based mechanisms is
      even more inefficient when included in every signaling message.
      With public-key-based protection for idempotent messages, there is
      the additional risk of introducing denial-of-service attacks.

   o  RSVP Path message functionality and next-hop discovery

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

      It is fair to assume that an RSVP-supporting node might not have
      security associations with all immediately neighboring RSVP nodes.
      Especially for inter-domain signaling, IntServ over DiffServ, or
      some new applications such as firewall signaling, the next RSVP-
      aware node might not be known in advance.  The number of next RSVP
      nodes might be considerably large if they are separated by a large
      number of non-RSVP aware nodes.  Hence, a node transmitting an
      RSVP Path message might experience difficulties in properly
      protecting the message if it serves as a mechanism to detect both
      the next RSVP node (i.e., Router Alert Option added to the
      signaling message and addressed to the destination address) and to
      detect route changes.  It is fair to note that, in the intra-




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


      domain case with a dense distribution of RSVP nodes, protection
      might be possible with manual configuration.

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

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Last-Hop Issue</span>

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

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

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

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

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





<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


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

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  RSVP- and IPsec-Protected Data Traffic</span>

   QoS signaling requires flow information to be established at routers
   along a path.  This flow identifier installed at each device tells
   the router which data packets should receive QoS treatment.  RSVP
   typically establishes a flow identifier based on the 5-tuple (source
   IP address, destination IP address, transport protocol type, source
   port, and destination port).  If this 5-tuple information is not
   available, then other identifiers have to be used.  ESP-encrypted
   data traffic is such an example where the transport protocol and the
   port numbers are not accessible.  Hence, the IPsec SPI is used as a
   substitute for them. [<a href="#ref-12" title="&quot;RSVP Extensions for IPSEC Data Flows&quot;">12</a>] considers these IPsec implications for RSVP
   and is based on three assumptions:

   (1) An end host that initiates the RSVP signaling message exchange
       has to be able to retrieve the SPI for a given flow.  This
       requires some interaction with the IPsec security association
       database (SAD) and security policy database (SPD) [<a href="#ref-3" title="&quot;Security Architecture for the Internet Protocol&quot;">3</a>].  An
       application usually does not know the SPI of the protected flow
       and cannot provide the desired values.  It can provide the
       signaling protocol daemon with flow identifiers.  The signaling
       daemon would then need to query the SAD by providing the flow
       identifiers as input parameters and receiving the SPI as an
       output parameter.

   (2) [<a href="#ref-12" title="&quot;RSVP Extensions for IPSEC Data Flows&quot;">12</a>] assumes end-to-end IPsec protection of the data traffic.  If
       IPsec is applied in a nested fashion, then parts of the path do
       not experience QoS treatment.  This can be treated as a problem
       of tunneling that is initiated by the end host.  The following
       figure better illustrates the problem in the case of enforcing
       secure network access:









<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


    +------+          +---------------+      +--------+          +-----+
    | Host |          | Security      |      | Router |          | Host|
    |  A   |          | Gateway (SGW) |      |   Rx   |          |  B  |
    +--+---+          +-------+-------+      +----+---+          +--+--+
       |                      |                   |                 |
       |IPsec-Data(           |                   |                 |
       | OuterSrc=A,          |                   |                 |
       | OuterDst=SGW,        |                   |                 |
       | SPI=SPI1,            |                   |                 |
       | InnerSrc=A,          |                   |                 |
       | InnerDst=B,          |                   |                 |
       | Protocol=X,          |IPsec-Data(        |                 |
       | SrcPort=Y,           | SrcIP=A,          |                 |
       | DstPort=Z)           | DstIP=B,          |                 |
       |=====================&gt;| Protocol=X,       |IPsec-Data(      |
       |                      | SrcPort=Y,        | SrcIP=A,        |
       | --IPsec protected-&gt;  | DstPort=Z)        | DstIP=B,        |
       |    data traffic      |------------------&gt;| Protocol=X,     |
       |                      |                   | SrcPort=Y,      |
       |                      |                   | DstPort=Z)      |
       |                      |                   |----------------&gt;|
       |                      |                   |                 |
       |                      |     --Unprotected data traffic---&gt;  |
       |                      |                   |                 |

              Figure 7: RSVP and IPsec protected data traffic.

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

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

       IPsec tunnels that neither start nor terminate at one of the
       signaling end points (for example between two networks) should be
       addressed differently by recursively applying an RSVP signaling
       exchange for the IPsec tunnel.  RSVP signaling within tunnels is
       addressed in [<a href="#ref-13" title="&quot;RSVP Operation Over IP Tunnels&quot;">13</a>].






<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   (3) It is assumed that SPIs do not change during the lifetime of the
       established QoS reservation.  If a new IPsec SA is created, then

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

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.   End-to-End Security Issues and RSVP</span>

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

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  IPsec Protection of RSVP Signaling Messages</span>

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



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   RSVP messages are transmitted as raw IP packets with protocol number
   46.  It might be possible to encapsulate them in UDP as described in
   <a href="#appendix-C">Appendix C</a> of [<a href="#ref-6" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">6</a>].  Some RSVP messages (Path, PathTear, and ResvConf)
   must have the Router Alert IP Option set in the IP header.  These
   messages are addressed to the (unicast or multicast) destination
   address and not to the next RSVP node along the path.  Hence, an
   IPsec traffic selector can only use these fields for IPsec SA
   selection.  If there is only a single path (and possibly all traffic
   along it is protected) then there is no problem for IPsec protection
   of signaling messages.  This type of protection is not common and
   might only be used to secure network access between an end host and
   its first-hop router.  Because the described RSVP messages are
   addressed to the destination address instead of the next RSVP node,
   it is not possible to use IPsec ESP [<a href="#ref-17" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">17</a>] or AH [<a href="#ref-16" title="&quot;IP Authentication Header&quot;">16</a>] in transport
   mode--only IPsec in tunnel mode is possible.

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

   RSVP messages like RESV can be protected by IPsec, because they
   contain enough information to create IPsec traffic selectors that
   allow differentiation between various next RSVP nodes.  The traffic
   selector would then contain the protocol number and the source and
   destination address pair of the two communicating RSVP nodes.

   One benefit of using IPsec is the availability of key management
   using either IKE [<a href="#ref-39" title="&quot;The Internet Key Exchange (IKE)&quot;">39</a>], KINK [<a href="#ref-40" title="&quot;Kerberized Internet Negotiation of Keys (KINK)&quot;">40</a>] or IKEv2 [<a href="#ref-41" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">41</a>].

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Authorization</span>

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




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   mechanism, but authentication might, in many cases, be insufficient
   for authorization.  The communication procedures defined for policy

   objects [<a href="#ref-42" title="&quot;Accounting and Access Control in RSVP&quot;">42</a>] can be improved to support the more efficient per-
   channel financial settlement model by avoiding policy handling
   between inter-domain networks at a signaling message granularity.
   Additional information about expected behavior of policy handling in
   RSVP can also be obtained from [<a href="#ref-43" title="&quot;Accounting and Access Control for Multicast Distributions: Models and Mechanisms&quot;">43</a>].

   [<a id="ref-35">35</a>] and [<a href="#ref-36" title="&quot;Analysis of Mobile IP and RSVP Interactions&quot;">36</a>] provide additional information on authorization.  No
   good and agreed mechanism for dealing with authorization of QoS
   reservations in roaming environments is provided.  Price distribution
   mechanisms are only described in papers and never made their way
   through standardization.  RSVP focuses on receiver-initiated
   reservations with authorization for the QoS reservation by the data
   receiver, which introduces a fair amount of complexity for mobility
   handling as described, for example, in [<a href="#ref-36" title="&quot;Analysis of Mobile IP and RSVP Interactions&quot;">36</a>].

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Conclusions</span>

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

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

   Certainly this document is not a complete description of all security
   issues related to RSVP.  Some issues that require further
   consideration are RSVP extensions (for example [<a href="#ref-12" title="&quot;RSVP Extensions for IPSEC Data Flows&quot;">12</a>]), multicast
   issues, and other security properties like traffic analysis.
   Additionally, the interaction with mobility protocols (micro- and
   macro-mobility) demands further investigation from a security point
   of view.

   What can be learned from practical protocol experience and from the
   increased awareness regarding security is that some of the available
   credential types have received more acceptance than others.  Kerberos
   is a system that is integrated into many IETF protocols today.
   Public-key-based authentication techniques are, however, still
   considered to be too heavy-weight (computationally and from a
   bandwidth perspective) to be used for per-flow signaling.  The
   increased focus on denial of service attacks puts additional demands
   on the design of public-key-based authentication.




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


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

   o  Discovery and signaling message delivery should be separated.

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

   o  Addressing for signaling messages should be done in a hop-by-hop
      fashion.

   o  Standard security protocols (IPsec, TLS, or CMS) should be used
      whenever possible.  Authentication and key exchange should be
      separated from signaling message protection.  In general, it is
      necessary to provide key management to establish security
      associations dynamically for signaling message protection.
      Relying on manually configured keys between neighboring RSVP nodes
      is insufficient.  A separate, less frequently executed key
      management and security association establishment protocol is a
      good place to perform entity authentication, security service
      negotiation and selection, and agreement on mechanisms,
      transforms, and options.

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

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

   o  Public-key-based user authentication only provides entity
      authentication.  An additional security association is required to
      protect signaling messages.

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

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

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





<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


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

   o  Parameter and mechanism negotiation should be provided.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

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

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgements</span>

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

   Finally, we would like to thank Allison Mankin and John Loughney for
   their guidance and input.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-1">1</a>]   Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
         Authentication", <a href="./rfc2747">RFC 2747</a>, January 2000.

   [<a id="ref-2">2</a>]   Herzog, S., "RSVP Extensions for Policy Control", <a href="./rfc2750">RFC 2750</a>,
         January 2000.

   [<a id="ref-3">3</a>]   Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.

   [<a id="ref-4">4</a>]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", <a href="./rfc2104">RFC 2104</a>, February 1997.

   [<a id="ref-5">5</a>]   Rivest, R., "The MD5 Message-Digest Algorithm", <a href="./rfc1321">RFC 1321</a>, April
         1992.

   [<a id="ref-6">6</a>]   Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
         Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.





<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   [<a id="ref-7">7</a>]   Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
         Herzog, S., and R. Hess, "Identity Representation for RSVP",
         <a href="./rfc3182">RFC 3182</a>, October 2001.

   [<a id="ref-8">8</a>]   Kohl, J. and C. Neuman, "The Kerberos Network Authentication
         Service (V5)", <a href="./rfc1510">RFC 1510</a>, September 1993.  Obsoleted by <a href="./rfc4120">RFC</a>
         <a href="./rfc4120">4120</a>.

   [<a id="ref-9">9</a>]   Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
         "Diameter Base Protocol", <a href="./rfc3588">RFC 3588</a>, September 2003.

   [<a id="ref-10">10</a>]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
         Sastry, "The COPS (Common Open Policy Service) Protocol", <a href="./rfc2748">RFC</a>
         <a href="./rfc2748">2748</a>, January 2000.

   [<a id="ref-11">11</a>]  Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
         Sastry, "COPS usage for RSVP", <a href="./rfc2749">RFC 2749</a>, January 2000.

   [<a id="ref-12">12</a>]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
         Flows", <a href="./rfc2207">RFC 2207</a>, September 1997.

   [<a id="ref-13">13</a>]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
         Operation Over IP Tunnels", <a href="./rfc2746">RFC 2746</a>, January 2000.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-14">14</a>]  Hess, R. and S. Herzog, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22RSVP+Extensions+for+Policy+Control%22'>"RSVP Extensions for Policy Control"</a>,
         Work in Progress, June 2001.

   [<a id="ref-15">15</a>]  "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal
         Information Processing Society, April 1995.

   [<a id="ref-16">16</a>]  Kent, S. and R. Atkinson, "IP Authentication Header", <a href="./rfc2402">RFC 2402</a>,
         November 1998.

   [<a id="ref-17">17</a>]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.

   [<a id="ref-18">18</a>]  Fowler, D., "Definitions of Managed Objects for the DS1, E1,
         DS2 and E2 Interface Types", <a href="./rfc2495">RFC 2495</a>, January 1999.

   [<a id="ref-19">19</a>]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
         "OpenPGP Message Format", <a href="./rfc2440">RFC 2440</a>, November 1998.

   [<a id="ref-20">20</a>]  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
         Realm Information with DNS", Work in Progress, July 2002.





<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   [<a id="ref-21">21</a>]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
         strengthened version of RIPEMD in Fast Software Encryption",
         LNCS vol. 1039, pp. 71-82, 1996.

   [<a id="ref-22">22</a>]  Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
         Laboratories CryptoBytes, vol. 2, no. 2, 1996.

   [<a id="ref-23">23</a>]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)", <a href="./rfc3748">RFC</a>
         <a href="./rfc3748">3748</a>, June 2004.

   [<a id="ref-24">24</a>]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
         Authentication Dial In User Service (RADIUS)", <a href="./rfc2865">RFC 2865</a>, June
         2000.

   [<a id="ref-25">25</a>]  "Microsoft Authorization Data Specification v. 1.0 for
         Microsoft Windows 2000 Operating Systems", April 2000.

   [<a id="ref-26">26</a>]  Cable Television Laboratories, Inc., "PacketCable Security
         Specification, PKT-SP-SEC-I01-991201", website:
         <a href="http://www.PacketCable.com/">http://www.PacketCable.com/</a>, June 2003.

   [<a id="ref-27">27</a>]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
         "X.509 Internet Public Key Infrastructure Online Certificate
         Status Protocol - OCSP", <a href="./rfc2560">RFC 2560</a>, June 1999.

   [<a id="ref-28">28</a>]  Malpani, A., Housley, R., and T. Freeman, "Simple Certificate
         Validation Protocol (SCVP)", Work in Progress, October 2005.

   [<a id="ref-29">29</a>]  Housley, R., "Cryptographic Message Syntax (CMS)", <a href="./rfc3369">RFC 3369</a>,
         August 2002.

   [<a id="ref-30">30</a>]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
         1.5", <a href="./rfc2315">RFC 2315</a>, March 1998.

   [<a id="ref-31">31</a>]  "Specifications and standard documents", website:
         <a href="http://www.PacketCable.com/">http://www.PacketCable.com/</a>, March 2002.

   [<a id="ref-32">32</a>]  Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History,
         Protocols and Implementation", USENIX Computing Systems, vol 9
         no. 1, Winter 1996.

   [<a id="ref-33">33</a>]  Raeburn, K., "Encryption and Checksum Specifications for
         Kerberos 5", <a href="./rfc3961">RFC 3961</a>, February 2005.

   [<a id="ref-34">34</a>]  Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
         Schulzrinne, "NSIS Authentication, Authorization and Accounting
         Issues", Work in Progress, March 2003.



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   [<a id="ref-35">35</a>]  Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne,
         H., and T. Chen, "QoS NSLP Authorization Issues", Work in
         Progress, June 2003.

   [<a id="ref-36">36</a>]  Thomas, M., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Analysis+of+Mobile+IP+and+RSVP+Interactions%22'>"Analysis of Mobile IP and RSVP Interactions"</a>, Work
         in Progress, October 2002.

   [<a id="ref-37">37</a>]  Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP
         Proxy", Work in Progress, March 2002.

   [<a id="ref-38">38</a>]  Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K.
         Raatikainen, "Localized RSVP", Work in Progress, September
         2004.

   [<a id="ref-39">39</a>]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         <a href="./rfc2409">RFC 2409</a>, November 1998.

   [<a id="ref-40">40</a>]  Thomas, M., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Kerberized+Internet+Negotiation+of+Keys+%28KINK%29%22'>"Kerberized Internet Negotiation of Keys (KINK)"</a>,
         Work in Progress, October 2005.

   [<a id="ref-41">41</a>]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", <a href="./rfc4306">RFC</a>
         <a href="./rfc4306">4306</a>, November 2005.

   [<a id="ref-42">42</a>]  Herzog, S., "Accounting and Access Control in RSVP", PhD
         Dissertation, USC, Work in Progress, November 1995.

   [<a id="ref-43">43</a>]  Herzog, S., "Accounting and Access Control for Multicast
         Distributions: Models and Mechanisms", June 1996.

   [<a id="ref-44">44</a>]  Pato, J., "Using Pre-Authentication to Avoid Password Guessing
         Attacks", Open Software Foundation DCE Request for Comments,
         December 1992.

   [<a id="ref-45">45</a>]  Tung, B. and L. Zhu, "Public Key Cryptography for Initial
         Authentication in Kerberos", Work in Progress, November 2005.

   [<a id="ref-46">46</a>]  Wu, T., "A Real-World Analysis of Kerberos Password Security",
         in Proceedings of the 1999 Internet Society Network and
         Distributed System Security Symposium, San Diego, February
         1999.

   [<a id="ref-47">47</a>]  Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP
         Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64,
         1999.

   [<a id="ref-48">48</a>]  Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For
         Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia
         Security Workshop), November 2000.



<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   [<a id="ref-49">49</a>]  Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure
         RSVP Protocol", International Conf on Multimedia and
         Exposition, Tokyo, Japan, August 2001.

   [<a id="ref-50">50</a>]  Jablon, D., "Strong Password-only Authenticated Key Exchange",
         ACM Computer Communication Review, 26(5), pp. 5-26, October
         1996.












































<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Dictionary Attacks and Kerberos</span>

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

   The initial Kerberos AS_REQ request (without pre-authentication,
   without various extensions, and without PKINIT) is unprotected.  The
   response message AS_REP is encrypted with the client's long-term key.
   An adversary can take advantage of this fact by requesting AS_REP
   messages to mount an off-line dictionary attack.  Pre-authentication
   ([<a href="#ref-44" title="&quot;Using Pre-Authentication to Avoid Password Guessing Attacks&quot;">44</a>]) can be used to reduce this problem.  However, pre-
   authentication does not entirely prevent dictionary attacks by an
   adversary who can still eavesdrop on Kerberos messages along the path
   between a mobile node and a KDC.  With mandatory pre-authentication
   for the initial request, an adversary cannot request a Ticket
   Granting Ticket for an arbitrary user.  On-line password guessing
   attacks are still possible by choosing a password (e.g., from a
   dictionary) and then transmitting an initial request that includes a
   pre-authentication data field.  An unsuccessful authentication by the
   KDC results in an error message and thus gives the adversary a hint
   to restart the protocol and try a new password.

   There are, however, some proposals that prevent dictionary attacks.
   The use of Public Key Cryptography for initial authentication [<a href="#ref-45" title="&quot;Public Key Cryptography for Initial Authentication in Kerberos&quot;">45</a>]
   (PKINIT) is one such solution.  Other proposals use strong-password-
   based authenticated key agreement protocols to protect the user's
   password during the initial Kerberos exchange. [<a href="#ref-46" title="&quot;A Real-World Analysis of Kerberos Password Security&quot;">46</a>] discusses the
   security of Kerberos and also discusses mechanisms to prevent
   dictionary attacks.

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Example of User-to-PDP Authentication</span>

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

   Windows 2000, which integrates Kerberos into RSVP, uses a
   configuration with the user authentication to the PDP as described in
   [<a href="#ref-25" title="&quot;Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems&quot;">25</a>].  The steps for authenticating the user to the PDP in an intra-
   realm scenario are the following:

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





<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   o  This ticket is then embedded into the AUTH_DATA element and
      included in either the PATH or the RESV message.  In the case of
      Microsoft's implementation, the user identity encoded as a
      distinguished name is encrypted with the session key provided with
      the Kerberos ticket.  The Kerberos ticket is sent without the
      Kerberos authdata element that contains authorization information,
      as explained in [<a href="#ref-25" title="&quot;Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems&quot;">25</a>].

   o  The RSVP message is then intercepted by the PEP, which forwards it
      to the PDP. [<a href="#ref-25" title="&quot;Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems&quot;">25</a>] does not state which protocol is used to forward
      the RSVP message to the PDP.

   o  The PDP that finally receives the message and decrypts the
      received service ticket.  The ticket contains the session key used
      by the user's host to

      *  Encrypt the principal name inside the policy locator field of
         the AUTH_DATA object and to

      *  Create the integrity-protected Keyed Message Digest field in
         the INTEGRITY object of the POLICY_DATA element.  The
         protection described here is between the user's host and the
         PDP.  The RSVP INTEGRITY object on the other hand is used to
         protect the path between the user's host and the first-hop
         router, because the two message parts terminate at different
         nodes, and different security associations must be used.  The
         interface between the message-intercepting, first-hop router
         and the PDP must be protected as well.

      *  The PDP does not maintain a user database, and [<a href="#ref-25" title="&quot;Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems&quot;">25</a>] describes
         how the PDP may query the Active Directory (a LDAP based
         directory service) for user policy information.

<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>.  Literature on RSVP Security</span>

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

   Improvements to RSVP are proposed in [<a href="#ref-47" title="&quot;Securing QoS: Threats to RSVP Messages and Their Countermeasures&quot;">47</a>] to deal with insider
   attacks.  Insider attacks are caused by malicious RSVP routers that
   modify RSVP signaling messages in such a way that they cause harm to
   the nodes participating in the signaling message exchange.

   As a solution, non-mutable RSVP objects are digitally signed by the
   sender.  This digital signature is added to the RSVP PATH message.
   Additionally, the receiver attaches an object to the RSVP RESV
   message containing a "signed" history.  This value allows




<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


   intermediate RSVP routers (by examining the previously signed value)
   to detect a malicious RSVP node.

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

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

   In [<a href="#ref-48" title="&quot;Securing RSVP For Multimedia Applications&quot;">48</a>], the above-described idea of detecting malicious RSVP nodes
   is improved by addressing performance aspects.  The proposed solution
   is somewhere between hop-by-hop security and the approach in [<a href="#ref-47" title="&quot;Securing QoS: Threats to RSVP Messages and Their Countermeasures&quot;">47</a>],
   insofar as it separates the end-to-end path into individual networks.
   Furthermore, some additional RSVP messages (e.g., feedback messages)
   are introduced to implement a mechanism called "delayed integrity
   checking."  In [<a href="#ref-49" title="&quot;RSVP-SQoS: A Secure RSVP Protocol&quot;">49</a>], the approach presented in [<a href="#ref-48" title="&quot;Securing RSVP For Multimedia Applications&quot;">48</a>] is enhanced.

Authors' Addresses

   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   EMail: Hannes.Tschofenig@siemens.com


   Richard Graveman
   RFG Security
   15 Park Avenue
   Morristown, NJ  07960
   USA

   EMail: rfg@acm.org







<span class="grey">Tschofenig &amp; Graveman        Informational                     [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc4230">RFC 4230</a>                RSVP Security Properties           December 2005</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

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







Tschofenig &amp; Graveman        Informational                     [Page 48]
</pre>