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