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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/