Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4230

RSVP Security Properties

Pages: 48
Part 2 of 3 – Pages 15 to 30
First   Prev   Next

Top   ToC   RFC4230 - Page 15   prevText

4. Detailed Security Property Discussion

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

4.1. Network Topology

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

4.2. Host/Router

When considering authentication in RSVP, it is important to make a distinction between user and host authentication of the signaling messages. The host is authenticated using the RSVP INTEGRITY object, whereas credentials inside the AUTH_DATA object can be used to authenticate the user. In this section, the focus is on host authentication, whereas the next section covers user authentication. (1) Authentication The term "host authentication" is used above, because the selection of the security association is bound to the host's IP
Top   ToC   RFC4230 - Page 16
       address, as mentioned in Section 3.1 and Section 3.2.  Depending
       on the key management protocol used to create this security
       association and the identity used, it is also possible to bind a
       user identity to this security association.  Because the key
       management protocol is not specified, it is difficult to evaluate
       this part, and hence we speak about data-origin authentication
       based on the host's identity for RSVP INTEGRITY objects.  The
       fact that the host identity is used for selecting the security
       association has already been described in Section 3.1.

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

       *  Kerberos for the RSVP INTEGRITY object

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

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

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

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

   (3) Replay Protection

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

   (4) Integrity Handshake

       The mechanism of the Integrity Handshake is explained in Section
       3.5.  The Cookie value is suggested to be a hash of a local
       secret and a timestamp.  The Cookie value is not verified by the
       receiver.  The mechanism used by the Integrity Handshake is a
       simple Challenge/Response message, which assumes that the key
       shared between the two hosts survives the crash.  If, however,
       the security association is dynamically created, then this
       assumption may not be true.
Top   ToC   RFC4230 - Page 18
       In Section 10 of [1], the authors note that an adversary can
       create a faked Integrity Handshake message that includes
       challenge cookies.  Subsequently, it could store the received
       response and later try to replay these responses while a
       responder recovers from a crash or restart.  If this replayed
       Integrity Response value is valid and has a lower sequence number
       than actually used, then this value is stored at the recovering
       host.  In order for this attack to be successful, the adversary
       must either have collected a large number of challenge/response
       value pairs or have "discovered" the cookie generation mechanism
       (for example by knowing the local secret).  The collection of
       Challenge/Response pairs is even more difficult, because they
       depend on the Cookie value, the sequence number included in the
       response message, and the shared key used by the INTEGRITY

   (5) Confidentiality

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

   (6) Authorization

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

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

       *  the router either forwards the received RSVP request to the
          policy decision point (e.g., using COPS [10] and [11]) to
          request that an admission control procedure be executed, or
Top   ToC   RFC4230 - Page 19
       *  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

       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

   (7) Performance

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

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

4.3. User to PEP/PDP

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

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

       *  Certificate Verification

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

       *  User Authentication to the PDP

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

       *  Kerberos-based Authentication to the PDP

          If Kerberos is used to authenticate the user, then a session
          ticket for the PDP must be requested first.  A user who roams
Top   ToC   RFC4230 - Page 21
          between different routers in the same administrative domain
          does not need to request a new service ticket, because the
          same PDP is likely to be used by most or all first-hop routers
          within the same administrative domain.  This is different from
          the case in which a session ticket for a router has to be
          obtained and authentication to a router is required.  The
          router therefore plays a passive role of simply forwarding the
          request to the PDP and executing the policy decision returned
          by the PDP.  Appendix B describes one example of user-to-PDP

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

   (2) Integrity Protection

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

       *  Kerberos

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

       *  Digital Signature

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

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

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

             For the digital signature case, only the replay protection
             provided by the digital signature algorithm can be used.
             It is not clear, however, whether this usage was
             anticipated or not.  Hence, we might assume that replay
Top   ToC   RFC4230 - Page 23
             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    +----+ |
   +--+---+                   +----+                      +-+--+
      |                                                     |
                       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
Top   ToC   RFC4230 - Page 24
       the Sequence Number field, sequence number rollover, and the
       Integrity Handshake have already been explained in Section 3.1.

       Section 9 of [7] states: "RSVP INTEGRITY object is used to
       protect the policy object containing user identity information
       from security (replay) attacks."  When using public-key-based
       authentication, RSVP-based replay protection is not supported,
       because the digital signature does not cover the POLICY_DATA
       INTEGRITY object with its Sequence Number field.  The digital
       signature covers only the entire AUTH_DATA object.

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

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

       The lifetime of the Kerberos ticket is based on the fields
       starttime and endtime of the EncTicketPart structure in the
       ticket, as described in Section 5.3.1 of [8].  Because the ticket
       is created by the KDC located at the network of the verifying
       entity, it is not difficult to have the clocks roughly
       synchronized for the purpose of lifetime verification.
       Additional information about clock-synchronization and Kerberos
       can be found in [32].
Top   ToC   RFC4230 - Page 25
       If the lifetime of the Kerberos ticket expires, then a new ticket
       must be requested and used.  Rekeying is implemented with this

   (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

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

       The ASCII or Unicode distinguished name of the user or
       application inside the POLICY_LOCATOR attribute of the AUTH_DATA
       element may be encrypted as specified in Section 3.3.1 of [7].
       The user (or application) identity is then encrypted with either
       the Kerberos session key or with the private key in case of
       public-key-based authentication.  When the private key is used,
       we usually speak of a digital signature that can be verified by
       everyone possessing the public key.  Because the certificate with
       the public key is included in the message itself, decryption is
       no obstacle.  Furthermore, the included certificate together with
       the additional (unencrypted) information in the RSVP message
       provides enough identity information for an eavesdropper.  Hence,
       the possibility of encrypting the policy locator in case of
       public-key-based authentication is problematic.  To encrypt the
       identities using asymmetric cryptography, the user's host must be
       able somehow to retrieve the public key of the entity verifying
       the policy element (i.e., the first policy-aware router or the
       PDP).  Then, this public key could be used to encrypt a symmetric
       key, which in turn encrypts the user's identity and certificate,
       as is done, e.g., by PGP.  Currently, no such mechanism is
       defined in [7].
Top   ToC   RFC4230 - Page 26
       The algorithm used to encrypt the POLICY_LOCATOR with the
       Kerberos session key is assumed to be the same as the one used
       for encrypting the service ticket.  The information about the
       algorithm used is available in the etype field of the
       EncryptedData ASN.1 encoded message part.  Section 6.3 of [8]
       lists the supported algorithms. [33] defines newer encryption
       algorithms (Rijndael, Serpent, and Twofish).

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

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

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

       Additional discussions are required to determine the expected
       authorization procedures. [34] and [35] discuss authorization
       issues for QoS signaling protocols.  Furthermore, a number of
       mobility implications for policy handling in RSVP are described
       in [36].

   (6) Performance

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

       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
Top   ToC   RFC4230 - Page 28
       needs to be done once in the lifetime of the session ticket.
       This is particularly true in a mobile environment with a fast
       roaming user's host.

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

4.4. Communication between RSVP-Aware Routers

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

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

5. Miscellaneous Issues

This section describes a number of issues that illustrate some of the shortcomings of RSVP with respect to security.
Top   ToC   RFC4230 - Page 30

5.1. First-Hop Issue

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

(page 30 continued on part 3)

Next Section