* UNICODE_DN
* ASCII_DN_ENCRYPT
* UNICODE_DN_ENCRYPT
The policy locator string is an X.500 distinguished name (DN)
used to locate user or application-specific policy information.
The four types of X.500 DNs are listed above. The first two
types are the ASCII and the Unicode representation of the user
or application DN identity. The two "encrypted" distinguished
name types are either encrypted with the Kerberos session key
or with the private key of the user’s digital certificate
(i.e., digitally signed). The term "encrypted together with a
digital signature" is easy to misconceive. If user identity
confidentiality is provided, then the policy locator has to be
encrypted with the public key of the recipient. How to obtain
this public key is not described in the document. This detail
may be specified in a concrete architecture in which RSVP is
used.
o Credentials
Two cryptographic credentials are currently defined for a user:
authentication with Kerberos V5 [8], and authentication with
the help of digital signatures based on X.509 [18] and PGP
[19]. The following list contains all defined credential types
currently available and defined in [7]:
+--------------+--------------------------------+
| Credential | Description |
| Type | |
+===============================================|
| ASCII_ID | User or application identity |
| | encoded as an ASCII string |
+--------------+--------------------------------+
| UNICODE_ID | User or application identity |
| | encoded as a Unicode string |
+--------------+--------------------------------+
| KERBEROS_TKT | Kerberos V5 session ticket |
+--------------+--------------------------------+
| X509_V3_CERT | X.509 V3 certificate |
+--------------+--------------------------------+
| PGP_CERT | PGP certificate |
+--------------+--------------------------------+
Figure 2: Credentials Supported in RSVP.
The first two credentials contain only a plaintext string, and
therefore they do not provide cryptographic user
authentication. These plaintext strings may be used to
identify applications, that are included for policy-based
admission control. Note that these plain-text identifiers may,
however, be protected if either the RSVP INTEGRITY or the
INTEGRITY object of the POLICY_DATA element is present. Note
that the two INTEGRITY objects can terminate at different
entities depending on the network structure. The digital
signature may also provide protection of application
identifiers. A protected application identity (and the entire
content of the POLICY_DATA element) cannot be modified as long
as no policy-ignorant nodes are encountered in between.
A Kerberos session ticket, as previously mentioned, is the
ticket of a Kerberos AP_REQ message [8] without the
Authenticator. Normally, the AP_REQ message is used by a
client to authenticate to a server. The INTEGRITY object
(e.g., of the POLICY_DATA element) provides the functionality
of the Kerberos Authenticator, namely protecting against replay
and showing that the user was able to retrieve the session key
following the Kerberos protocol. This is, however, only the
case if the Kerberos session was used for the keyed message
digest field of the INTEGRITY object. Section 7 of [1]
discusses some issues for establishment of keys for the
INTEGRITY object. The establishment of the security
association for the RSVP INTEGRITY object with the inclusion of
the Kerberos Ticket within the AUTH_DATA element may be
complicated by the fact that the ticket can be decrypted by
node B, whereas the RSVP INTEGRITY object terminates at a
different host C.
The Kerberos session ticket contains, among many other fields,
the session key. The Policy Locator may also be encrypted with
the same session key. The protocol steps that need to be
executed to obtain such a Kerberos service ticket are not
described in [7] and may involve several roundtrips, depending
on many Kerberos-related factors. As an optimization, the
Kerberos ticket does not need to be included in every RSVP
message, as described in Section 7.1 of [1]. Thus, the
receiver must store the received service ticket. If the
lifetime of the ticket has expired, then a new service ticket
must be sent. If the receiver lost its state information
(because of a crash or restart) then it may transmit an
Integrity Challenge message to force the sender to re-transmit
a new service ticket.
If either the X.509 V3 or the PGP certificate is included in
the policy element, then a digital signature must be added.
The digital signature computed over the entire AUTH_DATA object
provides authentication and integrity protection. The SubType
of the digital signature authentication attribute is set to
zero before computing the digital signature. Whether or not a
guarantee of freshness with replay protection (either
timestamps or sequence numbers) is provided by the digital
signature is an open issue as discussed in Section 4.3.
o Digital Signature
The digital signature computed over the contents of the
AUTH_DATA object must be the last attribute. The algorithm
used to compute the digital signature depends on the
authentication mode listed in the credential. This is only
partially true, because, for example, PGP again allows
different algorithms to be used for computing a digital
signature. The algorithm identifier used for computing the
digital signature is not included in the certificate itself.
The algorithm identifier included in the certificate only
serves the purpose of allowing the verification of the
signature computed by the certificate authority (except for the
case of self-signed certificates).
o Policy Error Object
The Policy Error Object is used in the case of a failure of
policy-based admission control or other credential
verification. Currently available error messages allow
notification if the credentials are expired
(EXPIRED_CREDENTIALS), if the authorization process disallowed
the resource request (INSUFFICIENT_PRIVILEGES), or if the given
set of credentials is not supported
(UNSUPPORTED_CREDENTIAL_TYPE). The last error message returned
by the network allows the user’s host to discover the type of
credentials supported. Particularly for mobile environments
this might be quite inefficient. Furthermore, it is unlikely
that a user supports different types of credentials. The
purpose of the error message IDENTITY_CHANGED is unclear.
Also, the protection of the error message is not discussed in
[7].
3.5. RSVP Integrity Handshake
The Integrity Handshake protocol was designed to allow a crashed or
restarted host to obtain the latest valid challenge value stored at
the receiving host. Due to the absence of key management, it must be
guaranteed that two messages do not use the same sequence number with
the same key. A host stores the latest sequence number of a
cryptographically verified message. An adversary can replay
eavesdropped packets if the crashed host has lost its sequence
numbers. A signaling message from the real sender with a new
sequence number would therefore allow the crashed host to update the
sequence number field and prevent further replays. Hence, if there
is a steady flow of RSVP-protected messages between the two hosts, an
attacker may find it difficult to inject old messages, because new,
authenticated messages with higher sequence numbers arrive and get
stored immediately.
The following description explains the details of an RSVP Integrity
Handshake that is started by Node A after recovering from a
synchronization failure:
Integrity Challenge
(1) Message (including
+----------+ a Cookie) +----------+
| |-------------------------->| |
| Node A | | Node B |
| |<--------------------------| |
+----------+ Integrity Response +----------+
(2) Message (including
the Cookie and the
INTEGRITY object)
Figure 3: RSVP Integrity Handshake.
The details of the messages are as follows:
CHALLENGE:=(Key Identifier, Challenge Cookie)
Integrity Challenge Message:=(Common Header, CHALLENGE)
Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
The "Challenge Cookie" is suggested to be a MD5 hash of a local
secret and a timestamp [1].
The Integrity Challenge message is not protected with an INTEGRITY
object as shown in the protocol flow above. As explained in Section
10 of [1] this was done to avoid problems in situations where both
communicating parties do not have a valid starting sequence number.
Using the RSVP Integrity Handshake protocol is recommended although
it is not mandatory (because it may not be needed in all network
environments).
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
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.
(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.
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
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 [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
* 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.