+--------+ | Policy | +----|Decision| | | Point +---+ | +--------+ | | | | | +------+ +-+----+ +---+--+ +------+ |Client| |Router| |Router| |Client| | A +-------+ 1 +--------+ 2 +----------+ B | +------+ +------+ +------+ +------+ Figure 4: Simple RSVP Architecture.
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 , 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 .  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  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.
(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  are known and were initially described in . Other algorithms like SHA-1  and RIPEMD-160  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 . 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 . We assume that this is an oversight. Section 4.2 of  gives a few comments about the out-of-order delivery and the ability of an implementation to specify the replay window. Appendix C of  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.
In Section 10 of , 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 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 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  in combination with AAA protocols (for example, RADIUS  or DIAMETER ). 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  and ) to request that an admission control procedure be executed, or
* the router supports the functionality of a PDP and, therefore, there is no need to forward the request, or * the router may already be configured with the appropriate policy information to decide locally whether to grant this request. 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. 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 ). Another architecture in which RSVP is tightly integrated is the one specified by the PacketCable organization. The interested reader is referred to  for a discussion of their security architecture.
(1) Authentication When a user sends an RSVP PATH or RESV message, this message may include some information to authenticate the user.  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 , 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 , 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  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)  and the Simple Certificate Validation Protocol (SCVP)  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 , 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
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 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 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  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.
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 ). * 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 , 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 . In the case of X.509 credentials, the situation is more complex because different mechanisms like CMS  or PKCS#7  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. , 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 , 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 ), 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
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
the Sequence Number field, sequence number rollover, and the Integrity Handshake have already been explained in Section 3.1. Section 9 of  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  and in . 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  contains more information and describes the different hash algorithms (MD2, MD5, SHA-1, RIPEMD-160) supported.  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 . 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 .
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 . 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 .
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  lists the supported algorithms.  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
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  and the Simple Certificate Validation Protocol  are needed. Then the integrity of the AUTH_DATA object can be verified via the digital signature.
(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.