Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4230

RSVP Security Properties

Pages: 48
Part 3 of 3 – Pages 30 to 48
First   Prev   None

Top   ToC   RFC4230 - Page 30   prevText

5.2. Next-Hop Problem

Throughout the document it was assumed that the next RSVP node along the path is always known. Knowing the next hop is important to be able to select the correct key for the RSVP Integrity object and to apply the proper protection. In the case in which an RSVP node assumes it knows which node is the next hop, the following protocol exchange can occur:
Top   ToC   RFC4230 - Page 31
                          (A<->C)               +------+
                                      (3)       | RSVP |
                                 +------------->+ Node |
                                 |              |  B   |
                    Integrity    |              +--+---+
                     (A<->C)     |                 |
          +------+    (2)     +--+----+            |
     (1)  | RSVP +----------->+Router |            |  Error
    ----->| Node |            | or    +<-----------+ (I am B)
          |  A   +<-----------+Network|       (4)
          +------+    (5)     +--+----+
                     Error       .
                    (I am B)     .              +------+
                                 .              | RSVP |
                                 ...............+ Node |
                                                |  C   |

                         Figure 6: Next-Hop Issue.

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

   Figure 6 describes a behavior that might help node A learn that an
   error occurred.  However, the description in Section 4.2 of [1]
   states in step (5) that a signaling message is silently discarded if
   the receiving host cannot properly verify the message: "If the
   calculated digest does not match the received digest, the message is
   discarded without further processing."  For RSVP Path and similar
   messages, this functionality is not really helpful.
Top   ToC   RFC4230 - Page 32
   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-
Top   ToC   RFC4230 - Page 33
      domain case with a dense distribution of RSVP nodes, protection
      might be possible with manual configuration.

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

5.3. Last-Hop Issue

This section tries to address practical difficulties when authentication and key establishment are accomplished with a two- party protocol that shows some asymmetry in message processing. Kerberos is such a protocol and also the only supported protocol that provides dynamic session key establishment for RSVP. For first-hop communication, authentication is typically done between a user and some router (for example the access router). Especially in a mobile environment, it is not feasible to authenticate end hosts based on their IP or MAC address. To illustrate this problem, the typical processing steps for Kerberos are shown for first-hop communication: (1) The end host A learns the identity (i.e., Kerberos principal name) of some entity B. This entity B is either the next RSVP node, a PDP, or the next policy-aware RSVP node. (2) Entity A then requests a ticket granting ticket for the network domain. This assumes that the identity of the network domain is known. (3) Entity A then requests a service ticket for entity B, whose name was learned in step (1). (4) Entity A includes the service ticket with the RSVP signaling message (inside the policy object). The Kerberos session key is used to protect the integrity of the entire RSVP signaling message.
Top   ToC   RFC4230 - Page 34
   For last-hop communication, this processing theoretically has to be
   reversed: entity A is then a node in the network (for example, the
   access router) and entity B is the other end host (under the
   assumption that RSVP signaling is accomplished between two end hosts
   and not between an end host and an application server).  However, the
   access router in step (1) might not be able to learn the user's
   principal name because this information might not be available.
   Entity A could reverse the process by triggering an IAKERB exchange.
   This would cause entity B to request a service ticket for A as
   described above.  However, IAKERB is not supported in RSVP.

5.4. RSVP- and IPsec-Protected Data Traffic

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

              Figure 7: RSVP and IPsec protected data traffic.

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

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

       IPsec tunnels that neither start nor terminate at one of the
       signaling end points (for example between two networks) should be
       addressed differently by recursively applying an RSVP signaling
       exchange for the IPsec tunnel.  RSVP signaling within tunnels is
       addressed in [13].
Top   ToC   RFC4230 - Page 36
   (3) It is assumed that SPIs do not change during the lifetime of the
       established QoS reservation.  If a new IPsec SA is created, then

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

5.5. End-to-End Security Issues and RSVP

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

5.6. IPsec Protection of RSVP Signaling Messages

It is assumed throughout that RSVP signaling messages can also be protected by IPsec [3] in a hop-by-hop fashion between two adjacent RSVP nodes. RSVP, however, uses special processing of signaling messages, which complicates IPsec protection. As explained in this section, IPsec should only be used for protection of RSVP signaling messages in a point-to-point communication environment (i.e., an RSVP message can only reach one RSVP router and not possibly more than one). This restriction is caused by the combination of signaling message delivery and discovery into a single message. Furthermore, end-to-end addressing complicates IPsec handling considerably. This section describes at least some of these complications.
Top   ToC   RFC4230 - Page 37
   RSVP messages are transmitted as raw IP packets with protocol number
   46.  It might be possible to encapsulate them in UDP as described in
   Appendix C of [6].  Some RSVP messages (Path, PathTear, and ResvConf)
   must have the Router Alert IP Option set in the IP header.  These
   messages are addressed to the (unicast or multicast) destination
   address and not to the next RSVP node along the path.  Hence, an
   IPsec traffic selector can only use these fields for IPsec SA
   selection.  If there is only a single path (and possibly all traffic
   along it is protected) then there is no problem for IPsec protection
   of signaling messages.  This type of protection is not common and
   might only be used to secure network access between an end host and
   its first-hop router.  Because the described RSVP messages are
   addressed to the destination address instead of the next RSVP node,
   it is not possible to use IPsec ESP [17] or AH [16] in transport
   mode--only IPsec in tunnel mode is possible.

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

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

   One benefit of using IPsec is the availability of key management
   using either IKE [39], KINK [40] or IKEv2 [41].

5.7. Authorization

[34] describes two trust models (NJ Turnpike and NJ Parkway) and two authorization models (per-session and per-channel financial settlement). The NJ Turnpike model gives a justification for hop-by- hop security protection. RSVP focuses on the NJ Turnpike model, although the different trust models are not described in detail. RSVP supports the NJ Parkway model and per-channel financial settlement only to a certain extent. Authentication of the user (or end host) can be provided with the user identity representation
Top   ToC   RFC4230 - Page 38
   mechanism, but authentication might, in many cases, be insufficient
   for authorization.  The communication procedures defined for policy

   objects [42] can be improved to support the more efficient per-
   channel financial settlement model by avoiding policy handling
   between inter-domain networks at a signaling message granularity.
   Additional information about expected behavior of policy handling in
   RSVP can also be obtained from [43].

   [35] and [36] provide additional information on authorization.  No
   good and agreed mechanism for dealing with authorization of QoS
   reservations in roaming environments is provided.  Price distribution
   mechanisms are only described in papers and never made their way
   through standardization.  RSVP focuses on receiver-initiated
   reservations with authorization for the QoS reservation by the data
   receiver, which introduces a fair amount of complexity for mobility
   handling as described, for example, in [36].

6. Conclusions

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

   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.
Top   ToC   RFC4230 - Page 40
   o  Confidentiality protection is missing and should therefore be
      added to the protocol.  The general principle is that protocol
      designers can seldom foresee all of the environments in which
      protocols will be run, so they should allow users to select from a
      full range of security services, as the needs of different user
      communities vary.

   o  Parameter and mechanism negotiation should be provided.

7. Security Considerations

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

8. Acknowledgements

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

9. References

9.1. Normative References

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

   [8]   Kohl, J. and C. Neuman, "The Kerberos Network Authentication
         Service (V5)", RFC 1510, September 1993.  Obsoleted by RFC

   [9]   Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
         "Diameter Base Protocol", RFC 3588, September 2003.

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

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

   [12]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
         Flows", RFC 2207, September 1997.

   [13]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
         Operation Over IP Tunnels", RFC 2746, January 2000.

9.2. Informative References

[14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control", Work in Progress, June 2001. [15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal Information Processing Society, April 1995. [16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [18] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999. [19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [20] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress, July 2002.
Top   ToC   RFC4230 - Page 42
   [21]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
         strengthened version of RIPEMD in Fast Software Encryption",
         LNCS vol. 1039, pp. 71-82, 1996.

   [22]  Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
         Laboratories CryptoBytes, vol. 2, no. 2, 1996.

   [23]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
         3748, June 2004.

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

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

   [26]  Cable Television Laboratories, Inc., "PacketCable Security
         Specification, PKT-SP-SEC-I01-991201", website:, June 2003.

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

   [28]  Malpani, A., Housley, R., and T. Freeman, "Simple Certificate
         Validation Protocol (SCVP)", Work in Progress, October 2005.

   [29]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
         August 2002.

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

   [31]  "Specifications and standard documents", website:, March 2002.

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

   [33]  Raeburn, K., "Encryption and Checksum Specifications for
         Kerberos 5", RFC 3961, February 2005.

   [34]  Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
         Schulzrinne, "NSIS Authentication, Authorization and Accounting
         Issues", Work in Progress, March 2003.
Top   ToC   RFC4230 - Page 43
   [35]  Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne,
         H., and T. Chen, "QoS NSLP Authorization Issues", Work in
         Progress, June 2003.

   [36]  Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work
         in Progress, October 2002.

   [37]  Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP
         Proxy", Work in Progress, March 2002.

   [38]  Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K.
         Raatikainen, "Localized RSVP", Work in Progress, September

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

   [40]  Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)",
         Work in Progress, October 2005.

   [41]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
         4306, November 2005.

   [42]  Herzog, S., "Accounting and Access Control in RSVP", PhD
         Dissertation, USC, Work in Progress, November 1995.

   [43]  Herzog, S., "Accounting and Access Control for Multicast
         Distributions: Models and Mechanisms", June 1996.

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

   [45]  Tung, B. and L. Zhu, "Public Key Cryptography for Initial
         Authentication in Kerberos", Work in Progress, November 2005.

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

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

   [48]  Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For
         Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia
         Security Workshop), November 2000.
Top   ToC   RFC4230 - Page 44
   [49]  Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure
         RSVP Protocol", International Conf on Multimedia and
         Exposition, Tokyo, Japan, August 2001.

   [50]  Jablon, D., "Strong Password-only Authenticated Key Exchange",
         ACM Computer Communication Review, 26(5), pp. 5-26, October
Top   ToC   RFC4230 - Page 45

Appendix A. Dictionary Attacks and Kerberos

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

Appendix B. Example of User-to-PDP Authentication

The following Section describes an example of user-to-PDP authentication. Note that the description below is not fully covered by the RSVP specification and hence it should only be viewed as an example. Windows 2000, which integrates Kerberos into RSVP, uses a configuration with the user authentication to the PDP as described in [25]. The steps for authenticating the user to the PDP in an intra- realm scenario are the following: o Windows 2000 requires the user to contact the KDC and to request a Kerberos service ticket for the PDP account AcsService in the local realm.
Top   ToC   RFC4230 - Page 46
   o  This ticket is then embedded into the AUTH_DATA element and
      included in either the PATH or the RESV message.  In the case of
      Microsoft's implementation, the user identity encoded as a
      distinguished name is encrypted with the session key provided with
      the Kerberos ticket.  The Kerberos ticket is sent without the
      Kerberos authdata element that contains authorization information,
      as explained in [25].

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

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

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

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

      *  The PDP does not maintain a user database, and [25] describes
         how the PDP may query the Active Directory (a LDAP based
         directory service) for user policy information.

Appendix C. Literature on RSVP Security

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

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

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

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

Authors' Addresses

Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany EMail: Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 USA EMail:
Top   ToC   RFC4230 - Page 48
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   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-


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