Request for Comments: 4230 Siemens
Category: Informational R. Graveman
RFG Security
December 2005
RSVP Security Properties
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document summarizes the security properties of RSVP. The goal
of this analysis is to benefit from previous work done on RSVP and to
capture knowledge about past activities.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Architectural Assumptions . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The RSVP INTEGRITY Object . . . . . . . . . . . . . . 5
3.2. Security Associations . . . . . . . . . . . . . . . . 8
3.3. RSVP Key Management Assumptions . . . . . . . . . . . 8
3.4. Identity Representation . . . . . . . . . . . . . . . 9
3.5. RSVP Integrity Handshake . . . . . . . . . . . . . . 13
4. Detailed Security Property Discussion . . . . . . . . . . . 15
4.1. Network Topology . . . . . . . . . . . . . . . . . . 15
4.2. Host/Router . . . . . . . . . . . . . . . . . . . . . 15
4.3. User to PEP/PDP . . . . . . . . . . . . . . . . . . . 19
4.4. Communication between RSVP-Aware Routers . . . . . . . 28
5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29
5.1. First-Hop Issue . . . . . . . . . . . . . . . . . . . 30
5.2. Next-Hop Problem . . . . . . . . . . . . . . . . . . . 30
5.3. Last-Hop Issue . . . . . . . . . . . . . . . . . . . 33
5.4. RSVP- and IPsec-protected data traffic . . . . . . . . 34
5.5. End-to-End Security Issues and RSVP . . . . . . . . . 36
5.6. IPsec protection of RSVP signaling messages . . . . . 36
5.7. Authorization . . . . . . . . . . . . . . . . . . . . 37
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . 41
A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . 45
B. Example of User-to-PDP Authentication . . . . . . . . . . . 45
C. Literature on RSVP Security . . . . . . . . . . . . . . . . 46
1. Introduction
As the work of the NSIS working group began, concerns about security
and its implications for the design of a signaling protocol were
raised. In order to understand the security properties and available
options of RSVP, a number of documents have to be read. This
document summarizes the security properties of RSVP and is part of
the overall process of analyzing other signaling protocols and
learning from their design considerations. This document should also
provide a starting point for further discussions.
The content of this document is organized as follows. Section 2
introduces the terminology used throughout the document. Section 3
provides an overview of the security mechanisms provided by RSVP
including the INTEGRITY object, a description of the identity
representation within the POLICY_DATA object (i.e., user
authentication), and the RSVP Integrity Handshake mechanism. Section
4 provides a more detailed discussion of the mechanisms used and
tries to describe in detail the mechanisms provided. Several
miscellaneous issues are covered in Section 5.
RSVP also supports multicast, but this document does not address
security aspects for supporting multicast QoS signaling. Multicast
is currently outside the scope of the NSIS working group.
Although a variation of RSVP, namely RSVP-TE, is used in the context
of MPLS to distribute labels for a label switched path, its usage is
different from the usage scenarios envisioned for NSIS. Hence, this
document does not address RSVP-TE or its security properties.
2. Terminology and Architectural Assumptions
This section describes some important terms and explains some
architectural assumptions.
o Chain-of-Trust:
The security mechanisms supported by RSVP [1] heavily rely on
optional hop-by-hop protection, using the built-in INTEGRITY
object. Hop-by-hop security with the INTEGRITY object inside the
RSVP message thereby refers to the protection between RSVP-
supporting network elements. Additionally, there is the notion of
policy-aware nodes that understand the POLICY_DATA element within
the RSVP message. Because this element also includes an INTEGRITY
object, there is an additional hop-by-hop security mechanism that
provides security between policy-aware nodes. Policy-ignorant
nodes are not affected by the inclusion of this object in the
POLICY_DATA element, because they do not try to interpret it.
To protect signaling messages that are possibly modified by each
RSVP router along the path, it must be assumed that each incoming
request is authenticated, integrity protected, and replay
protected. This provides protection against bogus messages
injected by unauthorized nodes. Furthermore, each RSVP-aware
router is assumed to behave in the expected manner. Outgoing
messages transmitted to the next-hop network element receive new
protection according to RSVP security processing.
Using the mechanisms described above, a chain-of-trust is created
whereby a signaling message that is transmitted by router A via
router B and received by router C is supposed to be secure if
routers A and B and routers B and C share security associations
and all routers behave as expected. Hence, router C trusts router
A although router C does not have a direct security association
with router A. We can therefore conclude that the protection
achieved with this hop-by-hop security for the chain-of-trust is
no better than the weakest link in the chain.
If one router is malicious (for example, because an adversary has
control over this router), then it can arbitrarily modify
messages, cause unexpected behavior, and mount a number of attacks
that are not limited to QoS signaling. Additionally, it must be
mentioned that some protocols demand more protection than others
(which depends, in part, on which nodes are executing these
protocols). For example, edge devices, where end-users are
attached, may be more likely to be attacked in comparison with the
more secure core network of a service provider. In some cases, a
network service provider may choose not to use the RSVP-provided
security mechanisms inside the core network because a different
security protection is deployed.
Section 6 of [2] mentions the term chain-of-trust in the context
of RSVP integrity protection. In Section 6 of [14] the same term
is used in the context of user authentication with the INTEGRITY
object inside the POLICY_DATA element. Unfortunately, the term is
not explained in detail and the assumptions behind it are not
clearly specified.
o Host and User Authentication:
The presence of RSVP protection and a separate user identity
representation leads to the fact that both user-identity and host-
identity are used for RSVP protection. Therefore, user-based
security and host-based security are covered separately, because
of the different authentication mechanisms provided. To avoid
confusion about the different concepts, Section 3.4 describes the
concept of user authentication in more detail.
o Key Management:
It is assumed that most of the security associations required for
the protection of RSVP signaling messages are already available,
and hence key management was done in advance. There is, however,
an exception with respect to support for Kerberos. Using
Kerberos, an entity is able to distribute a session key used for
RSVP signaling protection.
o RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
RSVP uses an INTEGRITY object in two places in a message. The
first is in the RSVP message itself and covers the entire RSVP
message as defined in [1]. The second is included in the
POLICY_DATA object and defined in [2]. To differentiate the two
objects by their scope of protection, the two terms RSVP INTEGRITY
and POLICY_DATA INTEGRITY object are used, respectively. The data
structure of the two objects, however, is the same.
o Hop versus Peer:
In the past, the terminology for nodes addressed by RSVP has been
discussed considerably. In particular, two favorite terms have
been used: hop and peer. This document uses the term hop, which
is different from an IP hop. Two neighboring RSVP nodes
communicating with each other are not necessarily neighboring IP
nodes (i.e., they may be more than one IP hop away).
3. Overview
This section describes the security mechanisms provided by RSVP.
Although use of IPsec is mentioned in Section 10 of [1], the other
security mechanisms primarily envisioned for RSVP are described.
3.1. The RSVP INTEGRITY Object
The RSVP INTEGRITY object is the major component of RSVP security
protection. This object is used to provide integrity and replay
protection for the content of the signaling message between two RSVP
participating routers or between an RSVP router and host.
Furthermore, the RSVP INTEGRITY object provides data origin
authentication. The attributes of the object are briefly described:
o Flags field:
The Handshake Flag is the only defined flag. It is used to
synchronize sequence numbers if the communication gets out of
sync (e.g., it allows a restarting host to recover the most
recent sequence number). Setting this flag to one indicates that
the sender is willing to respond to an Integrity Challenge
message. This flag can therefore be seen as a negotiation
capability transmitted within each INTEGRITY object.
o Key Identifier:
The Key Identifier selects the key used for verification of the
Keyed Message Digest field and, hence, must be unique for the
sender. It has a fixed 48-bit length. The generation of this
Key Identifier field is mostly a decision of the local host. [1]
describes this field as a combination of an address, sending
interface, and key number. We assume that the Key Identifier is
simply a (keyed) hash value computed over a number of fields,
with the requirement to be unique if more than one security
association is used in parallel between two hosts (e.g., as is
the case with security associations having overlapping
lifetimes). A receiving system uniquely identifies a security
association based on the Key Identifier and the sender’s IP
address. The sender’s IP address may be obtained from the
RSVP_HOP object or from the source IP address of the packet if
the RSVP_HOP object is not present. The sender uses the outgoing
interface to determine which security association to use. The
term "outgoing interface" may be confusing. The sender selects
the security association based on the receiver’s IP address
(i.e., the address of the next RSVP-capable router). The process
of determining which node is the next RSVP-capable router is not
further specified and is likely to be statically configured.
o Sequence Number:
The sequence number used by the INTEGRITY object is 64 bits in
length, and the starting value can be selected arbitrarily. The
length of the sequence number field was chosen to avoid
exhaustion during the lifetime of a security association as
stated in Section 3 of [1]. In order for the receiver to
distinguish between a new and a replayed message, the sequence
number must be monotonically incremented (modulo 2^64) for each
message. We assume that the first sequence number seen (i.e.,
the starting sequence number) is stored somewhere. The modulo-
operation is required because the starting sequence number may be
an arbitrary number. The receiver therefore only accepts packets
with a sequence number larger (modulo 2^64) than the previous
packet. As explained in [1] this process is started by
handshaking and agreeing on an initial sequence number. If no
such handshaking is available then the initial sequence number
must be part of the establishment of the security association.
The generation and storage of sequence numbers is an important
step in preventing replay attacks and is largely determined by
the capabilities of the system in the presence of system crashes,
failures, and restarts. Section 3 of [1] explains some of the
most important considerations. However, the description of how
the receiver distinguishes proper from improper sequence numbers
is incomplete: it implicitly assumes that gaps large enough to
cause the sequence number to wrap around cannot occur.
If delivery in order were guaranteed, the following procedure
would work: the receiver keeps track of the first sequence number
received, INIT-SEQ, and the most recent sequence number received,
LAST-SEQ, for each key identifier in a security association.
When the first message is received, set INIT-SEQ = LAST-SEQ =
value received and accept. When a subsequent message is
received, if its sequence number is strictly between LAST-SEQ and
INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the
value just received. If it is between INIT-SEQ and LAST-SEQ,
inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ
unchanged. Because delivery in order is not guaranteed, the
above rules need to be combined with a method of allowing a fixed
sized window in the neighborhood of LAST-SEQ for out-of-order
delivery, for example, as described in Appendix C of [3].
o Keyed Message Digest:
The Keyed Message Digest is a security mechanism built into RSVP
that used to provide integrity protection of a signaling message
(including its sequence number). Prior to computing the value
for the Keyed Message Digest field, the Keyed Message Digest
field itself must be set to zero and a keyed hash computed over
the entire RSVP packet. The Keyed Message Digest field is
variable in length but must be a multiple of four octets. If
HMAC-MD5 is used, then the output value is 16 bytes long. The
keyed hash function HMAC-MD5 [4] is required for an RSVP
implementation, as noted in Section 1 of [1]. Hash algorithms
other than MD5 [5], like SHA-1 [15], may also be supported.
The key used for computing this Keyed Message Digest may be
obtained from the pre-shared secret, which is either manually
distributed or the result of a key management protocol. No key
management protocol, however, is specified to create the desired
security associations. Also, no guidelines for key length are
given. It should be recommended that HMAC-MD5 keys be 128 bits
and SHA-1 keys 160 bits, as in IPsec AH [16] and ESP [17].
3.2. Security Associations
Different attributes are stored for security associations of sending
and receiving systems (i.e., unidirectional security associations).
The sending system needs to maintain the following attributes in such
a security association [1]:
o Authentication algorithm and algorithm mode
o Key
o Key Lifetime
o Sending Interface
o Latest sequence number (received with this key identifier)
The receiving system has to store the following fields:
o Authentication algorithm and algorithm mode
o Key
o Key Lifetime
o Source address of the sending system
o List of last n sequence numbers (received with this key
identifier)
Note that the security associations need to have additional fields to
indicate their state. It is necessary to have overlapping lifetimes
of security associations to avoid interrupting an ongoing
communication because of expired security associations. During such
a period of overlapping lifetime it is necessary to authenticate with
either one or both active keys. As mentioned in [1], a sender and a
receiver may have multiple active keys simultaneously. If more than
one algorithm is supported, then the algorithm used must be specified
for a security association.
3.3. RSVP Key Management Assumptions
RFC 2205 [6] assumes that security associations are already
available. An implementation must support manual key distribution as
noted in Section 5.2 of [1]. Manual key distribution, however, has
different requirements for key storage; a simple plaintext ASCII file
may be sufficient in some cases. If multiple security associations
with different lifetimes need to be supported at the same time, then
a key engine would be more appropriate. Further security
requirements listed in Section 5.2 of [1] are the following:
o The manual deletion of security associations must be supported.
o The key storage should persist during a system restart.
o Each key must be assigned a specific lifetime and a specific Key
Identifier.
3.4. Identity Representation
In addition to host-based authentication with the INTEGRITY object
inside the RSVP message, user-based authentication is available as
introduced in [2]. Section 2 of [7] states that "Providing policy
based admission control mechanism based on user identities or
application is one of the prime requirements." To identify the user
or the application, a policy element called AUTH_DATA, which is
contained in the POLICY_DATA object, is created by the RSVP daemon at
the user’s host and transmitted inside the RSVP message. The
structure of the POLICY_DATA element is described in [2]. Network
nodes acting as policy decision points (PDPs) then use the
information contained in the AUTH_DATA element to authenticate the
user and to allow policy-based admission control to be executed. As
mentioned in [7], the policy element is processed and the PDP
replaces the old element with a new one for forwarding to the next
hop router.
A detailed description of the POLICY_DATA element can be found in
[2]. The attributes contained in the authentication data policy
element AUTH_DATA, which is defined in [7], are briefly explained in
this Section. Figure 1 shows the abstract structure of the RSVP
message with its security-relevant objects and the scope of
protection. The RSVP INTEGRITY object (outer object) covers the
entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
covers objects within the POLICY_DATA element.
+--------------------------------------------------------+
| RSVP Message |
+--------------------------------------------------------+
| Object |POLICY_DATA Object ||
| +-------------------------------------------+|
| | INTEGRITY +------------------------------+||
| | Object | AUTH_DATA Object |||
| | +------------------------------+||
| | | Various Authentication |||
| | | Attributes |||
| | +------------------------------+||
| +-------------------------------------------+|
+--------------------------------------------------------+
Figure 1: Security Relevant Objects and Elements
within the RSVP Message.
The AUTH_DATA object contains information for identifying users and
applications together with credentials for those identities. The
main purpose of these identities seems to be usage for policy-based
admission control and not authentication and key management. As
noted in Section 6.1 of [7], an RSVP message may contain more than
one POLICY_DATA object and each of them may contain more than one
AUTH_DATA object. As indicated in Figure 1 and in [7], one AUTH_DATA
object may contain more than one authentication attribute. A typical
configuration for Kerberos-based user authentication includes at
least the Policy Locator and an attribute containing the Kerberos
session ticket.
Successful user authentication is the basis for executing policy-
based admission control. Additionally, other information such as
time-of-day, application type, location information, group
membership, etc. may be relevant to the implementation of an access
control policy.
The following attributes are defined for use in the AUTH_DATA object:
o Policy Locator
* ASCII_DN