draft-ietf-nsis-rsvp-sec-properties-06.txt   rfc4230.txt 
NSIS H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Siemens Request for Comments: 4230 Siemens
Expires: August 21, 2005 R. Graveman Category: Informational R. Graveman
RFG Security RFG Security
February 20, 2005 December 2005
RSVP Security Properties RSVP Security Properties
draft-ietf-nsis-rsvp-sec-properties-06.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2005. 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 Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document summarizes the security properties of RSVP. The goal This document summarizes the security properties of RSVP. The goal
of this analysis is to benefit from previous work done on RSVP and to of this analysis is to benefit from previous work done on RSVP and to
capture knowledge about past activities. capture knowledge about past activities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Architectural Assumptions . . . . . . . . . . 4 2. Terminology and Architectural Assumptions . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 The RSVP INTEGRITY Object . . . . . . . . . . . . . . . . 6 3.1. The RSVP INTEGRITY Object . . . . . . . . . . . . . . 5
3.2 Security Associations . . . . . . . . . . . . . . . . . . 8 3.2. Security Associations . . . . . . . . . . . . . . . . 8
3.3 RSVP Key Management Assumptions . . . . . . . . . . . . . 9 3.3. RSVP Key Management Assumptions . . . . . . . . . . . 8
3.4 Identity Representation . . . . . . . . . . . . . . . . . 9 3.4. Identity Representation . . . . . . . . . . . . . . . 9
3.5 RSVP Integrity Handshake . . . . . . . . . . . . . . . . . 13 3.5. RSVP Integrity Handshake . . . . . . . . . . . . . . 13
4. Detailed Security Property Discussion . . . . . . . . . . . . 15 4. Detailed Security Property Discussion . . . . . . . . . . . 15
4.1 Network Topology . . . . . . . . . . . . . . . . . . . . . 15 4.1. Network Topology . . . . . . . . . . . . . . . . . . 15
4.2 Host/Router . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Host/Router . . . . . . . . . . . . . . . . . . . . . 15
4.3 User to PEP/PDP . . . . . . . . . . . . . . . . . . . . . 19 4.3. User to PEP/PDP . . . . . . . . . . . . . . . . . . . 19
4.4 Communication between RSVP-Aware Routers . . . . . . . . . 26 4.4. Communication between RSVP-Aware Routers . . . . . . . 28
5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 29 5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29
5.1 First Hop Issue . . . . . . . . . . . . . . . . . . . . . 29 5.1. First-Hop Issue . . . . . . . . . . . . . . . . . . . 30
5.2 Next-Hop Problem . . . . . . . . . . . . . . . . . . . . . 29 5.2. Next-Hop Problem . . . . . . . . . . . . . . . . . . . 30
5.3 Last-Hop Issue . . . . . . . . . . . . . . . . . . . . . . 32 5.3. Last-Hop Issue . . . . . . . . . . . . . . . . . . . 33
5.4 RSVP and IPsec protected data traffic . . . . . . . . . . 33 5.4. RSVP- and IPsec-protected data traffic . . . . . . . . 34
5.5 End-to-End Security Issues and RSVP . . . . . . . . . . . 35 5.5. End-to-End Security Issues and RSVP . . . . . . . . . 36
5.6 IPsec protection of RSVP signaling messages . . . . . . . 35 5.6. IPsec protection of RSVP signaling messages . . . . . 36
5.7 Authorization . . . . . . . . . . . . . . . . . . . . . . 36 5.7. Authorization . . . . . . . . . . . . . . . . . . . . 37
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 7. Security Considerations . . . . . . . . . . . . . . . . . . 40
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 40 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1. Normative References . . . . . . . . . . . . . . . . . 40
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 9.2. Informative References . . . . . . . . . . . . . . . . 41
10.2 Informative References . . . . . . . . . . . . . . . . . . . 43 A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 B. Example of User-to-PDP Authentication . . . . . . . . . . . 45
A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . . 47 C. Literature on RSVP Security . . . . . . . . . . . . . . . . 46
B. Example of User-to-PDP Authentication . . . . . . . . . . . . 48
C. Literature on RSVP Security . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . 50
1. Introduction 1. Introduction
As the work of the NSIS working group has begun, there are also As the work of the NSIS working group began, concerns about security
concerns about security and its implications for the design of a and its implications for the design of a signaling protocol were
signaling protocol. In order to understand the security properties raised. In order to understand the security properties and available
and available options of RSVP a number of documents have to be read. options of RSVP, a number of documents have to be read. This
This document summarizes the security properties of RSVP and is part document summarizes the security properties of RSVP and is part of
of the overall process of analyzing other signaling protocols and the overall process of analyzing other signaling protocols and
learning from their design considerations. This document should also learning from their design considerations. This document should also
provide a starting point for further discussions. provide a starting point for further discussions.
The content of this document is organized as follows: The content of this document is organized as follows. Section 2
introduces the terminology used throughout the document. Section 3
Section 3 provides an overview of the security mechanisms provided by provides an overview of the security mechanisms provided by RSVP
RSVP including the INTEGRITY object, a description of the identity including the INTEGRITY object, a description of the identity
representation within the POLICY_DATA object (i.e., user representation within the POLICY_DATA object (i.e., user
authentication), and the RSVP Integrity Handshake mechanism. Section authentication), and the RSVP Integrity Handshake mechanism. Section
4 provides a more detailed discussion of the mechanisms used and 4 provides a more detailed discussion of the mechanisms used and
tries to describe in detail the mechanisms provided. 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 RSVP also supports multicast, but this document does not address
security aspects for supporting multicast QoS signaling. Multicast security aspects for supporting multicast QoS signaling. Multicast
is currently outside the scope of the NSIS working group. is currently outside the scope of the NSIS working group.
Although a variation of RSVP, namely RSVP-TE, is used in the context 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 of MPLS to distribute labels for a label switched path, its usage is
different than the usage scenarios envisioned for NSIS. Hence, this different from the usage scenarios envisioned for NSIS. Hence, this
document does not address RSVP-TE and the security properties of it. document does not address RSVP-TE or its security properties.
2. Terminology and Architectural Assumptions 2. Terminology and Architectural Assumptions
This section describes some important terms and explains some This section describes some important terms and explains some
architectural assumptions: architectural assumptions.
Chain-of-Trust: o Chain-of-Trust:
The security mechanisms supported by RSVP [1] heavily rely on The security mechanisms supported by RSVP [1] heavily rely on
optional hop-by-hop protection using the built-in INTEGRITY optional hop-by-hop protection, using the built-in INTEGRITY
object. Hop-by-hop security with the INTEGRITY object inside the object. Hop-by-hop security with the INTEGRITY object inside the
RSVP message thereby refers to the protection between RSVP message thereby refers to the protection between RSVP-
RSVP-supporting network elements. Additionally, there is the supporting network elements. Additionally, there is the notion of
notion of policy-aware network elements that understand the policy-aware nodes that understand the POLICY_DATA element within
POLICY_DATA element within the RSVP message. Because this element the RSVP message. Because this element also includes an INTEGRITY
also includes an INTEGRITY object, there is an additional object, there is an additional hop-by-hop security mechanism that
hop-by-hop security mechanism that provides security between provides security between policy-aware nodes. Policy-ignorant
policy-aware nodes. Policy-ignorant nodes are not affected by the nodes are not affected by the inclusion of this object in the
inclusion of this object in the POLICY_DATA element, because they POLICY_DATA element, because they do not try to interpret it.
do not try to interpret it.
To protect signaling messages that are possibly modified by each To protect signaling messages that are possibly modified by each
RSVP router along the path, it must be assumed that each incoming RSVP router along the path, it must be assumed that each incoming
request is authenticated, integrity protected, and replay request is authenticated, integrity protected, and replay
protected. This provides protection against unauthorized nodes' protected. This provides protection against bogus messages
injecting bogus messages. Furthermore, each RSVP-aware router is injected by unauthorized nodes. Furthermore, each RSVP-aware
assumed to behave in the expected manner. Outgoing messages router is assumed to behave in the expected manner. Outgoing
transmitted to the next hop network element receive protection messages transmitted to the next-hop network element receive new
according RSVP security processing. protection according to RSVP security processing.
Using the above described mechanisms, a chain-of-trust is created Using the mechanisms described above, a chain-of-trust is created
whereby a signaling message transmitted by router A via router B whereby a signaling message that is transmitted by router A via
and received by router C is supposed to be secure if routers A and router B and received by router C is supposed to be secure if
B and routers B and C share security associations and all routers routers A and B and routers B and C share security associations
behave as expected. Hence router C trusts router A although and all routers behave as expected. Hence, router C trusts router
router C does not have a direct security association with router A although router C does not have a direct security association
A. We can therefore conclude that the protection achieved with with router A. We can therefore conclude that the protection
this hop-by-hop security for the chain-of-trust is no better than achieved with this hop-by-hop security for the chain-of-trust is
the weakest link in the chain. no better than the weakest link in the chain.
If one router is malicious (for example because an adversary has If one router is malicious (for example, because an adversary has
control over this router), then it can arbitrarily modify control over this router), then it can arbitrarily modify
messages, cause unexpected behavior, and mount a number of attacks messages, cause unexpected behavior, and mount a number of attacks
not limited only to QoS signaling. Additionally, it must be that are not limited to QoS signaling. Additionally, it must be
mentioned that some protocols demand more protection than others mentioned that some protocols demand more protection than others
(which depends in part on which nodes are executing these (which depends, in part, on which nodes are executing these
protocols). For example, edge devices, where end-users are protocols). For example, edge devices, where end-users are
attached, may more likely be attacked in comparison with the more attached, may be more likely to be attacked in comparison with the
secure core network of a service provider. In some cases a more secure core network of a service provider. In some cases, a
network service provider may choose not to use the RSVP-provided network service provider may choose not to use the RSVP-provided
security mechanisms inside the core network because a different security mechanisms inside the core network because a different
security protection is deployed. security protection is deployed.
Section 6 of [2] mentions the term chain-of-trust in the context Section 6 of [2] mentions the term chain-of-trust in the context
of RSVP integrity protection. In Section 6 of [18] the same term of RSVP integrity protection. In Section 6 of [14] the same term
is used in the context of user authentication with the INTEGRITY is used in the context of user authentication with the INTEGRITY
object inside the POLICY_DATA element . Unfortunately the term is object inside the POLICY_DATA element. Unfortunately, the term is
not explained in detail and the assumptions behind it are not not explained in detail and the assumptions behind it are not
clearly specified. clearly specified.
Host and User Authentication: o Host and User Authentication:
The presence of RSVP protection and a separate user identity The presence of RSVP protection and a separate user identity
representation leads to the fact that both user-identity and representation leads to the fact that both user-identity and host-
host-identity are used for RSVP protection. Therefore, user-based identity are used for RSVP protection. Therefore, user-based
security and host-based security are covered separately, because security and host-based security are covered separately, because
of the different authentication mechanisms provided. To avoid of the different authentication mechanisms provided. To avoid
confusion about the different concepts, Section 3.4 describes the confusion about the different concepts, Section 3.4 describes the
concept of user authentication in more detail. concept of user authentication in more detail.
Key Management: o Key Management:
It is assumed that most of the security associations required for It is assumed that most of the security associations required for
the protection of RSVP signaling messages are already available, the protection of RSVP signaling messages are already available,
and hence key management was done in advance. There is, however, and hence key management was done in advance. There is, however,
an exception with respect to support for Kerberos. Using an exception with respect to support for Kerberos. Using
Kerberos, an entity is able to distribute a session key used for Kerberos, an entity is able to distribute a session key used for
RSVP signaling protection. RSVP signaling protection.
RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects: o RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
RSVP uses an INTEGRITY object in two places in a message. The RSVP uses an INTEGRITY object in two places in a message. The
first is in the RSVP message itself and covers the entire RSVP first is in the RSVP message itself and covers the entire RSVP
message as defined in [1]. The second is included in the message as defined in [1]. The second is included in the
POLICY_DATA object and defined in [2]. To differentiate the two POLICY_DATA object and defined in [2]. To differentiate the two
objects regarding their scope of protection, the two terms RSVP objects by their scope of protection, the two terms RSVP INTEGRITY
INTEGRITY and POLICY_DATA INTEGRITY object are used, respectively. and POLICY_DATA INTEGRITY object are used, respectively. The data
The data structure of the two objects, however, is the same. structure of the two objects, however, is the same.
Hop versus Peer: o Hop versus Peer:
In the past, the terminology for nodes addressed by RSVP has been In the past, the terminology for nodes addressed by RSVP has been
discussed considerably. In particular, two favorite terms have discussed considerably. In particular, two favorite terms have
been used: hop and peer. This document uses the term hop, which been used: hop and peer. This document uses the term hop, which
is different from an IP hop. Two neighboring RSVP nodes is different from an IP hop. Two neighboring RSVP nodes
communicating with each other are not necessarily neighboring IP communicating with each other are not necessarily neighboring IP
nodes (i.e., they may be more than one IP hop away). nodes (i.e., they may be more than one IP hop away).
3. Overview 3. Overview
This section describes the security mechanisms provided by RSVP. This section describes the security mechanisms provided by RSVP.
Although use of IPsec is mentioned in Section 10 of [1], the security Although use of IPsec is mentioned in Section 10 of [1], the other
mechanisms primarily envisioned for RSVP are described. security mechanisms primarily envisioned for RSVP are described.
3.1 The RSVP INTEGRITY Object 3.1. The RSVP INTEGRITY Object
The RSVP INTEGRITY object is the major component of RSVP security The RSVP INTEGRITY object is the major component of RSVP security
protection. This object is used to provide integrity and replay protection. This object is used to provide integrity and replay
protection for the content of the signaling message between two RSVP protection for the content of the signaling message between two RSVP
participating routers or between an RSVP router and host. participating routers or between an RSVP router and host.
Furthermore, the RSVP INTEGRITY object provides data origin Furthermore, the RSVP INTEGRITY object provides data origin
authentication. The attributes of the object are briefly described: authentication. The attributes of the object are briefly described:
Flags field: o Flags field:
The Handshake Flag is the only defined flag. It is used to The Handshake Flag is the only defined flag. It is used to
synchronize sequence numbers if the communication gets out of sync synchronize sequence numbers if the communication gets out of
(e.g., it allows a restarting host to recover the most recent sync (e.g., it allows a restarting host to recover the most
sequence number). Setting this flag to one indicates that the recent sequence number). Setting this flag to one indicates that
sender is willing to respond to an Integrity Challenge message. the sender is willing to respond to an Integrity Challenge
This flag can therefore be seen as a negotiation capability message. This flag can therefore be seen as a negotiation
transmitted within each INTEGRITY object. capability transmitted within each INTEGRITY object.
Key Identifier: o Key Identifier:
The Key Identifier selects the key used for verification of the The Key Identifier selects the key used for verification of the
Keyed Message Digest field and, hence, must be unique for 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 sender. It has a fixed 48-bit length. The generation of this
Identifier field is mostly a decision of the local host. [1] Key Identifier field is mostly a decision of the local host. [1]
describes this field as a combination of an address, sending describes this field as a combination of an address, sending
interface, and key number. We assume that the Key Identifier is interface, and key number. We assume that the Key Identifier is
simply a (keyed) hash value computed over a number of fields with simply a (keyed) hash value computed over a number of fields,
the requirement to be unique if more than one security association with the requirement to be unique if more than one security
is used in parallel between two hosts (e.g., as is the case with association is used in parallel between two hosts (e.g., as is
security associations having overlapping lifetimes). A receiving the case with security associations having overlapping
system uniquely identifies a security association based on the Key lifetimes). A receiving system uniquely identifies a security
Identifier and the sender's IP address. The sender's IP address association based on the Key Identifier and the sender's IP
may be obtained from the RSVP_HOP object or from the source IP address. The sender's IP address may be obtained from the
address of the packet if the RSVP_HOP object is not present. The RSVP_HOP object or from the source IP address of the packet if
sender uses the outgoing interface to determine which security the RSVP_HOP object is not present. The sender uses the outgoing
association to use. The term outgoing interface may be confusing. interface to determine which security association to use. The
The sender selects the security association based on the term "outgoing interface" may be confusing. The sender selects
receiver's IP address (i.e., the address of the next RSVP-capable the security association based on the receiver's IP address
router). The process of determining which node is the next (i.e., the address of the next RSVP-capable router). The process
RSVP-capable router is not further specified and is likely to be of determining which node is the next RSVP-capable router is not
statically configured. further specified and is likely to be statically configured.
Sequence Number: o Sequence Number:
The sequence number used by the INTEGRITY object is 64 bits in The sequence number used by the INTEGRITY object is 64 bits in
length, and the starting value can be selected arbitrarily. The length, and the starting value can be selected arbitrarily. The
length of the sequence number field was chosen to avoid exhaustion length of the sequence number field was chosen to avoid
during the lifetime of a security association as stated in Section exhaustion during the lifetime of a security association as
3 of [1]. In order for the receiver to distinguish between a new stated in Section 3 of [1]. In order for the receiver to
and a replayed message, the sequence number must be monotonically distinguish between a new and a replayed message, the sequence
incremented modulo 2^64 for each message. We assume that the number must be monotonically incremented (modulo 2^64) for each
first sequence number seen (i.e., the starting sequence number) is message. We assume that the first sequence number seen (i.e.,
stored somewhere. The modulo-operation is required because the the starting sequence number) is stored somewhere. The modulo-
starting sequence number may be an arbitrary number. The receiver operation is required because the starting sequence number may be
therefore only accepts packets with a sequence number larger an arbitrary number. The receiver therefore only accepts packets
(modulo 2^64) than the previous packet. As explained in [1] this with a sequence number larger (modulo 2^64) than the previous
process is started by handshaking and agreeing on an initial packet. As explained in [1] this process is started by
sequence number. If no such handshaking is available then the handshaking and agreeing on an initial sequence number. If no
initial sequence number must be part of the establishment of the such handshaking is available then the initial sequence number
security association. must be part of the establishment of the security association.
The generation and storage of sequence numbers is an important The generation and storage of sequence numbers is an important
step in preventing replay attacks and is largely determined by the step in preventing replay attacks and is largely determined by
capabilities of the system in presence of system crashes, failures the capabilities of the system in the presence of system crashes,
and restarts. Section 3 of [1] explains some of the most failures, and restarts. Section 3 of [1] explains some of the
important considerations. However, the description of how the most important considerations. However, the description of how
receiver distinguishes proper from improper sequence numbers is the receiver distinguishes proper from improper sequence numbers
incomplete--it implicitly assumes that gaps large enough to cause is incomplete: it implicitly assumes that gaps large enough to
the sequence number to wrap around cannot occur. cause the sequence number to wrap around cannot occur.
If delivery in order were guaranteed, the following procedure If delivery in order were guaranteed, the following procedure
would work: The receiver keeps track of the first sequence number would work: the receiver keeps track of the first sequence number
received, INIT-SEQ, and most recent sequence number received, received, INIT-SEQ, and the most recent sequence number received,
LAST-SEQ, for each key identifier in a security association. When LAST-SEQ, for each key identifier in a security association.
the first message is received, set INIT-SEQ = LAST-SEQ = value When the first message is received, set INIT-SEQ = LAST-SEQ =
received and accept. When a subsequent message is received, if value received and accept. When a subsequent message is
its sequence number is strictly between LAST-SEQ and INIT-SEQ, received, if its sequence number is strictly between LAST-SEQ and
modulo 2^64, accept and update LAST-SEQ with the value just INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the
received. If it is between INIT-SEQ and LAST-SEQ, inclusive, value just received. If it is between INIT-SEQ and LAST-SEQ,
modulo 2^64, reject and leave the value of LAST-SEQ unchanged. inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ
Because delivery in order is not guaranteed, the above rules need unchanged. Because delivery in order is not guaranteed, the
to be combined with a method of allowing a fixed sized window in above rules need to be combined with a method of allowing a fixed
the neighborhood of LAST-SEQ for out-of-order delivery, for sized window in the neighborhood of LAST-SEQ for out-of-order
example, as described in Appendix C of [3]. delivery, for example, as described in Appendix C of [3].
Keyed Message Digest: o Keyed Message Digest:
The Keyed Message Digest is a security mechanism built into RSVP The Keyed Message Digest is a security mechanism built into RSVP
and used to provide integrity protection of a signaling message that used to provide integrity protection of a signaling message
(including its sequence number). Prior to computing the value for (including its sequence number). Prior to computing the value
the Keyed Message Digest field, the Keyed Message Digest field for the Keyed Message Digest field, the Keyed Message Digest
itself must be set to zero and a keyed hash computed over the field itself must be set to zero and a keyed hash computed over
entire RSVP packet. The Keyed Message Digest field is variable in the entire RSVP packet. The Keyed Message Digest field is
length but must be a multiple of four octets. If HMAC-MD5 is variable in length but must be a multiple of four octets. If
used, then the output value is 16 bytes long. The keyed hash HMAC-MD5 is used, then the output value is 16 bytes long. The
function HMAC-MD5 [4] is required for a RSVP implementation as keyed hash function HMAC-MD5 [4] is required for an RSVP
noted in Section 1 of [1]. Hash algorithms other than MD5 [5] implementation, as noted in Section 1 of [1]. Hash algorithms
like SHA-1 [19] may also be supported. other than MD5 [5], like SHA-1 [15], may also be supported.
The key used for computing this Keyed Message Digest may be The key used for computing this Keyed Message Digest may be
obtained from the pre-shared secret, which is either manually obtained from the pre-shared secret, which is either manually
distributed or the result of a key management protocol. No key distributed or the result of a key management protocol. No key
management protocol, however, is specified to create the desired management protocol, however, is specified to create the desired
security associations. Also, no guidelines for key length are security associations. Also, no guidelines for key length are
given. It should be recommended that HMAC-MD5 keys be 128 bits given. It should be recommended that HMAC-MD5 keys be 128 bits
and SHA-1 key 160 bits, as in IPsec AH [20] and ESP [21]. and SHA-1 keys 160 bits, as in IPsec AH [16] and ESP [17].
3.2 Security Associations 3.2. Security Associations
Different attributes are stored for security associations of sending Different attributes are stored for security associations of sending
and receiving systems (i.e., unidirectional security associations). and receiving systems (i.e., unidirectional security associations).
The sending system needs to maintain the following attributes in such The sending system needs to maintain the following attributes in such
a security association [1]: a security association [1]:
o Authentication algorithm and algorithm mode o Authentication algorithm and algorithm mode
o Key o Key
o Key Lifetime o Key Lifetime
o Sending Interface o Sending Interface
o Latest sequence number (received with this key identifier) o Latest sequence number (received with this key identifier)
The receiving system has to store the following fields: The receiving system has to store the following fields:
o Authentication algorithm and algorithm mode o Authentication algorithm and algorithm mode
o Key o Key
o Key Lifetime o Key Lifetime
o Source address of the sending system o Source address of the sending system
o List of last n sequence numbers (received with this key o List of last n sequence numbers (received with this key
identifier) identifier)
Note that the security associations need to have additional fields to Note that the security associations need to have additional fields to
indicate their state. It is necessary to have an overlapping indicate their state. It is necessary to have overlapping lifetimes
lifetime of security associations to avoid interrupting an ongoing of security associations to avoid interrupting an ongoing
communication because of expired security associations. During such communication because of expired security associations. During such
a period of overlapping lifetime it is necessary to authenticate 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 either one or both active keys. As mentioned in [1], a sender and a
receiver may have multiple active keys simultaneously.If more than receiver may have multiple active keys simultaneously.If more than
one algorithm is supported then the algorithm used must be specified one algorithm is supported, then the algorithm used must be specified
for a security association. for a security association.
3.3 RSVP Key Management Assumptions 3.3. RSVP Key Management Assumptions
[6] assumes that security associations are already available. An RFC 2205 [6] assumes that security associations are already
implementation must support manual key distribution as noted in available. An implementation must support manual key distribution as
Section 5.2 of [1]. Manual key distribution, however, has different noted in Section 5.2 of [1]. Manual key distribution, however, has
requirements for key storage - a simple plaintext ASCII file may be different requirements for key storage; a simple plaintext ASCII file
sufficient in some cases. If multiple security associations with may be sufficient in some cases. If multiple security associations
different lifetimes need to be supported at the same time, then a key with different lifetimes need to be supported at the same time, then
engine would be more appropriate. Further security requirements a key engine would be more appropriate. Further security
listed in Section 5.2 of [1] are the following: requirements listed in Section 5.2 of [1] are the following:
o The manual deletion of security associations must be supported. o The manual deletion of security associations must be supported.
o The key storage should persist a system restart.
o The key storage should persist during a system restart.
o Each key must be assigned a specific lifetime and a specific Key o Each key must be assigned a specific lifetime and a specific Key
Identifier. Identifier.
3.4 Identity Representation 3.4. Identity Representation
In addition to host-based authentication with the INTEGRITY object In addition to host-based authentication with the INTEGRITY object
inside the RSVP message, user-based authentication is available as inside the RSVP message, user-based authentication is available as
introduced in [2]. Section 2 of [7] states that "Providing policy introduced in [2]. Section 2 of [7] states that "Providing policy
based admission control mechanism based on user identities or based admission control mechanism based on user identities or
application is one of the prime requirements." To identify the user application is one of the prime requirements." To identify the user
or the application, a policy element called AUTH_DATA, which is or the application, a policy element called AUTH_DATA, which is
contained in the POLICY_DATA object, is created by the RSVP daemon at contained in the POLICY_DATA object, is created by the RSVP daemon at
the user's host and transmitted inside the RSVP message. The the user's host and transmitted inside the RSVP message. The
structure of the POLICY_DATA element is described in [2]. Network structure of the POLICY_DATA element is described in [2]. Network
nodes like the policy decision point (PDP) then use the information nodes acting as policy decision points (PDPs) then use the
contained in the AUTH_DATA element to authenticate the user and to information contained in the AUTH_DATA element to authenticate the
allow policy-based admission control to be executed. As mentioned in user and to allow policy-based admission control to be executed. As
[7], the policy element is processed and the PDP replaces the old mentioned in [7], the policy element is processed and the PDP
element with a new one for forwarding to the next hop router. 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 A detailed description of the POLICY_DATA element can be found in
[2]. The attributes contained in the authentication data policy [2]. The attributes contained in the authentication data policy
element AUTH_DATA, which is defined in [7], are briefly explained in element AUTH_DATA, which is defined in [7], are briefly explained in
this Section. Figure 1 shows the abstract structure of the RSVP this Section. Figure 1 shows the abstract structure of the RSVP
message with its security-relevant objects and the scope of message with its security-relevant objects and the scope of
protection. The RSVP INTEGRITY object (outer object) covers the protection. The RSVP INTEGRITY object (outer object) covers the
entire RSVP message, whereas the POLICY_DATA INTEGRITY object only entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
covers objects within the POLICY_DATA element. covers objects within the POLICY_DATA element.
skipping to change at page 10, line 19 skipping to change at page 10, line 19
| +-------------------------------------------+| | +-------------------------------------------+|
| | INTEGRITY +------------------------------+|| | | INTEGRITY +------------------------------+||
| | Object | AUTH_DATA Object ||| | | Object | AUTH_DATA Object |||
| | +------------------------------+|| | | +------------------------------+||
| | | Various Authentication ||| | | | Various Authentication |||
| | | Attributes ||| | | | Attributes |||
| | +------------------------------+|| | | +------------------------------+||
| +-------------------------------------------+| | +-------------------------------------------+|
+--------------------------------------------------------+ +--------------------------------------------------------+
Figure 1: Security Relevant Objects and Elements within the RSVP Figure 1: Security Relevant Objects and Elements
Message within the RSVP Message.
The AUTH_DATA object contains information for identifying users and The AUTH_DATA object contains information for identifying users and
applications together with credentials for those identities. The applications together with credentials for those identities. The
main purpose of these identities seems to be usage for policy-based main purpose of these identities seems to be usage for policy-based
admission control and not authentication and key management. As admission control and not authentication and key management. As
noted in Section 6.1 of [7], an RSVP message may contain more than 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 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 AUTH_DATA object. As indicated in Figure 1 and in [7], one AUTH_DATA
object may contain more than one authentication attribute. A typical object may contain more than one authentication attribute. A typical
configuration for Kerberos-based user authentication includes at configuration for Kerberos-based user authentication includes at
least the Policy Locator and an attribute containing the Kerberos least the Policy Locator and an attribute containing the Kerberos
session ticket. session ticket.
Successful user authentication is the basis for executing Successful user authentication is the basis for executing policy-
policy-based admission control. Additionally, other information such based admission control. Additionally, other information such as
as time-of-day , application type, location information, group time-of-day, application type, location information, group
membership, etc. may be relevant to implement an access control membership, etc. may be relevant to the implementation of an access
policy. control policy.
The following attributes are defined for the usage in the AUTH_DATA The following attributes are defined for use in the AUTH_DATA object:
object:
o Policy Locator
1. Policy Locator
* ASCII_DN * ASCII_DN
* UNICODE_DN * UNICODE_DN
* ASCII_DN_ENCRYPT * ASCII_DN_ENCRYPT
* UNICODE_DN_ENCRYPT * UNICODE_DN_ENCRYPT
The policy locator string that is an X.500 distinguished name The policy locator string is an X.500 distinguished name (DN)
(DN) used to locate user or application specific policy used to locate user or application-specific policy information.
information. The following types of X.500 DNs are listed: The four types of X.500 DNs are listed above. The first two
The first two types are the ASCII and the Unicode representation types are the ASCII and the Unicode representation of the user
of the user or application DN identity. The two "encrypted" or application DN identity. The two "encrypted" distinguished
distinguished name types are either encrypted with the Kerberos name types are either encrypted with the Kerberos session key
session key or with the private key of the user's digital or with the private key of the user's digital certificate
certificate (i.e., digitally signed). The term encrypted (i.e., digitally signed). The term "encrypted together with a
together with a digital signature is easy to misconceive. If digital signature" is easy to misconceive. If user identity
user identity confidentiality is provided, then the policy confidentiality is provided, then the policy locator has to be
locator has to be encrypted with the public key of the recipient. encrypted with the public key of the recipient. How to obtain
How to obtain this public key is not described in the document. this public key is not described in the document. This detail
Such an issue may be specified in a concrete architecture where may be specified in a concrete architecture in which RSVP is
RSVP is used. used.
2. Credentials
o Credentials
Two cryptographic credentials are currently defined for a user: Two cryptographic credentials are currently defined for a user:
Authentication with Kerberos V5 [8], and authentication with the authentication with Kerberos V5 [8], and authentication with
help of digital signatures based on X.509 [22] and PGP [23]. The the help of digital signatures based on X.509 [18] and PGP
following list contains all defined credential types currently [19]. The following list contains all defined credential types
available and defined in [7]: currently available and defined in [7]:
+--------------+--------------------------------+ +--------------+--------------------------------+
| Credential | Description | | Credential | Description |
| Type | | | Type | |
+===============================================| +===============================================|
| ASCII_ID | User or application identity | | ASCII_ID | User or application identity |
| | encoded as an ASCII string | | | encoded as an ASCII string |
+--------------+--------------------------------+ +--------------+--------------------------------+
| UNICODE_ID | User or application identity | | UNICODE_ID | User or application identity |
| | encoded as a Unicode string | | | encoded as a Unicode string |
+--------------+--------------------------------+ +--------------+--------------------------------+
| KERBEROS_TKT | Kerberos V5 session ticket | | KERBEROS_TKT | Kerberos V5 session ticket |
+--------------+--------------------------------+ +--------------+--------------------------------+
| X509_V3_CERT | X.509 V3 certificate | | X509_V3_CERT | X.509 V3 certificate |
+--------------+--------------------------------+ +--------------+--------------------------------+
| PGP_CERT | PGP certificate | | PGP_CERT | PGP certificate |
+--------------+--------------------------------+ +--------------+--------------------------------+
Figure 2: Credentials Supported in RSVP Figure 2: Credentials Supported in RSVP.
The first two credentials contain only a plaintext string, and The first two credentials contain only a plaintext string, and
therefore they do not provide cryptographic user authentication. therefore they do not provide cryptographic user
These plaintext strings may be used to identify applications, authentication. These plaintext strings may be used to
which are included for policy-based admission control. Note that identify applications, that are included for policy-based
these plain-text identifiers may, however, be protected if either admission control. Note that these plain-text identifiers may,
the RSVP INTEGRITY or the INTEGRITY object of the POLICY_DATA however, be protected if either the RSVP INTEGRITY or the
element is present. Note that the two INTEGRITY objects can INTEGRITY object of the POLICY_DATA element is present. Note
terminate at different entities depending on the network that the two INTEGRITY objects can terminate at different
structure. The digital signature may also provide protection of entities depending on the network structure. The digital
application identifiers. A protected application identity (and signature may also provide protection of application
the entire content of the POLICY_DATA element) cannot be modified identifiers. A protected application identity (and the entire
as long as no policy ignorant nodes are encountered in between. content of the POLICY_DATA element) cannot be modified as long
A Kerberos session ticket, as previously mentioned, is the ticket as no policy-ignorant nodes are encountered in between.
of a Kerberos AP_REQ message [8] without the Authenticator.
Normally, the AP_REQ message is used by a client to authenticate A Kerberos session ticket, as previously mentioned, is the
to a server. The INTEGRITY object (e.g., of the POLICY_DATA ticket of a Kerberos AP_REQ message [8] without the
element) provides the functionality of the Kerberos Authenticator. Normally, the AP_REQ message is used by a
Authenticator, namely protecting against replay and showing that client to authenticate to a server. The INTEGRITY object
the user was able to retrieve the session key following the (e.g., of the POLICY_DATA element) provides the functionality
Kerberos protocol. This is, however, only the case if the of the Kerberos Authenticator, namely protecting against replay
Kerberos session was used for the keyed message digest field of and showing that the user was able to retrieve the session key
the INTEGRITY object. Section 7 of [1] discusses some issues for following the Kerberos protocol. This is, however, only the
establishment of keys for the INTEGRITY object. The case if the Kerberos session was used for the keyed message
establishment of the security association for the RSVP INTEGRITY digest field of the INTEGRITY object. Section 7 of [1]
object with the inclusion of the Kerberos Ticket within the discusses some issues for establishment of keys for the
AUTH_DATA element may be complicated by the fact that the ticket INTEGRITY object. The establishment of the security
can be decrypted by node B whereas the RSVP INTEGRITY object association for the RSVP INTEGRITY object with the inclusion of
terminates at a different host C. The Kerberos session ticket the Kerberos Ticket within the AUTH_DATA element may be
contains, among many other fields, the session key. The Policy complicated by the fact that the ticket can be decrypted by
Locator may also be encrypted with the same session key. The node B, whereas the RSVP INTEGRITY object terminates at a
protocol steps that need to be executed to obtain such a Kerberos different host C.
service ticket are not described in [7] and may involve several
roundtrips depending on many Kerberos-related factors. The 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 Kerberos ticket does not need to be included in every RSVP
message as an optimization, as described in Section 7.1 of [1]. message, as described in Section 7.1 of [1]. Thus, the
Thus the receiver must store the received service ticket. If the receiver must store the received service ticket. If the
lifetime of the ticket has expired, then a new service ticket lifetime of the ticket has expired, then a new service ticket
must be sent. If the receiver lost its state information must be sent. If the receiver lost its state information
(because of a crash or restart) then it may transmit an Integrity (because of a crash or restart) then it may transmit an
Challenge message to force the sender to re-transmit a new Integrity Challenge message to force the sender to re-transmit
service ticket. 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 If either the X.509 V3 or the PGP certificate is included in
digital signature computed over the entire AUTH_DATA object the policy element, then a digital signature must be added.
provides authentication and integrity protection. The SubType of The digital signature computed over the entire AUTH_DATA object
the digital signature authentication attribute is set to zero provides authentication and integrity protection. The SubType
before computing the digital signature. Whether or not a of the digital signature authentication attribute is set to
guarantee of freshness with replay protection (either timestamps zero before computing the digital signature. Whether or not a
or sequence numbers) is provided by the digital signature is an guarantee of freshness with replay protection (either
open issue as discussed in Section 4.3 timestamps or sequence numbers) is provided by the digital
3. Digital Signature signature is an open issue as discussed in Section 4.3.
The digital signature computed over the data of the AUTH_DATA
object must be the last attribute. The algorithm used to compute o Digital Signature
the digital signature depends on the authentication mode listed
in the credential. This is only partially true, because, for The digital signature computed over the contents of the
example, PGP again allows different algorithms to be used for AUTH_DATA object must be the last attribute. The algorithm
computing a digital signature. The algorithm identifier used for used to compute the digital signature depends on the
computing the digital signature is not included in the authentication mode listed in the credential. This is only
certificate itself. The algorithm identifier included in the partially true, because, for example, PGP again allows
certificate only serves the purpose of allowing the verification different algorithms to be used for computing a digital
of the signature computed by the certificate authority (except signature. The algorithm identifier used for computing the
for the case of self-signed certificates). digital signature is not included in the certificate itself.
4. Policy Error Object 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 The Policy Error Object is used in the case of a failure of
policy-based admission control or other credential verification. policy-based admission control or other credential
Currently available error messages allow notification if the verification. Currently available error messages allow
credentials are expired (EXPIRED_CREDENTIALS), if the notification if the credentials are expired
authorization process disallowed the resource request (EXPIRED_CREDENTIALS), if the authorization process disallowed
(INSUFFICIENT_PRIVILEGES), or if the given set of credentials is the resource request (INSUFFICIENT_PRIVILEGES), or if the given
not supported (UNSUPPORTED_CREDENTIAL_TYPE). The last error set of credentials is not supported
message returned by the network allows the user's host to (UNSUPPORTED_CREDENTIAL_TYPE). The last error message returned
discover the type of credentials supported. Particularly for by the network allows the user's host to discover the type of
mobile environments this might be quite inefficient. credentials supported. Particularly for mobile environments
Furthermore, it is unlikely that a user supports different types this might be quite inefficient. Furthermore, it is unlikely
of credentials. The purpose of the error message that a user supports different types of credentials. The
IDENTITY_CHANGED is unclear. Also, the protection of the error purpose of the error message IDENTITY_CHANGED is unclear.
message is not discussed in [7]. Also, the protection of the error message is not discussed in
[7].
3.5 RSVP Integrity Handshake 3.5. RSVP Integrity Handshake
The Integrity Handshake protocol was designed to allow a crashed or The Integrity Handshake protocol was designed to allow a crashed or
restarted host to obtain the latest valid challenge value stored at restarted host to obtain the latest valid challenge value stored at
the receiving host. Due to the absence of key management, it must be 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 guaranteed that two messages do not use the same sequence number with
the same key. A host stores the latest sequence number of a the same key. A host stores the latest sequence number of a
cryptographically verified message. An adversary can replay cryptographically verified message. An adversary can replay
eavesdropped packets if the crashed host has lost its sequence eavesdropped packets if the crashed host has lost its sequence
numbers. A signaling message from the real sender with a new numbers. A signaling message from the real sender with a new
sequence number would therefore allow the crashed host to update the sequence number would therefore allow the crashed host to update the
sequence number field and prevent further replays. Hence, if there sequence number field and prevent further replays. Hence, if there
is a steady flow of RSVP protected messages between the two hosts, an is a steady flow of RSVP-protected messages between the two hosts, an
attacker may find it difficult to inject old messages, because new, attacker may find it difficult to inject old messages, because new,
authenticated messages with higher sequence numbers arrive and get authenticated messages with higher sequence numbers arrive and get
stored immediately. stored immediately.
The following description explains the details of a RSVP Integrity The following description explains the details of an RSVP Integrity
Handshake that is started by Node A after recovering from a Handshake that is started by Node A after recovering from a
synchronization failure: synchronization failure:
Integrity Challenge Integrity Challenge
(1) Message (including (1) Message (including
+----------+ a Cookie) +----------+ +----------+ a Cookie) +----------+
| |-------------------------->| | | |-------------------------->| |
| Node A | | Node B | | Node A | | Node B |
| |<--------------------------| | | |<--------------------------| |
+----------+ Integrity Response +----------+ +----------+ Integrity Response +----------+
(2) Message (including (2) Message (including
the Cookie and the the Cookie and the
INTEGRITY object) INTEGRITY object)
Figure 3: RSVP Integrity Handshake Figure 3: RSVP Integrity Handshake.
The details of the messages are as follows: The details of the messages are as follows:
CHALLENGE:=(Key Identifier, Challenge Cookie) CHALLENGE:=(Key Identifier, Challenge Cookie)
Integrity Challenge Message:=(Common Header, CHALLENGE) Integrity Challenge Message:=(Common Header, CHALLENGE)
Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE) Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
The "Challenge Cookie" is suggested to be a MD5 hash of a local The "Challenge Cookie" is suggested to be a MD5 hash of a local
secret and a timestamp [1]. secret and a timestamp [1].
The Integrity Challenge message is not protected with an INTEGRITY The Integrity Challenge message is not protected with an INTEGRITY
object as shown in the protocol flow above. As explained in Section 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 10 of [1] this was done to avoid problems in situations where both
communicating parties do not have a valid starting sequence number. communicating parties do not have a valid starting sequence number.
skipping to change at page 14, line 34 skipping to change at page 14, line 44
The "Challenge Cookie" is suggested to be a MD5 hash of a local The "Challenge Cookie" is suggested to be a MD5 hash of a local
secret and a timestamp [1]. secret and a timestamp [1].
The Integrity Challenge message is not protected with an INTEGRITY The Integrity Challenge message is not protected with an INTEGRITY
object as shown in the protocol flow above. As explained in Section 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 10 of [1] this was done to avoid problems in situations where both
communicating parties do not have a valid starting sequence number. communicating parties do not have a valid starting sequence number.
Using the RSVP Integrity Handshake protocol is recommended although Using the RSVP Integrity Handshake protocol is recommended although
it is not mandatory (since it may not be needed in all network it is not mandatory (because it may not be needed in all network
environments). environments).
4. Detailed Security Property Discussion 4. Detailed Security Property Discussion
The purpose of this section is to describe the protection of the This section describes the protection of the RSVP-provided mechanisms
RSVP-provided mechanisms individually for authentication, for authentication, authorization, integrity and replay protection
authorization, integrity and replay protection, user identity individually, user identity confidentiality, and confidentiality of
confidentiality, and confidentiality of the signaling messages. the signaling messages,
4.1 Network Topology 4.1. Network Topology
The main purpose of this paragraph is to show the basic interfaces in This paragraph shows the basic interfaces in a simple RSVP network
a simple RSVP network architecture. The architecture below assumes architecture. The architecture below assumes that there is only a
that there is only a single domain and that two routers are RSVP and single domain and that the two routers are RSVP- and policy-aware.
policy aware. These assumptions are relaxed in the individual These assumptions are relaxed in the individual paragraphs, as
paragraphs as necessary. Layer 2 devices between the clients and necessary. Layer 2 devices between the clients and their
their corresponding first hop routers are not shown. Other network corresponding first-hop routers are not shown. Other network
elements like a Kerberos Key Distribution Center and for example a elements like a Kerberos Key Distribution Center and, for example, an
LDAP server, from which the PDP retrieves its policies are also LDAP server from which the PDP retrieves its policies are also
omitted. The security of various interfaces to the individual omitted. The security of various interfaces to the individual
servers (KDC, PDP, etc.) depends very much on the security policy of servers (KDC, PDP, etc.) depends very much on the security policy of
a specific network service provider. a specific network service provider.
+--------+ +--------+
| Policy | | Policy |
+----|Decision| +----|Decision|
| | Point +---+ | | Point +---+
| +--------+ | | +--------+ |
| | | |
| | | |
+------+ +-+----+ +---+--+ +------+ +------+ +-+----+ +---+--+ +------+
|Client| |Router| |Router| |Client| |Client| |Router| |Router| |Client|
| A +-------+ 1 +--------+ 2 +----------+ B | | A +-------+ 1 +--------+ 2 +----------+ B |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
Figure 4: Simple RSVP Architecture Figure 4: Simple RSVP Architecture.
4.2 Host/Router 4.2. Host/Router
When considering authentication in RSVP it is important to make a When considering authentication in RSVP, it is important to make a
distinction between user and host authentication of the signaling distinction between user and host authentication of the signaling
messages . By using the RSVP INTEGRITY object the host is messages. The host is authenticated using the RSVP INTEGRITY object,
authenticated while credentials inside the AUTH_DATA object can be whereas credentials inside the AUTH_DATA object can be used to
used to authenticate the user. In this section the focus is on host authenticate the user. In this section, the focus is on host
authentication whereas the next section covers user authentication. 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.
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 the 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 must therefore be available before
signaling is started.
* Kerberos for the RSVP INTEGRITY object * 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 As described in Section 7 of [1], Kerberos may be used to
principal name (and realm information) of the other node is create the key for the RSVP INTEGRITY object. How to learn
outside the scope of [1]. [24] describes a way to distribute the principal name (and realm information) of the other node
principal and realm information via DNS, which can be used for is outside the scope of [1]. [20] describes a way to
this purpose (assuming that the FQDN or the IP address of the distribute principal and realm information via DNS, which can
other node for which this information is desired is known). All be used for this purpose (assuming that the FQDN or the IP
that is required is to encapsulate the Kerberos ticket inside the address of the other node for which this information is
policy element. It is furthermore mentioned that Kerberos desired is known). All that is required is to encapsulate the
tickets with expired lifetime must not be used and the initiator Kerberos ticket inside the policy element. It is furthermore
is responsible for requesting and exchanging a new service ticket mentioned that Kerberos tickets with expired lifetime must not
before expiration. be used, and the initiator is responsible for requesting and
RSVP multicast processing in combination with Kerberos requires exchanging a new service ticket before expiration.
additional considerations:
Section 7 of [1] states that in the multicast case all receivers RSVP multicast processing in combination with Kerberos
must share a single key with the Kerberos Authentication Server, involves additional considerations. Section 7 of [1] states
i.e., a single principal used for all receivers). From a that in the multicast case all receivers must share a single
personal discussion with Rodney Hess it seems that there is key with the Kerberos Authentication Server (i.e., a single
currently no other solution available in the context of Kerberos. principal used for all receivers). From a personal discussion
Multicast handling therefore leaves some open questions in this with Rodney Hess, it seems that there is currently no other
context. 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 In the case where one entity crashed, the established security
association is lost and therefore the other node must retransmit association is lost and therefore the other node must
the service ticket . The crashed entity can use an Integrity retransmit the service ticket. The crashed entity can use an
Challenge message to request a new Kerberos ticket to be Integrity Challenge message to request a new Kerberos ticket
retransmitted by the other node. If a node receives such a to be retransmitted by the other node. If a node receives
request, then a reply message must be returned. such a request, then a reply message must be returned.
2. Integrity protection
Integrity protection between the user's host and the first hop (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 router is based on the RSVP INTEGRITY object. HMAC-MD5 is
preferred, although other keyed hash functions may also be used preferred, although other keyed hash functions may also be used
within the RSVP INTEGRITY object. In any case, both within the RSVP INTEGRITY object. In any case, both
communicating entities must have a security association that communicating entities must have a security association that
indicates the algorithm to use. This may, however, be difficult, indicates the algorithm to use. This may, however, be difficult,
because no negotiation protocol is defined to agree on a specific because no negotiation protocol is defined to agree on a specific
algorithm. Hence, if RSVP is used in a mobile environment, it is algorithm. Hence, if RSVP is used in a mobile environment, it is
likely that HMAC-MD5 is the only usable algorithm for the RSVP likely that HMAC-MD5 is the only usable algorithm for the RSVP
INTEGRITY object. Only in local environments may it be useful to INTEGRITY object. Only in local environments may it be useful to
switch to a different keyed hash algorithm. The other possible switch to a different keyed hash algorithm. The other possible
alternative is that every implementation must support the most alternative is that every implementation support the most
important keyed hash algorithms for example MD5, SHA-1, important keyed hash algorithms. e.g., MD5, SHA-1, RIPEMD-160,
RIPEMD-160, etc. HMAC-MD5 was mainly chosen because of its etc. HMAC-MD5 was chosen mainly because of its performance
performance characteristics. The weaknesses of MD5 [25] are characteristics. The weaknesses of MD5 [21] are known and were
known and described in [26]. Other algorithms like SHA-1 [19] initially described in [22]. Other algorithms like SHA-1 [15]
and RIPEMD-160 [25] have stronger security properties. and RIPEMD-160 [21] have stronger security properties.
3. Replay Protection
(3) Replay Protection
The main mechanism used for replay protection in RSVP is based on The main mechanism used for replay protection in RSVP is based on
sequence numbers, whereby the sequence number is included in the sequence numbers, whereby the sequence number is included in the
RSVP INTEGRITY object. The properties of this sequence number RSVP INTEGRITY object. The properties of this sequence number
mechanism are described in Section 3.1. The fact that the 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 receiver stores a list of sequence numbers is an indicator for a
window mechanism. This somehow conflicts with the requirement window mechanism. This somehow conflicts with the requirement
that the receiver only has to store the highest number given in that the receiver only has to store the highest number given in
Section 3 of [1]. We assume that this is a typo. Section 4.2 of Section 3 of [1]. We assume that this is an oversight. Section
[1] gives a few comments about the out-of-order delivery and the 4.2 of [1] gives a few comments about the out-of-order delivery
ability of an implementation to specify the replay window. and the ability of an implementation to specify the replay
Appendix C of [3] describes a window mechanism for handling window. Appendix C of [3] describes a window mechanism for
out-of-sequence delivery. handling out-of-sequence delivery.
4. Integrity Handshake
(4) Integrity Handshake
The mechanism of the Integrity Handshake is explained in Section The mechanism of the Integrity Handshake is explained in Section
Section 3.5. The Cookie value is suggested to be hash of a local 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 secret and a timestamp. The Cookie value is not verified by the
receiver. The mechanism used by the Integrity Handshake is a receiver. The mechanism used by the Integrity Handshake is a
simple Challenge/Response message, which assumes that the key simple Challenge/Response message, which assumes that the key
shared between the two hosts survives the crash. If, however, shared between the two hosts survives the crash. If, however,
the security association is dynamically created, then this the security association is dynamically created, then this
assumption may not be true. assumption may not be true.
In Section 10 of [1] the authors note that an adversary can
create a faked Integrity Handshake message including challenge In Section 10 of [1], the authors note that an adversary can
cookies. Subsequently it could store the received response and create a faked Integrity Handshake message that includes
later try to replay these responses while a responder recovers challenge cookies. Subsequently, it could store the received
from a crash or restart. If this replayed Integrity Response response and later try to replay these responses while a
value is valid and has a lower sequence number than actually responder recovers from a crash or restart. If this replayed
used, then this value is stored at the recovering host. In order Integrity Response value is valid and has a lower sequence number
for this attack to be successful the adversary must either have than actually used, then this value is stored at the recovering
collected a large number of challenge/response value pairs or host. In order for this attack to be successful, the adversary
have "discovered" the cookie generation mechanism (for example by must either have collected a large number of challenge/response
knowing the local secret). The collection of Challenge/Response value pairs or have "discovered" the cookie generation mechanism
pairs is even more difficult, because they depend on the Cookie (for example by knowing the local secret). The collection of
value, the sequence number included in the response message, and Challenge/Response pairs is even more difficult, because they
the shared key used by the INTEGRITY object. depend on the Cookie value, the sequence number included in the
5. Confidentiality response message, and the shared key used by the INTEGRITY
object.
(5) Confidentiality
Confidentiality is not considered to be a security requirement Confidentiality is not considered to be a security requirement
for RSVP. Hence it is not supported by RSVP, except as described for RSVP. Hence, it is not supported by RSVP, except as
in paragraph d) of Section 4.3. This assumption may not hold, described in paragraph d) of Section 4.3. This assumption may
however, for enterprises or carriers who want to protect, in not hold, however, for enterprises or carriers who want to
addition to users' identities, also billing data, network usage protect billing data, network usage patterns, or network
patterns, or network configurations from eavesdropping and configurations, in addition to users' identities, from
traffic analysis. Confidentiality may also help make certain eavesdropping and traffic analysis. Confidentiality may also
other attacks more difficult. For example, the PathErr attack help make certain other attacks more difficult. For example, the
described in Section 5.2 is harder to carry out if the attacker PathErr attack described in Section 5.2 is harder to carry out if
cannot observe the Path message to which the PathErr corresponds. the attacker cannot observe the Path message to which the PathErr
6. Authorization corresponds.
(6) Authorization
The task of authorization consists of two subcategories: network The task of authorization consists of two subcategories: network
access authorization and RSVP request authorization. Access access authorization and RSVP request authorization. Access
authorization is provided when a node is authenticated to the authorization is provided when a node is authenticated to the
network, e.g., using EAP [27] in combination with AAA protocols network, e.g., using EAP [23] in combination with AAA protocols
(for example using RADIUS [28] or DIAMETER [9]). Issues related (for example, RADIUS [24] or DIAMETER [9]). Issues related to
to network access authentication and authorization are outside network access authentication and authorization are outside the
the scope of RSVP. scope of RSVP.
The second authorization refers to RSVP itself. Depending on the The second authorization refers to RSVP itself. Depending on the
network configuration: network configuration:
* the router either forwards the received RSVP request to the * the router either forwards the received RSVP request to the
policy decision point, e.g., by using COPS [10] and [11],to policy decision point (e.g., using COPS [10] and [11]) to
request that an admission control procedure be executed or request that an admission control procedure be executed, or
* the router supports the functionality of a PDP and therefore * the router supports the functionality of a PDP and, therefore,
there is no need to forward the request or there is no need to forward the request, or
* the router may already be configured with the appropriate * the router may already be configured with the appropriate
policy information to decide locally whether to grant this policy information to decide locally whether to grant this
request or not request.
Based on the result of the admission control, the request may be Based on the result of the admission control, the request may be
granted or rejected. Information about the resource-requesting granted or rejected. Information about the resource-requesting
entity must be available to provide policy-based admission entity must be available to provide policy-based admission
control. control.
7. Performance
The computation of the keyed message digest for a RSVP INTEGRITY (7) Performance
The computation of the keyed message digest for an RSVP INTEGRITY
object does not represent a performance problem. The protection object does not represent a performance problem. The protection
of signaling messages is usually not a problem, because these of signaling messages is usually not a problem, because these
messages are transmitted at a low rate. Even a high volume of messages are transmitted at a low rate. Even a high volume of
messages does not cause performance problems for a RSVP routers messages does not cause performance problems for an RSVP router
due to the efficiency of the keyed message digest routine. due to the efficiency of the keyed message digest routine.
Dynamic key management, which is computationally more demanding, Dynamic key management, which is computationally more demanding,
is more important for scalability. Because RSVP does not specify is more important for scalability. Because RSVP does not specify
a particular key exchange protocol, it is difficult to estimate a particular key exchange protocol, it is difficult to estimate
the effort to create the required security associations. the effort needed to create the required security associations.
Furthermore, the number of key exchanges to be triggered depends Furthermore, the number of key exchanges to be triggered depends
on security policy issues like lifetime of a security on security policy issues like lifetime of a security
association, required security properties of the key exchange association, required security properties of the key exchange
protocol, authentication mode used by the key exchange protocol, protocol, authentication mode used by the key exchange protocol,
etc. In a stationary environment with a single administrative etc. In a stationary environment with a single administrative
domain, manual security association establishment may be domain, manual security association establishment may be
acceptable and may provide the best performance characteristics. acceptable and may provide the best performance characteristics.
In a mobile environment, asymmetric authentication methods are In a mobile environment, asymmetric authentication methods are
likely to be used with a key exchange protocol, and some sort of likely to be used with a key exchange protocol, and some sort of
public key or certificate verification needs to be supported. public key or certificate verification needs to be supported.
4.3 User to PEP/PDP 4.3. User to PEP/PDP
As noted in the previous section, both user-based and host-based As noted in the previous section, RSVP supports both user-based and
authentication are supported by RSVP. Using RSVP, a user may host-based authentication. Using RSVP, a user may authenticate to
authenticate to the first hop router or to the PDP as specified in the first hop router or to the PDP as specified in [1], depending on
[1], depending on the infrastructure provided by the network domain the infrastructure provided by the network domain or the architecture
or the architecture used (e.g., the integration of RSVP and Kerberos used (e.g., the integration of RSVP and Kerberos V5 into the Windows
V5 into the Windows 2000 Operating System [29]. Another architecture 2000 Operating System [25]). Another architecture in which RSVP is
in which RSVP is tightly integrated is the one specified by the tightly integrated is the one specified by the PacketCable
PacketCable organization. The interested reader is referred to [30] organization. The interested reader is referred to [26] for a
for a discussion of their security architecture. discussion of their security architecture.
1. Authentication (1) Authentication
When a user sends a RSVP PATH or RESV message, this message may
When a user sends an RSVP PATH or RESV message, this message may
include some information to authenticate the user. [7] describes include some information to authenticate the user. [7] describes
how user and application information is embedded into the RSVP how user and application information is embedded into the RSVP
message (AUTH_DATA object) and how to protect it. A router message (AUTH_DATA object) and how to protect it. A router
receiving such a message can use this information to authenticate receiving such a message can use this information to authenticate
the client and forward the user or application information to the the client and forward the user or application information to the
policy decision point (PDP). Optionally the PDP itself can policy decision point (PDP). Optionally, the PDP itself can
authenticate the user, which is described in the next section. authenticate the user, which is described in the next section.
To be able to authenticate the user, to verify the integrity, and To be able to authenticate the user, to verify the integrity, and
to check for replays, the entire POLICY_DATA element has to be to check for replays, the entire POLICY_DATA element has to be
forwarded from the router to the PDP, e.g., by including the forwarded from the router to the PDP (e.g., by including the
element into a COPS message. It is assumed, although not clearly element into a COPS message). It is assumed, although not
specified in [7], that the INTEGRITY object within the clearly specified in [7], that the INTEGRITY object within the
POLICY_DATA element is sent to the PDP along with all other POLICY_DATA element is sent to the PDP along with all other
attributes. attributes.
* Certificate Verification * Certificate Verification
Using the policy element as described in [7] it is not possible
to provide a certificate revocation list or other information to Using the policy element as described in [7], it is not
prove the validity of the certificate inside the policy element. possible to provide a certificate revocation list or other
A specific mechanism for certificate verification is not information to prove the validity of the certificate inside
discussed in [7] and hence a number of them can be used for this the policy element. A specific mechanism for certificate
purpose. For certificate verification, the network element (a verification is not discussed in [7] and hence a number of
router or the policy decision point), which has to authenticate them can be used for this purpose. For certificate
the user, could frequently download certificate revocation lists verification, the network element (a router or the policy
or use a protocol like the Online Certificate Status Protocol decision point) that has to authenticate the user could
(OCSP) [31] and the Simple Certificate Validation Protocol (SCVP) frequently download certificate revocation lists or use a
[32] to determine the current status of a digital certificate. 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 * User Authentication to the PDP
This alternative authentication procedure uses the PDP to This alternative authentication procedure uses the PDP to
authenticate the user instead of the first hop router. In 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 Section 4.2.1 of [7], the choice is given for the user to
session ticket either for the next hop router or for the PDP. As obtain a session ticket either for the next hop router or for
noted in the same Section, the identity of the PDP or the next the PDP. As noted in the same section, the identity of the
hop router is statically configured or dynamically retrieved. PDP or the next hop router is statically configured or
Subsequently, user authentication to the PDP is considered. dynamically retrieved. Subsequently, user authentication to
the PDP is considered.
* Kerberos-based Authentication to the PDP * Kerberos-based Authentication to the PDP
If Kerberos is used to authenticate the user, then a session If Kerberos is used to authenticate the user, then a session
ticket for the PDP needs to be requested first. A user who roams ticket for the PDP must be requested first. A user who roams
between different routers in the same administrative domain does between different routers in the same administrative domain
not need to request a new service ticket, because the PDP is does not need to request a new service ticket, because the
likely to be used by most or all first-hop routers within the same PDP is likely to be used by most or all first-hop routers
same administrative domain. This is different from the case in within the same administrative domain. This is different from
which a session ticket for a router has to be obtained and the case in which a session ticket for a router has to be
authentication to a router is required. The router therefore obtained and authentication to a router is required. The
plays a passive role of forwarding the request only to the PDP router therefore plays a passive role of simply forwarding the
and executing the policy decision returned by the PDP. request to the PDP and executing the policy decision returned
Appendix B describes one example of user-to-PDP authentication. by the PDP. Appendix B describes one example of user-to-PDP
User authentication with the policy element only provides authentication.
unilateral authentication whereby the client authenticates to the
router or to the PDP. If a RSVP message is sent to the user's User authentication with the policy element provides only
host and public key based authentication is used, then the unilateral authentication, whereby the client authenticates to
message does not contain a certificate and digital signature. the router or to the PDP. If an RSVP message is sent to the
Hence no mutual authentication can be assumed. In case of user's host and public-key-based authentication is not used,
Kerberos, mutual authentication may be accomplished if the PDP or then the message does not contain a certificate and digital
the router transmits a policy element with an INTEGRITY object signature. Hence, no mutual authentication can be assumed.
computed with the session key retrieved from the Kerberos ticket In case of Kerberos, mutual authentication may be accomplished
or if the Kerberos ticket included in the policy element is also if the PDP or the router transmits a policy element with an
used for the RSVP INTEGRITY object as described in Section 4.2. INTEGRITY object computed with the session key retrieved from
This procedure only works if a previous message was transmitted the Kerberos ticket, or if the Kerberos ticket included in the
from the end host to the network and such key is already policy element is also used for the RSVP INTEGRITY object as
established. [7] does not discuss this issue and therefore there described in Section 4.2. This procedure only works if a
is no particular requirement dealing with transmitting previous message was transmitted from the end host to the
network-specific credentials back to the end-user's host. network and such key is already established. Reference [7]
2. Integrity Protection 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 Integrity protection is applied separately to the RSVP message
and the POLICY_DATA element as shown in Figure 1. In case of a and the POLICY_DATA element, as shown in Figure 1. In case of
policy-ignorant node along the path, the RSVP INTEGRITY object a policy-ignorant node along the path, the RSVP INTEGRITY
and the INTEGRITY object inside the policy element terminate at object and the INTEGRITY object inside the policy element
different nodes. Basically, the same is true for the user terminate at different nodes. Basically, the same is true for
credentials if they are verified at the policy decision point the user credentials if they are verified at the policy
instead of the first hop router. decision point instead of the first hop router.
* Kerberos * Kerberos
If Kerberos is used to authenticate the user to the first hop If Kerberos is used to authenticate the user to the first hop
router, then the session key included in the Kerberos ticket may router, then the session key included in the Kerberos ticket
be used to compute the INTEGRITY object of the policy element. may be used to compute the INTEGRITY object of the policy
It is the keyed message digest that provides the authentication. element. It is the keyed message digest that provides the
The existence of the Kerberos service ticket inside the AUTH_DATA authentication. The existence of the Kerberos service ticket
object does not provide authentication and a guarantee of inside the AUTH_DATA object does not provide authentication or
freshness for the receiving host. Authentication and guarantee a guarantee of freshness for the receiving host.
of freshness are provided by the keyed hash value of the
INTEGRITY object inside the POLICY_DATA element. This shows that Authentication and guarantee of freshness are provided by the
the user actively participated in the Kerberos protocol and was keyed hash value of the INTEGRITY object inside the
able to obtain the session key to compute the keyed message POLICY_DATA element. This shows that the user actively
digest. The Authenticator used in the Kerberos V5 protocol participated in the Kerberos protocol and was able to obtain
provides similar functionality, but replay protection is based on 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 timestamps (or on a sequence number if the optional seq-number
field inside the Authenticator is used for KRB_PRIV/KRB_SAFE field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
messages as described in Section 5.3.2 of [8]). messages as described in Section 5.3.2 of [8]).
* Digital Signature * Digital Signature
If public key based authentication is provided, then user
If public-key-based authentication is provided, then user
authentication is accomplished with a digital signature. As authentication is accomplished with a digital signature. As
explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE
attribute must be the last attribute in the AUTH_DATA object, and attribute must be the last attribute in the AUTH_DATA object,
the digital signature covers the entire AUTH_DATA object. Which and the digital signature covers the entire AUTH_DATA object.
hash algorithm and public key algorithm are used for the digital In the case of PGP, which hash algorithm and public key
signature computation is described in [23] in the case of PGP. algorithm are used for the digital signature computation is
In the case of X.509 credentials the situation is more complex, described in [19]. In the case of X.509 credentials, the
because different mechanisms like CMS [33] or PKCS#7 [34] may be situation is more complex because different mechanisms like
used for digitally signing the message element. X.509 only CMS [29] or PKCS#7 [30] may be used for digitally signing the
provides the standard for the certificate layout, which seems to message element. X.509 only provides the standard for the
provide insufficient information for this purpose. Therefore, certificate layout, which seems to provide insufficient
X.509 certificates are supported for example by CMS and PKCS#7. information for this purpose. Therefore, X.509 certificates
[7], however, does not make any statements about the usage of CMS are supported, for example, by CMS or PKCS#7. [7], however,
and PKCS#7. Currently there is no support for CMS or PKCS#7 does not make any statements about the usage of CMS or PKCS#7.
described in [7], which provides more than just public key based Currently, there is no support for CMS or for PKCS#7 [7],
authentication (e.g., CRL distribution, key transport, key which provides more than just public-key-based authentication
agreement, etc.). Furthermore, the use of PGP in RSVP is vaguely (e.g., CRL distribution, key transport, key agreement, etc.).
defined, because there are different versions of PGP (including Furthermore, the use of PGP in RSVP is vaguely defined,
OpenPGP [23]), and no indication is given as to which should be because there are different versions of PGP (including OpenPGP
used. [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. Additionally, the large Supporting public-key-based mechanisms in RSVP might increase
processing, memory, and bandwidth utilization should be the risks of denial-of-service attacks. The large processing,
considered. Fragmentation might also be an issue here. 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 If the INTEGRITY object is not included in the POLICY_DATA
element or not sent to the PDP, then we have to make the element or not sent to the PDP, then we have to make the
following observations: following observations:
3. For the digital signature case, only the replay protection
provided by the digital signature algorithm can be used. It For the digital signature case, only the replay protection
is not clear, however, whether this usage was anticipated or provided by the digital signature algorithm can be used.
not. Hence, we might assume that replay protection is based It is not clear, however, whether this usage was
on the availability of the RSVP INTEGRITY object used with a anticipated or not. Hence, we might assume that replay
security association that is established by other means. protection is based on the availability of the RSVP
4. Including only the Kerberos session ticket is insufficient, INTEGRITY object used with a security association that is
because freshness is not provided (since the Kerberos 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 Authenticator is missing). Obviously there is no guarantee
that the user actually followed the Kerberos protocol and was that the user actually followed the Kerberos protocol and
able to decrypt the received TGS_REP (or in rare cases the was able to decrypt the received TGS_REP (or, in rare
AS_REP if a session ticket is requested with the initial cases, the AS_REP if a session ticket is requested with the
AS_REQ). initial AS_REQ).
5. Replay Protection
Figure 5 shows the interfaces relevant for replay protection (3) Replay Protection
of signaling messages in a more complicated architecture. In
this case, the client uses the policy data element with PEP2, Figure 5 shows the interfaces relevant for replay protection of
because PEP1 is not policy aware. The interfaces between the signaling messages in a more complicated architecture. In this
client and PEP1 and between PEP1 and PEP2 are protected with case, the client uses the policy data element with PEP2, because
the RSVP INTEGRITY object. The link between the PEP2 and the PEP1 is not policy-aware. The interfaces between the client and
PDP is protected, for example, by using the COPS built-in PEP1 and between PEP1 and PEP2 are protected with the RSVP
INTEGRITY object. The dotted line between the Client and the INTEGRITY object. The link between the PEP2 and the PDP is
PDP indicates the protection provided by the AUTH_DATA protected, for example, by using the COPS built-in INTEGRITY
element, which has no RSVP INTEGRITY object included. 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 +----+ AUTH_DATA +----+
+---------------------------------------------------+PDP +-+ +---------------------------------------------------+PDP +-+
| +----+ | | +----+ |
| | | |
| | | |
| COPS | | COPS |
| INTEGRITY| | INTEGRITY|
| | | |
| | | |
| | | |
+--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ | +--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
|Client+-------------------+PEP1+----------------------+PEP2+-+ |Client+-------------------+PEP1+----------------------+PEP2+-+
+--+---+ +----+ +-+--+ +--+---+ +----+ +-+--+
| | | |
+-----------------------------------------------------+ +-----------------------------------------------------+
POLICY_DATA INTEGRITY POLICY_DATA INTEGRITY
Figure 5: Replay Protection Figure 5: Replay Protection.
Host authentication with the RSVP INTEGRITY object and user Host authentication with the RSVP INTEGRITY object and user
authentication with the INTEGRITY object inside the authentication with the INTEGRITY object inside the POLICY_DATA
POLICY_DATA element both use the same anti-replay mechanism. element both use the same anti-replay mechanism. The length of
The length of the Sequence Number field, sequence number the Sequence Number field, sequence number rollover, and the
rollover, and the Integrity Handshake have already been Integrity Handshake have already been explained in Section 3.1.
explained in Section 3.1.
Section 9 of [7] states: "RSVP INTEGRITY object is used to Section 9 of [7] states: "RSVP INTEGRITY object is used to
protect the policy object containing user identity protect the policy object containing user identity information
information from security (replay) attacks." When using from security (replay) attacks." When using public-key-based
public key based authentication, RSVP based replay protection authentication, RSVP-based replay protection is not supported,
is not supported, because the digital signature does not because the digital signature does not cover the POLICY_DATA
cover the POLICY_DATA INTEGRITY object with its Sequence INTEGRITY object with its Sequence Number field. The digital
Number field. The digital signature covers only the entire signature covers only the entire AUTH_DATA object.
AUTH_DATA object.
The use of public key cryptography within the AUTH_DATA The use of public key cryptography within the AUTH_DATA object
object complicates replay protection. Digital signature complicates replay protection. Digital signature computation
computation with PGP is described in [35] and in [23]. The with PGP is described in [31] and in [19]. The data structure
data structure preceding the signed message digest includes preceding the signed message digest includes information about
information about the message digest algorithm used and a the message digest algorithm used and a 32-bit timestamp of when
32-bit timestamp of when the signature was created the signature was created ("Signature creation time"). The
("Signature creation time"). The timestamp is included in timestamp is included in the computation of the message digest.
the computation of the message digest. The IETF standardized The IETF standardized version of OpenPGP [19] contains more
OpenPGP version [23] contains more information and describes information and describes the different hash algorithms (MD2,
the different hash algorithms (MD2, MD5, SHA-1, RIPEMD-160) MD5, SHA-1, RIPEMD-160) supported. [7] does not make any
supported. [7] does not make any statements as to whether statements as to whether the "Signature creation time" field is
the "Signature creation time" field is used for replay used for replay protection. Using timestamps for replay
protection. Using timestamps for replay protection requires protection requires different synchronization mechanisms in the
different synchronization mechanisms in the case of case of clock-skew. Traditionally, these cases assume "loosely
clock-skew. Traditionally, these cases assume "loosely synchronized" clocks but also require specifying a replay window.
synchronized" clocks but also require specifying a
replay-window.
If the "Signature creation time" is not used for replay If the "Signature creation time" is not used for replay
protection, then a malicious, policy-ignorant node can use protection, then a malicious, policy-ignorant node can use this
this weakness to replace the AUTH_DATA object without weakness to replace the AUTH_DATA object without destroying the
destroying the digital signature. If this was not simply an digital signature. If this was not simply an oversight, it is
oversight, it is therefore assumed that replay protection of therefore assumed that replay protection of the user credentials
the user credentials was not considered an important security was not considered an important security requirement, because the
requirement, because the hop-by-hop processing of the RSVP hop-by-hop processing of the RSVP message protects the message
message protects the message against modification by an against modification by an adversary between two communicating
adversary between two communicating nodes. nodes.
The lifetime of the Kerberos ticket is based on the fields The lifetime of the Kerberos ticket is based on the fields
starttime and endtime of the EncTicketPart structure in the starttime and endtime of the EncTicketPart structure in the
ticket, as described in Section 5.3.1 of [8]. Because the ticket, as described in Section 5.3.1 of [8]. Because the ticket
ticket is created by the KDC located at the network of the is created by the KDC located at the network of the verifying
verifying entity, it is not difficult to have the clocks entity, it is not difficult to have the clocks roughly
roughly synchronized for the purpose of lifetime synchronized for the purpose of lifetime verification.
verification. Additional information about Additional information about clock-synchronization and Kerberos
clock-synchronization and Kerberos can be found in [36]. can be found in [32].
If the lifetime of the Kerberos ticket expires, then a new
ticket must be requested and used. Rekeying is implemented If the lifetime of the Kerberos ticket expires, then a new ticket
with this procedure. must be requested and used. Rekeying is implemented with this
3. (User Identity) Confidentiality procedure.
(4) (User Identity) Confidentiality
This section discusses privacy protection of identity information This section discusses privacy protection of identity information
transmitted inside the policy element. User identity transmitted inside the policy element. User identity
confidentiality is of particular interest because there is no confidentiality is of particular interest because there is no
built-in RSVP mechanism for encrypting the POLICY_DATA object or built-in RSVP mechanism for encrypting the POLICY_DATA object or
the AUTH_DATA elements. Encryption of one of the attributes the AUTH_DATA elements. Encryption of one of the attributes
inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
discussed. discussed.
To protect the user's privacy it is important not to reveal the
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 user's identity to an adversary located between the user's host
and the first-hop router (e.g., on a wireless link). User and the first-hop router (e.g., on a wireless link).
identities should furthermore not be transmitted outside the Furthermore, user identities should not be transmitted outside
domain of the visited network provider, i.e., the user identity the domain of the visited network provider. That is, the user
information inside the policy data element should be removed or identity information inside the policy data element should be
modified by the PDP to prevent revealing its contents to other removed or modified by the PDP to prevent revealing its contents
(non-authorized) entities along the signaling path. It is not to other (unauthorized) entities along the signaling path. It is
possible (with the offered mechanisms) to hide the user's not possible (with the offered mechanisms) to hide the user's
identity in such a way that it is not visible to the first identity in such a way that it is not visible to the first
policy-aware RSVP node (or to the attached network in general). policy-aware RSVP node (or to the attached network in general).
The ASCII or Unicode distinguished name of user or application
inside the POLICY_LOCATOR attribute of the AUTH_DATA element may The ASCII or Unicode distinguished name of the user or
be encrypted as specified in Section 3.3.1 of [7]. The user (or application inside the POLICY_LOCATOR attribute of the AUTH_DATA
application) identity is then encrypted with either the Kerberos element may be encrypted as specified in Section 3.3.1 of [7].
session key or with the private key in case of public key based The user (or application) identity is then encrypted with either
authentication. When the private key is used, we usually speak the Kerberos session key or with the private key in case of
of a digital signature that can be verified by everyone public-key-based authentication. When the private key is used,
possessing the public key. Because the certificate with the we usually speak of a digital signature that can be verified by
public key is included in the message itself, decryption is no everyone possessing the public key. Because the certificate with
obstacle. Furthermore, the included certificate together 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 the additional (unencrypted) information in the RSVP message
provides enough identity information for an eavesdropper. Hence, provides enough identity information for an eavesdropper. Hence,
the possibility of encrypting the policy locator in case of the possibility of encrypting the policy locator in case of
public key based authentication is problematic. To encrypt the public-key-based authentication is problematic. To encrypt the
identities using asymmetric cryptography, the user's host must be identities using asymmetric cryptography, the user's host must be
able somehow to retrieve the public key of the entity verifying able somehow to retrieve the public key of the entity verifying
the policy element (i.e., the first policy aware router or the the policy element (i.e., the first policy-aware router or the
PDP). Then, this public key could be used to encrypt a symmetric PDP). Then, this public key could be used to encrypt a symmetric
key, which in turn encrypts the user's identity and certificate, key, which in turn encrypts the user's identity and certificate,
as is done, e.g., by PGP. Currently no such mechanism is defined as is done, e.g., by PGP. Currently, no such mechanism is
in [7]. defined in [7].
The algorithm used to encrypt the POLICY_LOCATOR with the The algorithm used to encrypt the POLICY_LOCATOR with the
Kerberos session key is assumed to be the same as the one used Kerberos session key is assumed to be the same as the one used
for encrypting the service ticket. The information about the for encrypting the service ticket. The information about the
algorithm used is available in the etype field of the algorithm used is available in the etype field of the
EncryptedData ASN.1 encoded message part. Section 6.3 of [8] EncryptedData ASN.1 encoded message part. Section 6.3 of [8]
lists the supported algorithms. [12] defines new encryption lists the supported algorithms. [33] defines newer encryption
algorithms (Rijndael, Serpent, and Twofish). algorithms (Rijndael, Serpent, and Twofish).
Evaluating user identity confidentiality requires also looking at
Evaluating user identity confidentiality also requires looking at
protocols executed outside of RSVP (for example, the Kerberos protocols executed outside of RSVP (for example, the Kerberos
protocol). The ticket included in the CREDENTIAL attribute may protocol). The ticket included in the CREDENTIAL attribute may
provide user identity protection by not including the optional provide user identity protection by not including the optional
cname attribute inside the unencrypted part of the Ticket. cname attribute inside the unencrypted part of the Ticket.
Because the Authenticator is not transmitted with the RSVP Because the Authenticator is not transmitted with the RSVP
message, the cname and the crealm of the unencrypted part of the message, the cname and the crealm of the unencrypted part of the
Authenticator are not revealed. In order for the user to request Authenticator are not revealed. In order for the user to request
the Kerberos session ticket for inclusion in the CREDENTIAL the Kerberos session ticket for inclusion in the CREDENTIAL
attribute, the Kerberos protocol exchange must be executed. Then attribute, the Kerberos protocol exchange must be executed. Then
the Authenticator sent with the TGS_REQ reveals the identity of the Authenticator sent with the TGS_REQ reveals the identity of
the user. The AS_REQ must also include the user's identity to the user. The AS_REQ must also include the user's identity to
allow the Kerberos Authentication Server to respond with an allow the Kerberos Authentication Server to respond with an
AS_REP message that is encrypted with the user's secret key. AS_REP message that is encrypted with the user's secret key.
Using Kerberos, it is therefore only possible to hide the content Using Kerberos, it is therefore only possible to hide the content
of the encrypted policy locator, which is only useful if this of the encrypted policy locator, which is only useful if this
value differs from the Kerberos principal name. Hence using value differs from the Kerberos principal name. Hence, using
Kerberos it is not "entirely" possible to provide user identity Kerberos it is not "entirely" possible to provide user identity
confidentiality. confidentiality.
It is important to note that information stored in the policy It is important to note that information stored in the policy
element may be changed by a policy-aware router or by the policy element may be changed by a policy-aware router or by the policy
decision point. Which parts are changed depends upon whether decision point. Which parts are changed depends upon whether
multicast or unicast is used, how the policy server reacts, where multicast or unicast is used, how the policy server reacts, where
the user is authenticated, whether the user needs to be the user is authenticated, whether the user needs to be re-
re-authenticated in other network nodes, etc. Hence, user and authenticated in other network nodes, etc. Hence, user-specific
application specific information can leak after the messages and application-specific information can leak after the messages
leave the first hop within the network where the user's host is leave the first hop within the network where the user's host is
attached. As mentioned at the beginning of this section, this attached. As mentioned at the beginning of this section, this
information leakage is assumed to be intentional. information leakage is assumed to be intentional.
4. Authorization
(5) Authorization
In addition to the description of the authorization steps of the In addition to the description of the authorization steps of the
Host-to-Router interface, user-based authorization is performed Host-to-Router interface, user-based authorization is performed
with the policy element providing user credentials. The with the policy element providing user credentials. The
inclusion of user and application specific information enables inclusion of user and application specific information enables
policy-based admission control with special user policies that policy-based admission control with special user policies that
are likely to be stored at a dedicated server. Hence a Policy are likely to be stored at a dedicated server. Hence, a Policy
Decision Point can query, for example, a LDAP server for a Decision Point can query, for example, an LDAP server for a
service level agreement stating the amount of resources a certain service level agreement that states the amount of resources a
user is allowed to request. In addition to the user identity certain user is allowed to request. In addition to the user
information, group membership and other non-security-related identity information, group membership and other non-security-
information may contribute to the evaluation of the final policy related information may contribute to the evaluation of the final
decision . If the user is not registered to the currently policy decision. If the user is not registered to the currently
attached domain, then there is the question of how much attached domain, then there is the question of how much
information the home domain of the user is willing to exchange. information the home domain of the user is willing to exchange.
This also impacts the user's privacy policy. In general, the This also impacts the user's privacy policy.
user may not want to distribute much of this policy information.
Furthermore, the lack of a standardized authorization data format In general, the user may not want to distribute much of this
may create interoperability problems when exchanging policy policy information. Furthermore, the lack of a standardized
information. Hence, we can assume that the policy decision point authorization data format may create interoperability problems
may use information from an initial authentication and key when exchanging policy information. Hence, we can assume that
agreement protocol, which may have already required cross-realm the policy decision point may use information from an initial
communication with the user's home domain if only to assume that authentication and key agreement protocol (which may have already
the home domain knows the user and that the user is entitled to required cross-realm communication with the user's home domain,
roam and to be able to forward accounting messages to this 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 domain. This represents the traditional subscriber-based
accounting scenario. Non-traditional or alternative means of accounting scenario. Non-traditional or alternative means of
access might be deployed in the near future that do not require access might be deployed in the near future that do not require
any type of inter-domain communication. any type of inter-domain communication.
Additional discussions are required to determine the expected Additional discussions are required to determine the expected
authorization procedures. [37] and [38] discuss authorization authorization procedures. [34] and [35] discuss authorization
issues for QoS signaling protocols. Furthermore, a number of issues for QoS signaling protocols. Furthermore, a number of
mobililty implications for policy handling in RSVP are described mobility implications for policy handling in RSVP are described
in [39] in [36].
5. Performance
(6) Performance
If Kerberos is used for user authentication, then a Kerberos If Kerberos is used for user authentication, then a Kerberos
ticket must be included in the CREDENTIAL Section of the ticket must be included in the CREDENTIAL Section of the
AUTH_DATA element. The Kerberos ticket has a size larger than AUTH_DATA element. The Kerberos ticket has a size larger than
500 bytes but only needs to be sent once, because a performance 500 bytes, but it only needs to be sent once because a
optimization allows the session key to be cached as noted in performance optimization allows the session key to be cached as
Section 7.1 of [1]. It is assumed that subsequent RSVP messages noted in Section 7.1 of [1]. It is assumed that subsequent RSVP
only include the POLICY_DATA INTEGRITY object with a keyed messages only include the POLICY_DATA INTEGRITY object with a
message digest that uses the Kerberos session key. This, keyed message digest that uses the Kerberos session key.
however, assumes that the security association required for the However, this assumes that the security association required for
POLICY_DATA INTEGRITY object is created (or modified) to allow the POLICY_DATA INTEGRITY object is created (or modified) to
the selection of the correct key. Otherwise, it difficult to say allow the selection of the correct key. Otherwise, it difficult
which identifier is used to index the security association. to say which identifier is used to index the security
When Kerberos is used as an authentication system then, from a association.
If Kerberos is used as an authentication system then, from a
performance perspective, the message exchange to obtain the performance perspective, the message exchange to obtain the
session key needs to be considered, although the exchange only session key needs to be considered, although the exchange only
needs to be done once in the lifetime of the session ticket. needs to be done once in the lifetime of the session ticket.
This is particularly true in a mobile environment with a fast This is particularly true in a mobile environment with a fast
roaming user's host. roaming user's host.
Public key based authentication usually provides the best
Public-key-based authentication usually provides the best
scalability characteristics for key distribution, but the scalability characteristics for key distribution, but the
protocols are performance demanding. A major disadvantage of the protocols are performance demanding. A major disadvantage of the
public key based user authentication in RSVP is the lack of a public-key-based user authentication in RSVP is the lack of a
method to derive a session key. Hence every RSVP PATH or RESV method to derive a session key. Hence, every RSVP PATH or RESV
message includes the certificate and a digital signature, which message includes the certificate and a digital signature, which
is a huge performance and bandwidth penalty. For a mobile is a huge performance and bandwidth penalty. For a mobile
environment with low power devices, high latency, channel noise, environment with low power devices, high latency, channel noise,
and low bandwidth links, this seems to be less encouraging. Note and low-bandwidth links, this seems to be less encouraging. Note
that a public key infrastructure is required to allow the PDP (or that a public key infrastructure is required to allow the PDP (or
the first-hop router) to verify the digital signature and the the first-hop router) to verify the digital signature and the
certificate. To check for revoked certificates, certificate certificate. To check for revoked certificates, certificate
revocation lists or protocols like the Online Certificate Status revocation lists or protocols like the Online Certificate Status
Protocol [31] and the Simple Certificate Validation Protocol [32] Protocol [27] and the Simple Certificate Validation Protocol [28]
are needed. Then the integrity of the AUTH_DATA object via the are needed. Then the integrity of the AUTH_DATA object can be
digital signature can be verified. verified via the digital signature.
4.4 Communication between RSVP-Aware Routers 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.
1. Authentication
RSVP signaling messages are data origin authenticated and
protected against modification and replay using the RSVP
INTEGRITY object. The RSVP message flow between routers is
protected based on the chain of trust and hence each router only
needs to have 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 where 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 Independent of the key distribution mechanism, host
authentication with RSVP built-in mechanisms is accomplished with authentication with built-in RSVP mechanisms is accomplished
the keyed message digest in the RSVP INTEGRITY object computed using the keyed message digest in the RSVP INTEGRITY object,
using the previously exchanged symmetric key. computed using the previously exchanged symmetric key.
2. Integrity Protection
(2) Integrity Protection
Integrity protection is accomplished with the RSVP INTEGRITY Integrity protection is accomplished with the RSVP INTEGRITY
object with the variable length Keyed Message Digest field. object with the variable length Keyed Message Digest field.
3. Replay Protection
(3) Replay Protection
Replay protection with the RSVP INTEGRITY object is extensively Replay protection with the RSVP INTEGRITY object is extensively
described in previous sections. To enable crashed hosts to learn described in previous sections. To enable crashed hosts to learn
the latest sequence number used, the Integrity Handshake the latest sequence number used, the Integrity Handshake
mechanism is provided in RSVP. mechanism is provided in RSVP.
4. Confidentiality
(4) Confidentiality
Confidentiality is not provided by RSVP. Confidentiality is not provided by RSVP.
5. Authorization
(5) Authorization
Depending on the RSVP network, QoS resource authorization at Depending on the RSVP network, QoS resource authorization at
different routers may need to contact the PDP again. Because the different routers may need to contact the PDP again. Because the
PDP is allowed to modify the policy element, a token may be added PDP is allowed to modify the policy element, a token may be added
to the policy element to increase the efficiency of the to the policy element to increase the efficiency of the re-
re-authorization procedure. This token is used to refer to an authorization procedure. This token is used to refer to an
already computed policy decision. The communications interface already computed policy decision. The communications interface
from the PEP to the PDP must be properly secured. from the PEP to the PDP must be properly secured.
6. Performance
(6) Performance
The performance characteristics for the protection of the RSVP The performance characteristics for the protection of the RSVP
signaling messages is largely determined by the key exchange signaling messages is largely determined by the key exchange
protocol, because the RSVP INTEGRITY object is only used to protocol, because the RSVP INTEGRITY object is only used to
compute a keyed message digest of the transmitted signaling compute a keyed message digest of the transmitted signaling
messages. messages.
The security associations within the core network, i.e., 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 The security associations within the core network, that is,
problematic. 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 5. Miscellaneous Issues
This section describes a number of issues that illustrate some of the This section describes a number of issues that illustrate some of the
shortcomings of RSVP with respect to security. shortcomings of RSVP with respect to security.
5.1 First Hop Issue 5.1. First-Hop Issue
In case of end-to-end signaling, an end host starts signaling to its In case of end-to-end signaling, an end host starts signaling to its
attached network. The first-hop communication is often more attached network. The first-hop communication is often more
difficult to secure because of the different requirements and a difficult to secure because of the different requirements and a
missing trust relationship. An end host must therefore obtain some missing trust relationship. An end host must therefore obtain some
information to start RSVP signaling: information to start RSVP signaling:
o Does this network support RSVP signaling? o Does this network support RSVP signaling?
o Which node supports RSVP signaling? o Which node supports RSVP signaling?
o To which node is authentication required? o To which node is authentication required?
o Which security mechanisms are used for authentication? o Which security mechanisms are used for authentication?
o Which algorithms have to be used?
o Where should the keys and security association come from? o Which algorithms are required?
o Where should the keys and security associations come from?
o Should a security association be established? o Should a security association be established?
RSVP, as specified today, is used as a building block. Hence, these RSVP, as specified today, is used as a building block. Hence, these
questions have to be answered as part of overall architectural questions have to be answered as part of overall architectural
considerations. Without giving an answer to this question, ad hoc considerations. Without answers to these questions, ad hoc RSVP
RSVP communication by an end host roaming to an unknown network is communication by an end host roaming to an unknown network is not
not possible. A negotiation of security mechanisms and algorithms is possible. A negotiation of security mechanisms and algorithms is not
not supported for RSVP. supported for RSVP.
5.2 Next-Hop Problem 5.2. Next-Hop Problem
Throughout the document it was assumed that the next RSVP node along Throughout the document it was assumed that the next RSVP node along
the path is always known. Knowing your next hop is important to be the path is always known. Knowing the next hop is important to be
able to select the correct key for the RSVP Integrity object and to able to select the correct key for the RSVP Integrity object and to
apply the proper protection. In case in which an RSVP node assumes apply the proper protection. In the case in which an RSVP node
it knows which node is the next hop the following protocol exchange assumes it knows which node is the next hop, the following protocol
can occur: exchange can occur:
Integrity Integrity
(A<->C) +------+ (A<->C) +------+
(3) | RSVP | (3) | RSVP |
+------------->+ Node | +------------->+ Node |
| | B | | | B |
Integrity | +--+---+ Integrity | +--+---+
(A<->C) | | (A<->C) | |
+------+ (2) +--+----+ | +------+ (2) +--+----+ |
(1) | RSVP +----------->+Router | | Error (1) | RSVP +----------->+Router | | Error
----->| Node | | or +<-----------+ (I am B) ----->| Node | | or +<-----------+ (I am B)
| A +<-----------+Network| (4) | A +<-----------+Network| (4)
+------+ (5) +--+----+ +------+ (5) +--+----+
Error . Error .
(I am B) . +------+ (I am B) . +------+
. | RSVP | . | RSVP |
...............+ Node | ...............+ Node |
| C | | C |
+------+ +------+
Figure 6: Next-Hop Issue Figure 6: Next-Hop Issue.
When RSVP node A in Figure 6 receives an incoming RSVP Path message, When RSVP node A in Figure 6 receives an incoming RSVP Path message,
standard RSVP message processing takes place. Node A then has to standard RSVP message processing takes place. Node A then has to
decide which key to select to protect the signaling message. We decide which key to select to protect the signaling message. We
assume that some unspecified mechanism is used to make this decision. assume that some unspecified mechanism is used to make this decision.
In this example node A assumes that the message will travel to RSVP In this example, node A assumes that the message will travel to RSVP
node C. However, because of some reasons (e.g. a route change, node C. However, for some reasons (e.g., a route change, inability
inability to learn the next RSVP hop along the path, etc.) the to learn the next RSVP hop along the path, etc.) the message travels
message travels to node B via a non-RSVP supporting router that to node B via a non-RSVP supporting router that cannot verify the
cannot verify the integrity of the message (or cannot decrypt the integrity of the message (or cannot decrypt the Kerberos service
Kerberos service ticket). The processing failure causes a PathErr ticket). The processing failure causes a PathErr message to be
message to be returned to the originating sender of the Path message. returned to the originating sender of the Path message. This error
This error message also contains information about the node message also contains information about the node that recognized the
recognizing the error. In many cases a security association might error. In many cases, a security association might not be available.
not be available. Node A receiving the PathErr message might use the Node A receiving the PathErr message might use the information
information returned with the PathErr message to select a different returned with the PathErr message to select a different security
security association (or to establish one). association (or to establish one).
Figure 6 describes a behavior that might help node A learn that an Figure 6 describes a behavior that might help node A learn that an
error occurred. However, the description of Section 4.2 of [1] error occurred. However, the description in Section 4.2 of [1]
describes in step (5) that a signaling message is silently discarded states in step (5) that a signaling message is silently discarded if
if the receiving host cannot properly verify the message: "If the the receiving host cannot properly verify the message: "If the
calculated digest does not match the received digest, the message is calculated digest does not match the received digest, the message is
discarded without further processing." For RSVP Path and similar discarded without further processing." For RSVP Path and similar
messages this functionality is not really helpful. messages, this functionality is not really helpful.
The RSVP Path message therefore provides a number of functions: path The RSVP Path message therefore provides a number of functions: path
discovery, detecting route changes, learning of QoS capabilities discovery, detecting route changes, discovery of QoS capabilities
along the path using the Adspec object, (with some interpretation) along the path using the Adspec object (with some interpretation),
next-hop discovery, and possibly security association establishment next-hop discovery, and possibly security association establishment
(for example, in the case of Kerberos). (for example, in the case of Kerberos).
From a security point of view there is a conflict between From a security point of view, there are conflicts between:
o Idempotent message delivery and efficiency o Idempotent message delivery and efficiency
The RSVP Path message especially performs a number of functions. The RSVP Path message especially performs a number of functions.
Supporting idempotent message delivery somehow contradicts with Supporting idempotent message delivery somehow contradicts with
security association establishment, efficient message delivery, security association establishment, efficient message delivery,
and message size. For example, a "real" idempotent signaling and message size. For example, a "real" idempotent signaling
message would contain enough information to perform security message would contain enough information to perform security
processing without depending on a previously executed message processing without depending on a previously executed message
exchange. Adding a Kerberos ticket with every signaling message exchange. Adding a Kerberos ticket with every signaling message
is, however, inefficient. Using public key based mechanisms is is, however, inefficient. Using public-key-based mechanisms is
even more inefficient when included in every signaling message. even more inefficient when included in every signaling message.
With public key based protection for idempotent messages, there is With public-key-based protection for idempotent messages, there is
additionally a risk of introducing denial of service attacks. the additional risk of introducing denial-of-service attacks.
o RSVP Path message functionality and next-hop discovery o RSVP Path message functionality and next-hop discovery
To protect an RSVP signaling message (and a RSVP Path message in To protect an RSVP signaling message (and an RSVP Path message in
particular) it is necessary to know the identity of the next particular) it is necessary to know the identity of the next
RSVP-aware node (and some other parameters). Without a mechanism RSVP-aware node (and some other parameters). Without a mechanism
for next-hop discovery, an RSVP Path message is also responsible for next-hop discovery, an RSVP Path message is also responsible
for this task. Without knowing the identity of the next hop, the for this task. Without knowing the identity of the next hop, the
Kerberos principal name is also unknown. The so-called Kerberos Kerberos principal name is also unknown. The so-called Kerberos
user-to-user authentication mechanism, which would allow the user-to-user authentication mechanism, which would allow the
receiver to trigger the process of establishing Kerberos receiver to trigger the process of establishing Kerberos
authentication, is not supported. This issue will again be authentication, is not supported. This issue will again be
discussed in relationship with the last-hop problem. discussed in relationship with the last-hop problem.
It is fair to assume that a RSVP-supporting node might not have It is fair to assume that an RSVP-supporting node might not have
security associations with all immediately neighboring RSVP nodes. security associations with all immediately neighboring RSVP nodes.
Especially for inter-domain signaling, IntServ over DiffServ, or Especially for inter-domain signaling, IntServ over DiffServ, or
some new applications such as firewall signaling, the next some new applications such as firewall signaling, the next RSVP-
RSVP-aware node might not be known in advance. The number of next aware node might not be known in advance. The number of next RSVP
RSVP nodes might be considerably large if they are separated by a nodes might be considerably large if they are separated by a large
large number of non-RSVP aware nodes. Hence, a node transmitting number of non-RSVP aware nodes. Hence, a node transmitting an
a RSVP Path message might experience difficulties in properly RSVP Path message might experience difficulties in properly
protecting the message if it serves as a mechanism to detect both protecting the message if it serves as a mechanism to detect both
the next RSVP node (i.e., Router Alert Option added to the the next RSVP node (i.e., Router Alert Option added to the
signaling message and addressed to the destination address) and to signaling message and addressed to the destination address) and to
detect route changes. It is fair to note that in an intra-domain detect route changes. It is fair to note that, in the intra-
case with a dense distribution of RSVP nodes this might be domain case with a dense distribution of RSVP nodes, protection
possible with manual configuration. might be possible with manual configuration.
Nothing prevents an adversary from continuously flooding an RSVP Nothing prevents an adversary from continuously flooding an RSVP
node with bogus PathErr messages, although it might be possible to node with bogus PathErr messages, although it might be possible to
protect the PathErr message with an existing, available security protect the PathErr message with an existing, available security
association. A legitimate RSVP node would believe that a change association. A legitimate RSVP node would believe that a change
in the path took place. Hence, this node might try to select a in the path took place. Hence, this node might try to select a
different security association or try to create one with the different security association or try to create one with the
indicated node. If an adversary is located somewhere along the indicated node. If an adversary is located somewhere along the
path and either authentication or authorization is not performed path, and either authentication or authorization is not performed
with the necessary strength and accuracy, then it might also be with the necessary strength and accuracy, then it might also be
possible to act as a man-in-the-middle. One method of reducing possible to act as a man-in-the-middle. One method of reducing
susceptibility to this attack is as follows: when a PathErr susceptibility to this attack is as follows: when a PathErr
message is received from a node with which no security association message is received from a node with which no security association
exists, attempt to establish a security association and then exists, attempt to establish a security association and then
repeat the action that led to the PathErr message. repeat the action that led to the PathErr message.
5.3 Last-Hop Issue 5.3. Last-Hop Issue
This section tries to address practical difficulties when This section tries to address practical difficulties when
authentication and key establishment are accomplished with a authentication and key establishment are accomplished with a two-
two-party protocol that shows some asymmetry in message processing. party protocol that shows some asymmetry in message processing.
Kerberos is such a protocol and also the only supported protocol that Kerberos is such a protocol and also the only supported protocol that
provides dynamic session key establishment for RSVP. For first-hop provides dynamic session key establishment for RSVP. For first-hop
communication, authentication is typically done between a user and communication, authentication is typically done between a user and
some router (for example the access router). Especially in a mobile some router (for example the access router). Especially in a mobile
environment, it is not feasible to authenticate end hosts based on environment, it is not feasible to authenticate end hosts based on
their IP or MAC address. To illustrate this problem, the typical their IP or MAC address. To illustrate this problem, the typical
processing steps for Kerberos are shown for first-hop communication: processing steps for Kerberos are shown for first-hop communication:
1. The end host A learns the identity (i.e., Kerberos principal (1) The end host A learns the identity (i.e., Kerberos principal
name) of some entity B. This entity B is either the next RSVP name) of some entity B. This entity B is either the next RSVP
node, a PDP, or the next policy-aware RSVP node. node, a PDP, or the next policy-aware RSVP node.
2. Entity A then requests a ticket granting ticket for the network
(2) Entity A then requests a ticket granting ticket for the network
domain. This assumes that the identity of the network domain is domain. This assumes that the identity of the network domain is
known. known.
3. Entity A then requests a service ticket for entity B, whose name
was learned in step (a). (3) Entity A then requests a service ticket for entity B, whose name
4. Entity A includes the service ticket with the RSVP signaling was learned in step (1).
(4) Entity A includes the service ticket with the RSVP signaling
message (inside the policy object). The Kerberos session key is message (inside the policy object). The Kerberos session key is
used to protect the integrity of the entire RSVP signaling used to protect the integrity of the entire RSVP signaling
message. message.
For last-hop communication this processing step theoretically has to For last-hop communication, this processing theoretically has to be
be reversed; entity A is then a node in the network (for example the reversed: entity A is then a node in the network (for example, the
access router) and entity B is the other end host (under the access router) and entity B is the other end host (under the
assumption that RSVP signaling is accomplished between two end hosts assumption that RSVP signaling is accomplished between two end hosts
and not between an end host and a application server). The access and not between an end host and an application server). However, the
router might, however, in step (a) not be able to learn the user's access router in step (1) might not be able to learn the user's
principal name, because this information might not be available. principal name because this information might not be available.
Entity A could reverse the process by triggering an IAKERB exchange. Entity A could reverse the process by triggering an IAKERB exchange.
This would cause entity B to request a service ticket for A as This would cause entity B to request a service ticket for A as
described above. IAKERB is however not supported in RSVP. described above. However, IAKERB is not supported in RSVP.
5.4 RSVP and IPsec protected data traffic 5.4. RSVP- and IPsec-Protected Data Traffic
QoS signaling requires flow information to be established at routers QoS signaling requires flow information to be established at routers
along a path. This flow identifier installed at each device tells along a path. This flow identifier installed at each device tells
the router which data packets should receive QoS treatment. RSVP the router which data packets should receive QoS treatment. RSVP
typically establishes a flow identifier based on the 5-tuple (source typically establishes a flow identifier based on the 5-tuple (source
IP address, destination IP address, transport protocol type, source IP address, destination IP address, transport protocol type, source
port, and destination port). If this 5-tuple information is not port, and destination port). If this 5-tuple information is not
available, then other identifiers have to be used. IPsec-protected available, then other identifiers have to be used. ESP-encrypted
data traffic is such an example where the transport protocol and the data traffic is such an example where the transport protocol and the
port numbers are not accessible. Hence the IPsec SPI is used as a port numbers are not accessible. Hence, the IPsec SPI is used as a
substitute for them. [13] considers these IPsec implications for substitute for them. [12] considers these IPsec implications for RSVP
RSVP and is based on three assumptions: and is based on three assumptions:
1. An end host, which initiates the RSVP signaling message exchange, (1) An end host that initiates the RSVP signaling message exchange
has to be able to retrieve the SPI for given flow. This requires has to be able to retrieve the SPI for a given flow. This
some interaction with the IPsec security association database requires some interaction with the IPsec security association
(SAD) and security policy database (SPD) [3]. An application database (SAD) and security policy database (SPD) [3]. An
usually does not know the SPI of the protected flow and cannot application usually does not know the SPI of the protected flow
provide the desired values. It can provide the signaling and cannot provide the desired values. It can provide the
protocol daemon with flow identifiers. The signaling daemon signaling protocol daemon with flow identifiers. The signaling
would then need to query the SAD by providing the flow daemon would then need to query the SAD by providing the flow
identifiers as input parameters and the SPI as an output identifiers as input parameters and receiving the SPI as an
parameter. output parameter.
2. [13] assumes end-to-end IPsec protection of the data traffic. If
(2) [12] assumes end-to-end IPsec protection of the data traffic. If
IPsec is applied in a nested fashion, then parts of the path do IPsec is applied in a nested fashion, then parts of the path do
not experience QoS treatment. This can be treated as a tunneling not experience QoS treatment. This can be treated as a problem
problem, but it is initiated by the end host. A figure better of tunneling that is initiated by the end host. The following
illustrates the problem in the case of enforcing secure network figure better illustrates the problem in the case of enforcing
access: secure network access:
+------+ +---------------+ +--------+ +-----+ +------+ +---------------+ +--------+ +-----+
| Host | | Security | | Router | | Host| | Host | | Security | | Router | | Host|
| A | | Gateway (SGW) | | Rx | | B | | A | | Gateway (SGW) | | Rx | | B |
+--+---+ +-------+-------+ +----+---+ +--+--+ +--+---+ +-------+-------+ +----+---+ +--+--+
| | | | | | | |
|IPsec-Data( | | | |IPsec-Data( | | |
| OuterSrc=A, | | | | OuterSrc=A, | | |
| OuterDst=SGW, | | | | OuterDst=SGW, | | |
| SPI=SPI1, | | | | SPI=SPI1, | | |
| InnerSrc=A, | | | | InnerSrc=A, | | |
| OuterDst=B, | | | | InnerDst=B, | | |
| Protocol=X, |IPsec-Data( | | | Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | | | SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | | | DstPort=Z) | DstIP=B, | |
|=====================>| Protocol=X, |IPsec-Data( | |=====================>| Protocol=X, |IPsec-Data( |
| | SrcPort=Y, | SrcIP=A, | | | SrcPort=Y, | SrcIP=A, |
| --IPsec protected-> | DstPort=Z) | DstIP=B, | | --IPsec protected-> | DstPort=Z) | DstIP=B, |
| data traffic |------------------>| Protocol=X, | | data traffic |------------------>| Protocol=X, |
| | | SrcPort=Y, | | | | SrcPort=Y, |
| | | DstPort=Z) | | | | DstPort=Z) |
| | |---------------->| | | |---------------->|
| | | | | | | |
| | --Unprotected data traffic-> | | | --Unprotected data traffic---> |
| | | | | | | |
Figure 7: RSVP and IPsec protected data traffic Figure 7: RSVP and IPsec protected data traffic.
Host A, transmitting data traffic, would either indicate a 3-
tuple <A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. In any case,
it is not possible to make a QoS reservation for the entire path.
Two similar examples are remote access using a VPN and protection
of data traffic between a home agent (or a security gateway in
the home network) and a mobile node. The same problem occurs
with a nested application of IPsec (for example, IPsec between A
and SGW and between A and B).
Host A transmitting data traffic would either indicate a 3-tuple
<A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. In any case it is
not possible to make a QoS reservation for the entire path. Two
similar examples are remote access using a VPN and protection of
data traffic between a home agent (or a security gateway in the
home network) and a mobile node. With a nested application of
IPsec (for example, IPsec between A and SGW and between A and B)
the same problem occurs.
One possible solution to this problem is to change the flow One possible solution to this problem is to change the flow
identifier along the path to capture the new flow identifier identifier along the path to capture the new flow identifier
after an IPsec endpoint. after an IPsec endpoint.
IPsec tunnels that neither start nor terminate at one of the IPsec tunnels that neither start nor terminate at one of the
signaling end points (for example between two networks) should be signaling end points (for example between two networks) should be
addressed differently by recursively applying an RSVP signaling addressed differently by recursively applying an RSVP signaling
exchange for the IPsec tunnel. RSVP signaling within tunnels is exchange for the IPsec tunnel. RSVP signaling within tunnels is
addressed in [14]. addressed in [13].
3. It is assumed that SPIs do not change during the lifetime of the
(3) It is assumed that SPIs do not change during the lifetime of the
established QoS reservation. If a new IPsec SA is created, then established QoS reservation. If a new IPsec SA is created, then
a new SPI is allocated for the security association. To reflect a new SPI is allocated for the security association. To reflect
this change, either a new reservation has to be established or this change, either a new reservation has to be established or
the flow identifier of the existing reservation has to be the flow identifier of the existing reservation has to be
updated. Because IPsec SAs usually have a longer lifetime, this updated. Because IPsec SAs usually have a longer lifetime, this
does not seem to be a major issue. IPsec protection of SCTP data does not seem to be a major issue. IPsec protection of SCTP data
traffic might more often require an IPsec SA (and an SPI) change traffic might more often require an IPsec SA (and SPI) change to
to reflect added and removed IP addresses from an SCTP reflect added and removed IP addresses from an SCTP association.
association.
5.5 End-to-End Security Issues and RSVP 5.5. End-to-End Security Issues and RSVP
End-to-end security for RSVP has not been discussed throughout the End-to-end security for RSVP has not been discussed throughout the
document. In this context end-to-end security refers to credentials document. In this context, end-to-end security refers to credentials
transmitted between the two end hosts using RSVP. It is obvious that transmitted between the two end hosts using RSVP. It is obvious that
care must be taken to ensure that routers along the path are able to care must be taken to ensure that routers along the path are able to
process and modify the signaling messages according to prescribed process and modify the signaling messages according to prescribed
processing procedures. Some objects or mechanisms, however, could be processing procedures. However, some objects or mechanisms could be
used for end-to-end protection. The main question however is what used for end-to-end protection. The main question, however, is the
the benefit of such an end-to-end security is. First, there is the benefit of such end-to-end security. First, there is the question of
question of how to establish the required security association. how to establish the required security association. Between two
Between two arbitrary hosts on the Internet this might turn out to be arbitrary hosts on the Internet, this might turn out to be quite
quite difficult. Furthermore, te usefulness of end-to-end security difficult. Second, the usefulness of end-to-end security depends on
depends on the architecture in which RSVP is deployed. If RSVP is the architecture in which RSVP is deployed. If RSVP is used only to
only used to signal QoS information into the network, and other signal QoS information into the network, and other protocols have to
protocols have to be executed beforehand to negotiate the parameters be executed beforehand to negotiate the parameters and to decide
and to decide which entity is charged for the QoS reservation, then which entity is charged for the QoS reservation, then no end-to-end
no end-to-end security is likely to be required. Introducing security is likely to be required. Introducing end-to-end security
end-to-end security to RSVP would then cause problems with extensions to RSVP would then cause problems with extensions like RSVP proxy
like RSVP proxy [40], Localized RSVP [41], and others that terminate [37], Localized RSVP [38], and others that terminate RSVP signaling
RSVP signaling somewhere along the path without reaching the somewhere along the path without reaching the destination end host.
destination end host. Such a behavior could then be interpreted as a Such a behavior could then be interpreted as a man-in-the-middle
man-in-the-middle attack. attack.
5.6 IPsec protection of RSVP signaling messages 5.6. IPsec Protection of RSVP Signaling Messages
It is assumed throughout that RSVP signaling messages can also be It is assumed throughout that RSVP signaling messages can also be
protected by IPsec [3] in a hop-by-hop fashion between two adjacent protected by IPsec [3] in a hop-by-hop fashion between two adjacent
RSVP nodes. RSVP, however, uses special processing of signaling RSVP nodes. RSVP, however, uses special processing of signaling
messages, which complicates IPsec protection. As explained in this messages, which complicates IPsec protection. As explained in this
section, IPsec should only be used for protection of RSVP signaling section, IPsec should only be used for protection of RSVP signaling
messages in a point-to-point communication environment (i.e., a RSVP messages in a point-to-point communication environment (i.e., an RSVP
message can only reach one RSVP router and not possibly more than message can only reach one RSVP router and not possibly more than
one). This restriction is caused by the combination of signaling one). This restriction is caused by the combination of signaling
message delivery and discovery into a single message. Furthermore, message delivery and discovery into a single message. Furthermore,
end-to-end addressing complicates IPsec handling considerably. This end-to-end addressing complicates IPsec handling considerably. This
section describes at least some of these complications. section describes at least some of these complications.
RSVP messages are transmitted as raw IP packets with protocol number RSVP messages are transmitted as raw IP packets with protocol number
46. It might be possible to encapsulate them in UDP as described in 46. It might be possible to encapsulate them in UDP as described in
Appendix C of [6]. Some RSVP messages (Path, PathTear, and ResvConf) Appendix C of [6]. Some RSVP messages (Path, PathTear, and ResvConf)
must have the Router Alert IP Option set in the IP header. These must have the Router Alert IP Option set in the IP header. These
messages are addressed to the (unicast or multicast) destination messages are addressed to the (unicast or multicast) destination
address and not to the next RSVP node along the path. Hence an IPsec address and not to the next RSVP node along the path. Hence, an
traffic selector can only use these fields for IPsec SA selection. IPsec traffic selector can only use these fields for IPsec SA
If there is only a single path (and possibly all traffic along it is selection. If there is only a single path (and possibly all traffic
protected) then there is no problem for IPsec protection of signaling along it is protected) then there is no problem for IPsec protection
messages. This type of protection is not common and might only be of signaling messages. This type of protection is not common and
used to secure network access between an end host and its first-hop might only be used to secure network access between an end host and
router. Because the described RSVP messages are addressed to the its first-hop router. Because the described RSVP messages are
destination address instead of the next RSVP node, it is not possible addressed to the destination address instead of the next RSVP node,
to use IPsec ESP [21] or AH [20] in transport mode--only IPsec in it is not possible to use IPsec ESP [17] or AH [16] in transport
tunnel mode is possible. mode--only IPsec in tunnel mode is possible.
5.7 Authorization If an RSVP message can taket more than one possible path, then the
IPsec engine will experience difficulties protecting the message.
Even if the RSVP daemon installs a traffic selector with the
destination IP address, still, no distinguishing element allows
selection of the correct security association for one of the possible
RSVP nodes along the path. Even if it possible to apply IPsec
protection (in tunnel mode) for RSVP signaling messages by
incorporating some additional information, there is still the
possibility that the tunneled messages do not recognize a path change
in a non-RSVP router. In this case the signaling messages would
simply follow a different path than the data.
[37] describes two trust models (NJ Turnpike and NJ Parkway) and two RSVP messages like RESV can be protected by IPsec, because they
contain enough information to create IPsec traffic selectors that
allow differentiation between various next RSVP nodes. The traffic
selector would then contain the protocol number and the source and
destination address pair of the two communicating RSVP nodes.
One benefit of using IPsec is the availability of key management
using either IKE [39], KINK [40] or IKEv2 [41].
5.7. Authorization
[34] describes two trust models (NJ Turnpike and NJ Parkway) and two
authorization models (per-session and per-channel financial authorization models (per-session and per-channel financial
settlement). The NJ Turnpike model gives a justification for settlement). The NJ Turnpike model gives a justification for hop-by-
hop-by-hop security protection. RSVP focuses on the NJ Turnpike hop security protection. RSVP focuses on the NJ Turnpike model,
model although the different trust models are not described in although the different trust models are not described in detail.
detail. RSVP supports the NJ Parkway model and per-channel financial RSVP supports the NJ Parkway model and per-channel financial
settlement only to a certain extent. Authentication of the user (or settlement only to a certain extent. Authentication of the user (or
end host) can be provided with the user identity representation end host) can be provided with the user identity representation
mechanism but authentication might in many cases be insufficient for mechanism, but authentication might, in many cases, be insufficient
authorization. The communication procedures defined for policy for authorization. The communication procedures defined for policy
objects [42] can be improved to support the more efficient
per-channel financial settlement model by avoiding policy handling objects [42] can be improved to support the more efficient per-
channel financial settlement model by avoiding policy handling
between inter-domain networks at a signaling message granularity. between inter-domain networks at a signaling message granularity.
Additional information about expected behavior of policy handling in Additional information about expected behavior of policy handling in
RSVP can also be obtained from [43]. RSVP can also be obtained from [43].
[38] and [39] provide additional information on authorization. No [35] and [36] provide additional information on authorization. No
good and agreed mechanism for dealing with authorization of QoS good and agreed mechanism for dealing with authorization of QoS
reservations in roaming environments is provided. Price distribution reservations in roaming environments is provided. Price distribution
mechanisms are only described in papers and never made their way mechanisms are only described in papers and never made their way
through standardization. RSVP focuses on receiver-initiated through standardization. RSVP focuses on receiver-initiated
reservations with authorization for the QoS reservation by the data reservations with authorization for the QoS reservation by the data
receiver which introduces a fair number of complexity for mobility receiver, which introduces a fair amount of complexity for mobility
handling as described, for example, in [39]. handling as described, for example, in [36].
6. Conclusions 6. Conclusions
RSVP was the first QoS signaling protocol that provided some security RSVP was the first QoS signaling protocol that provided some security
protection. Whether RSVP provides enough security protection heavily protection. Whether RSVP provides appropriate security protection
depends on the environment where it is deployed. RSVP as specified heavily depends on the environment where it is deployed. RSVP as
today should be seen as a building block that has to be adapted to a specified today should be viewed as a building block that has to be
given architecture. adapted to a given architecture.
This document aims to provide more insights into the security of This document aims to provide more insight into the security of RSVP.
RSVP. It cannot not be interpreted as a pass or fail evaluation of It cannot be interpreted as a pass or fail evaluation of the security
the security provided by RSVP. provided by RSVP.
Certainly this document is not a complete description of all security Certainly this document is not a complete description of all security
issues related to RSVP. Some issues that require further issues related to RSVP. Some issues that require further
consideration are RSVP extensions (for example [13]), multicast consideration are RSVP extensions (for example [12]), multicast
issues, and other security properties like traffic analysis. issues, and other security properties like traffic analysis.
Additionally, the interaction with mobility protocols (micro- and Additionally, the interaction with mobility protocols (micro- and
macro-mobility) from a security point of view demands further macro-mobility) demands further investigation from a security point
investigation. of view.
What can be learned from practical protocol experience and from the What can be learned from practical protocol experience and from the
increased awareness regarding security is that some of the available increased awareness regarding security is that some of the available
credential types have received more acceptance than others. Kerberos credential types have received more acceptance than others. Kerberos
is a system that is integrated into many IETF protocols today. is a system that is integrated into many IETF protocols today.
Public key based authentication techniques are however still Public-key-based authentication techniques are, however, still
considered to be too heavy-weight (computationally and from a considered to be too heavy-weight (computationally and from a
bandwidth perspective) to be used for per-flow signaling. The bandwidth perspective) to be used for per-flow signaling. The
increased focus on denial of service attacks put additional demands increased focus on denial of service attacks puts additional demands
on the design of public key based authentication. on the design of public-key-based authentication.
The following list briefly summarizes a few security or architectural The following list briefly summarizes a few security or architectural
issues that deserve improvement: issues that deserve improvement:
o Discovery and signaling message delivery should be separated. o Discovery and signaling message delivery should be separated.
o For some applications and scenarios it cannot be assumed that
neighboring RSVP-aware nodes know each other. Hence some in-path o For some applications and scenarios, it cannot be assumed that
neighboring RSVP-aware nodes know each other. Hence, some in-path
discovery mechanism should be provided. discovery mechanism should be provided.
o Addressing for signaling messages should be done in a hop-by-hop o Addressing for signaling messages should be done in a hop-by-hop
fashion. fashion.
o Standard security protocols (IPsec, TLS or CMS) should be used
o Standard security protocols (IPsec, TLS, or CMS) should be used
whenever possible. Authentication and key exchange should be whenever possible. Authentication and key exchange should be
separated from signaling message protection. In general, it is separated from signaling message protection. In general, it is
necessary to provide key management to establish security necessary to provide key management to establish security
associations dynamically for signaling message protection. associations dynamically for signaling message protection.
Relying on manually configured keys between neighboring RSVP nodes Relying on manually configured keys between neighboring RSVP nodes
is insufficient. A separate, less frequently executed key is insufficient. A separate, less frequently executed key
management and security association establishment protocol is a management and security association establishment protocol is a
good place to perform entity authentication, security service good place to perform entity authentication, security service
negotiation and selection, and agreement on mechanisms, negotiation and selection, and agreement on mechanisms,
transforms, and options. transforms, and options.
skipping to change at page 38, line 6 skipping to change at page 39, line 28
whenever possible. Authentication and key exchange should be whenever possible. Authentication and key exchange should be
separated from signaling message protection. In general, it is separated from signaling message protection. In general, it is
necessary to provide key management to establish security necessary to provide key management to establish security
associations dynamically for signaling message protection. associations dynamically for signaling message protection.
Relying on manually configured keys between neighboring RSVP nodes Relying on manually configured keys between neighboring RSVP nodes
is insufficient. A separate, less frequently executed key is insufficient. A separate, less frequently executed key
management and security association establishment protocol is a management and security association establishment protocol is a
good place to perform entity authentication, security service good place to perform entity authentication, security service
negotiation and selection, and agreement on mechanisms, negotiation and selection, and agreement on mechanisms,
transforms, and options. transforms, and options.
o The use of public key cryptography in authorization tokens, o The use of public key cryptography in authorization tokens,
identity representations, selective object protection, etc. is identity representations, selective object protection, etc. is
likely to cause fragmentation, the need to protect against denial likely to cause fragmentation, the need to protect against denial
of service attacks, and other problems. of service attacks, and other problems.
o Public key authentication and user identity confidentiality o Public key authentication and user identity confidentiality
provided with RSVP require some improvement. provided with RSVP require some improvement.
o Public key based user authentication only provides entity
o Public-key-based user authentication only provides entity
authentication. An additional security association is required to authentication. An additional security association is required to
protect signaling messages. protect signaling messages.
o Data origin authentication should not be provided by non-RSVP o Data origin authentication should not be provided by non-RSVP
nodes (such as the PDP). Such a procedure could be accomplished nodes (such as the PDP). Such a procedure could be accomplished
by entity authentication during the authentication and key by entity authentication during the authentication and key
exchange phase. exchange phase.
o Authorization and charging should be better integrated into the o Authorization and charging should be better integrated into the
base protocol. base protocol.
o Selective message protection should be provided. A protected o Selective message protection should be provided. A protected
message should be recognizable from a flag in the header. message should be recognizable from a flag in the header.
o Confidentiality protection is missing and should therefore be o Confidentiality protection is missing and should therefore be
added to the protocol. The general principle is that protocol added to the protocol. The general principle is that protocol
designers can seldom foresee all of the environments in which designers can seldom foresee all of the environments in which
protocols will be run, so they should allow users to select from a protocols will be run, so they should allow users to select from a
full range of security services, as the needs of different user full range of security services, as the needs of different user
communities vary. communities vary.
o Parameter and mechanism negotiation should be provided. o Parameter and mechanism negotiation should be provided.
7. Security Considerations 7. Security Considerations
This document discusses security properties of RSVP and, as such, it This document discusses security properties of RSVP and, as such, it
is concerned entirely with security. is concerned entirely with security.
8. IANA considerations 8. Acknowledgements
This document does not address any IANA considerations.
9. Acknowledgments
We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu, We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu,
Guenther Schaefer, Marc De Vuyst, Bob Grillo and Jukka Manner for Guenther Schaefer, Marc De Vuyst, Bob Grillo, and Jukka Manner for
their valuable comments. Additionally, we would like to thank Robert their comments. Additionally, Hannes would like to thank Robert and
and Jorge for their time to discuss various issues with me. Jorge for their time discussing various issues.
Finally we would Allison Mankin and John Loughney for their comments. Finally, we would like to thank Allison Mankin and John Loughney for
their guidance and input.
10. References 9. References
10.1 Normative References 9.1. Normative References
[1] Baker, F., Lindell, B. and M. Talwar, "Identity Representation [1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
for RSVP", January 2000. Authentication", RFC 2747, January 2000.
[2] Herzog, S., "RSVP Extensions for Policy Control", January 2000. [2] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[3] Kent, S., Atkinson, R. and M. Talwar, "Security Architecture [3] Kent, S. and R. Atkinson, "Security Architecture for the
for the Internet Protocol", November 1998. Internet Protocol", RFC 2401, November 1998.
[4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing [4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", February 1997. for Message Authentication", RFC 2104, February 1997.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992. [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[6] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [6] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) - Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", September 1997. Specification", RFC 2205, September 1997.
[7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for RSVP", Herzog, S., and R. Hess, "Identity Representation for RSVP",
October 2001. RFC 3182, October 2001.
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication [8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", September 1993. Service (V5)", RFC 1510, September 1993. Obsoleted by RFC
4120.
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003. "Diameter Base Protocol", RFC 3588, September 2003.
[10] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A. [10] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
Sastry, "The COPS(Common Open Policy Service) Protocol", Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
January 2000. 2748, January 2000.
[11] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A.
Sastry, "COPS usage for RSVP", January 2000.
[12] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", draft-ietf-krb-wg-crypto-07 (work in progress),
February 2004.
[13] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", September 1997.
[14] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
Operation Over IP Tunnels", January 2000.
[15] Tung, B. and L. Zhu, "Public Key Cryptography for Initial [11] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-24 Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
(work in progress), February 2005.
[16] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [12] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. Flows", RFC 2207, September 1997.
[17] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of [13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Keys (KINK)", draft-ietf-kink-kink-06 (work in progress), July Operation Over IP Tunnels", RFC 2746, January 2000.
2004.
10.2 Informative References 9.2. Informative References
[18] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control", [14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control",
Internet-Draft(Expired) draft-ietf-rap-new-rsvp-ext-00.txt, Work in Progress, June 2001.
June 2001.
[19] "Secure Hash Standard,NIST, FIPS PUB 180-1", April 1995. [15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal
Information Processing Society, April 1995.
[20] Kent, S. and R. Atkinson, "IP Authentication Header", November [16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
1998. November 1998.
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", November 1998. (ESP)", RFC 2406, November 1998.
[22] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 [18] Fowler, D., "Definitions of Managed Objects for the DS1, E1,
Public Key Infrastructure Certificate and CRL Profile", January DS2 and E2 Interface Types", RFC 2495, January 1999.
1999.
[23] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP [19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
Message Format", November 1998. "OpenPGP Message Format", RFC 2440, November 1998.
[24] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and [20] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
Realm Information with DNS", Internet-Draft(Expired) Realm Information with DNS", Work in Progress, July 2002.
draft-ietf-krb-wg-krb-dns-locate-03.txt, July 2002.
[25] Dobbertin, H., Bosselaers, A. and B. Preneel, "RIPEMD-160: A [21] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
strengthened version of RIPEMD in Fast Software Encryption, strengthened version of RIPEMD in Fast Software Encryption",
LNCS Vol 1039, pp. 71-82", 1996. LNCS vol. 1039, pp. 71-82, 1996.
[26] Dobbertin, H., "The Status of Md5 After a Recent Attack, RSA [22] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
Laboratories CryptoBytes, Volume 2, Number 2", 1996. Laboratories CryptoBytes, vol. 2, no. 2, 1996.
[27] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication [23] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Protocol (EAP)", March 1998. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[28] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [24] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[29] ""Microsoft Authorization Data Specification v. 1.0 for [25] "Microsoft Authorization Data Specification v. 1.0 for
Microsoft Windows 2000 Operating Systems", April 2000. Microsoft Windows 2000 Operating Systems", April 2000.
[30] Cable Television Laboratories, Inc.,, "PacketCable Security [26] Cable Television Laboratories, Inc., "PacketCable Security
Specification,PKT-SP-SEC-I01-991201", website Specification, PKT-SP-SEC-I01-991201", website:
http://www.PacketCable.com/ , June 2003. http://www.PacketCable.com/ , June 2003.
[31] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, [27] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", June 1999. Status Protocol - OCSP", RFC 2560, June 1999.
[32] Malpani, A., Hoffman, P., Housley, R. and T. Freeman, "Simple [28] Malpani, A., Housley, R., and T. Freeman, "Simple Certificate
Certificate Validation Protocol (SCVP)", Internet-Draft(Work in Validation Protocol (SCVP)", Work in Progress, October 2005.
progress) draft-ietf-pkix-scvp-11.txt, December 2002.
[33] Housley, R., "Cryptographic Message Syntax", June 1999. [29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[34] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version [30] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1.5", March 1998. 1.5", RFC 2315, March 1998.
[35] "Specifications and standard documents", website [31] "Specifications and standard documents", website:
http://www.PacketCable.com/ , March 2002. http://www.PacketCable.com/ , March 2002.
[36] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History, [32] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History,
Protocols and Implementation in "USENIX Computing Systems Protocols and Implementation", USENIX Computing Systems, vol 9
Volume 9 no. 1, Winter", 1996. no. 1, Winter 1996.
[37] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. [33] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[34] Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
Schulzrinne, "NSIS Authentication, Authorization and Accounting Schulzrinne, "NSIS Authentication, Authorization and Accounting
Issues", Internet-Draft(Work in progress) Issues", Work in Progress, March 2003.
draft-tschofenig-nsis-aaa-issues-01.txt, March 2003.
[38] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne, H. [35] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne,
and T. Chen, "QoS NSLP Authorization Issues", H., and T. Chen, "QoS NSLP Authorization Issues", Work in
Internet-Draft(Work in progress) Progress, June 2003.
draft-tschofenig-nsis-qos-authz-issues-00.txt, June 2003.
[39] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", [36] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work
Internet-Draft(Work in progress) in Progress, October 2002.
draft-thomas-nsis-rsvp-analysis-00.txt, October 2002.
[40] Gai, S., Dutt, D., Elfassy, N. and Y. Bernet, "RSVP Proxy", [37] Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP
Internet-Draft(Expired) draft-ietf-rsvp-proxy-03.txt, March Proxy", Work in Progress, March 2002.
2002.
[41] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K. [38] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K.
Raatikainen, "Localized RSVP", Internet-Draft(Expired) Raatikainen, "Localized RSVP", Work in Progress, September
draft-manner-lrsvp-00.txt, May 2002. 2004.
[42] Herzog, S., "Accounting and Access Control in RSVP,", PhD [39] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
Dissertation,", Internet-Draft(Expired) RFC 2409, November 1998.
draft-ietf-rsvp-lpm-arch-00.txt, November 1995.
[40] Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)",
Work in Progress, October 2005.
[41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, November 2005.
[42] Herzog, S., "Accounting and Access Control in RSVP", PhD
Dissertation, USC, Work in Progress, November 1995.
[43] Herzog, S., "Accounting and Access Control for Multicast [43] Herzog, S., "Accounting and Access Control for Multicast
Distributions: Models and Mechanisms", June 1996. Distributions: Models and Mechanisms", June 1996.
[44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing [44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
Attacks ,Open Software Foundation DCE Request for Comments", Attacks", Open Software Foundation DCE Request for Comments,
December 1992. December 1992.
[45] Wu, T., "A Real-World Analysis of Kerberos Password Security", [45] Tung, B. and L. Zhu, "Public Key Cryptography for Initial
February 1999. Authentication in Kerberos", Work in Progress, November 2005.
[46] Wu, T., Wu, F. and F. Gong, "Securing QoS: Threats to RSVP [46] Wu, T., "A Real-World Analysis of Kerberos Password Security",
Messages and Their Countermeasures in "IEEE IWQoS, pp. 62-64", in Proceedings of the 1999 Internet Society Network and
Distributed System Security Symposium, San Diego, February
1999. 1999.
[47] Talwar, V., Nahrstedt, K. and F. Gong, "Securing RSVP For [47] Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP
Multimedia Applications in "Proceedings of ACM Multimedia Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64,
(Multimedia Security Workshop)"", November 2000. 1999.
[48] Talwar, V., Nahrstedt, K. and S. Nath, "RSVP-SQoS : A Secure
RSVP Protocol in "International Conference on Multimedia and
Exposition", Tokyo , Japan", August 2001.
[49] Jablon, D., "Strong password-only authenticated key exchange
Computer Communication Review, 26(5), pp. 5-26",
Internet-Draft(Expired) draft-ietf-rap-new-rsvp-ext-00.txt,
October 1996.
[50] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
November 1998.
Authors' Addresses
Hannes Tschofenig [48] Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For
Siemens Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia
Otto-Hahn-Ring 6 Security Workshop), November 2000.
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com [49] Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure
Richard Graveman RSVP Protocol", International Conf on Multimedia and
RFG Security Exposition, Tokyo, Japan, August 2001.
15 Park Avenue
Morristown, NJ 07960
USA
EMail: rfg@acm.org [50] Jablon, D., "Strong Password-only Authenticated Key Exchange",
ACM Computer Communication Review, 26(5), pp. 5-26, October
1996.
Appendix A. Dictionary Attacks and Kerberos Appendix A. Dictionary Attacks and Kerberos
Kerberos might be used with RSVP as described in this document. Kerberos might be used with RSVP as described in this document.
Because dictionary attacks are often mentioned in relationship with Because dictionary attacks are often mentioned in relationship with
Kerberos, a few issues are addressed here. Kerberos, a few issues are addressed here.
The initial Kerberos AS_REQ request (without pre-authentication, The initial Kerberos AS_REQ request (without pre-authentication,
without various extensions, and without PKINIT) is unprotected. The without various extensions, and without PKINIT) is unprotected. The
response message AS_REP is encrypted with the client's long-term key. response message AS_REP is encrypted with the client's long-term key.
An adversary can take advantage of this fact by requesting AS_REP An adversary can take advantage of this fact by requesting AS_REP
messages to mount an off-line dictionary attack. Pre-authentication messages to mount an off-line dictionary attack. Pre-authentication
([44]) can be used to reduce this problem. However, ([44]) can be used to reduce this problem. However, pre-
pre-authentication does not entirely prevent dictionary attacks by an authentication does not entirely prevent dictionary attacks by an
adversary who can still eavesdrop on Kerberos messages along the path adversary who can still eavesdrop on Kerberos messages along the path
between a mobile node and a KDC. With mandatory pre-authentication between a mobile node and a KDC. With mandatory pre-authentication
for the initial request, an adversary cannot request a Ticket for the initial request, an adversary cannot request a Ticket
Granting Ticket for an arbitrary user. On-line password guessing Granting Ticket for an arbitrary user. On-line password guessing
attacks are still possible by choosing a password (e.g., from a attacks are still possible by choosing a password (e.g., from a
dictionary) and then transmitting an initial request including a dictionary) and then transmitting an initial request that includes a
pre-authentication data field. An unsuccessful authentication by the pre-authentication data field. An unsuccessful authentication by the
KDC results in an error message and the gives the adversary a hint to KDC results in an error message and thus gives the adversary a hint
restart the protocol and try a new password. to restart the protocol and try a new password.
There are, however, some proposals that prevent dictionary attacks. There are, however, some proposals that prevent dictionary attacks.
The use of Public Key Cryptography for initial authentication [15] The use of Public Key Cryptography for initial authentication [45]
(PKINIT) is one such solution. Other proposals use (PKINIT) is one such solution. Other proposals use strong-password-
strong-password-based authenticated key agreement protocols to based authenticated key agreement protocols to protect the user's
protect the user's password during the initial Kerberos exchange. password during the initial Kerberos exchange. [46] discusses the
[45] discusses the security of Kerberos and also discusses mechanisms security of Kerberos and also discusses mechanisms to prevent
to prevent dictionary attacks. dictionary attacks.
Appendix B. Example of User-to-PDP Authentication Appendix B. Example of User-to-PDP Authentication
The following Section describes an example of user-to-PDP The following Section describes an example of user-to-PDP
authentication. Note that the description below is not fully covered authentication. Note that the description below is not fully covered
by the RSVP specification and hence it should only be seen as an by the RSVP specification and hence it should only be viewed as an
example. example.
Windows 2000, which integrates Kerberos into RSVP, uses a Windows 2000, which integrates Kerberos into RSVP, uses a
configuration with the user authentication to the PDP as described in configuration with the user authentication to the PDP as described in
[29]. The steps for authenticating the user to the PDP in an [25]. The steps for authenticating the user to the PDP in an intra-
intra-realm scenario are the following: realm scenario are the following:
o Windows 2000 requires the user to contact the KDC and to request a o Windows 2000 requires the user to contact the KDC and to request a
Kerberos service ticket for the PDP account AcsService in the Kerberos service ticket for the PDP account AcsService in the
local realm . local realm .
o This ticket is then embedded into the AUTH_DATA element and o This ticket is then embedded into the AUTH_DATA element and
included in either the PATH or the RESV message. In case of included in either the PATH or the RESV message. In the case of
Microsoft's implementation, the user identity encoded as a Microsoft's implementation, the user identity encoded as a
distinguished name is encrypted with the session key provided with distinguished name is encrypted with the session key provided with
the Kerberos ticket. The Kerberos ticket is sent without the the Kerberos ticket. The Kerberos ticket is sent without the
Kerberos authdata element that contains authorization information, Kerberos authdata element that contains authorization information,
as explained in [29]. as explained in [25].
o The RSVP message is then intercepted by the PEP, which forwards it o The RSVP message is then intercepted by the PEP, which forwards it
to the PDP. [29] does not state which protocol is used to forward to the PDP. [25] does not state which protocol is used to forward
the RSVP message to the PDP. the RSVP message to the PDP.
o The PDP that finally receives the message decrypts the received
service ticket. The ticket contains the session key used by the o The PDP that finally receives the message and decrypts the
user's host to received service ticket. The ticket contains the session key used
by the user's host to
* Encrypt the principal name inside the policy locator field of * Encrypt the principal name inside the policy locator field of
the AUTH_DATA object and to the AUTH_DATA object and to
* Create the integrity-protected Keyed Message Digest field in * Create the integrity-protected Keyed Message Digest field in
the INTEGRITY object of the POLICY_DATA element. The the INTEGRITY object of the POLICY_DATA element. The
protection described here is between the user's host and the protection described here is between the user's host and the
PDP. The RSVP INTEGRITY object on the other hand is used to PDP. The RSVP INTEGRITY object on the other hand is used to
protect the path between the user's host and the first-hop protect the path between the user's host and the first-hop
router, because the two message parts terminate at different router, because the two message parts terminate at different
nodes and different security associations must be used. The nodes, and different security associations must be used. The
interface between the message-intercepting, first-hop router interface between the message-intercepting, first-hop router
and the PDP must be protected as well. and the PDP must be protected as well.
* The PDP does not maintain a user database, and [29] describes
* The PDP does not maintain a user database, and [25] describes
how the PDP may query the Active Directory (a LDAP based how the PDP may query the Active Directory (a LDAP based
directory service) for user policy information. directory service) for user policy information.
Appendix C. Literature on RSVP Security Appendix C. Literature on RSVP Security
Few documents address the security of RSVP signaling. This section Few documents address the security of RSVP signaling. This section
briefly describes some important documents. briefly describes some important documents.
Improvements to RSVP are proposed in [46] to deal with insider Improvements to RSVP are proposed in [47] to deal with insider
attacks. Insider attacks are caused by malicious RSVP routers that attacks. Insider attacks are caused by malicious RSVP routers that
modify RSVP signaling messages in such a way that they cause harm to modify RSVP signaling messages in such a way that they cause harm to
the nodes participating in the signaling message exchange. the nodes participating in the signaling message exchange.
As a solution, non-mutable RSVP objects are digitally signed by the As a solution, non-mutable RSVP objects are digitally signed by the
sender. This digital signature is added to the RSVP PATH message. sender. This digital signature is added to the RSVP PATH message.
Additionally, the receiver attaches an object to the RSVP RESV Additionally, the receiver attaches an object to the RSVP RESV
message containing a "signed" history. This value allows message containing a "signed" history. This value allows
intermediate RSVP routers (by examining the previously signed value) intermediate RSVP routers (by examining the previously signed value)
to detect a malicious RSVP node. to detect a malicious RSVP node.
A few issues are, however, left open in the document. Replay attacks A few issues are, however, left open in this document. Replay
are not covered, and it is therefore assumed that timestamp-based attacks are not covered, and it is therefore assumed that timestamp-
replay protection is used. To detect a malicious node, it is based replay protection is used. To identify a malicious node, it is
necessary that all routers along the path are able to verify the necessary that all routers along the path are able to verify the
digital signature. This may require a global public key digital signature. This may require a global public key
infrastructure and also client-side certificates. Furthermore the infrastructure and also client-side certificates. Furthermore, the
bandwidth and computational requirements to compute, transmit, and bandwidth and computational requirements to compute, transmit, and
verify digital signatures for each signaling message might place a verify digital signatures for each signaling message might place a
burden on a real-world deployment. burden on a real-world deployment.
Authorization is not considered in the document, which might have an Authorization is not considered in the document, which might have an
influence on the implications of signaling message modification. influence on the implications of signaling message modification.
Hence, the chain-of-trust relationship (or this step in a different Hence, the chain-of-trust relationship (or this step in a different
direction) should be considered in relationship with authorization. direction) should be considered in relationship with authorization.
In [47], the above-described idea of detecting malicious RSVP nodes In [48], the above-described idea of detecting malicious RSVP nodes
is improved by addressing performance aspects. The proposed solution is improved by addressing performance aspects. The proposed solution
is somewhere between hop-by-hop security and the approach in [46], is somewhere between hop-by-hop security and the approach in [47],
insofar as it separates the end-to-end path into individual networks. insofar as it separates the end-to-end path into individual networks.
Furthermore, some additional RSVP messages (e.g., feedback messages) Furthermore, some additional RSVP messages (e.g., feedback messages)
are introduced to implement a mechanism called "delayed integrity are introduced to implement a mechanism called "delayed integrity
checking." In [48], the approach presented in [47] is enhanced. checking." In [49], the approach presented in [48] is enhanced.
Intellectual Property Statement Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Richard Graveman
RFG Security
15 Park Avenue
Morristown, NJ 07960
USA
EMail: rfg@acm.org
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 309 change blocks. 
1067 lines changed or deleted 1198 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/