draft-ietf-nsis-rsvp-sec-properties-00.txt   draft-ietf-nsis-rsvp-sec-properties-01.txt 
Hannes Tschofenig Hannes Tschofenig
Internet Draft Siemens AG Internet Draft Siemens
Document: draft-ietf-nsis-rsvp-sec- Document:
properties-00.txt draft-ietf-nsis-rsvp-sec-properties-01.txt
Expires: April, 2003 Expires: September, 2003
October, 2002 March, 2003
RSVP Security Properties RSVP Security Properties
<draft-ietf-nsis-rsvp-sec-properties-00.txt> <draft-ietf-nsis-rsvp-sec-properties-01.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.
skipping to change at line 34 skipping to change at line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Tschofenig Informational - Expires April 2003 1 Tschofenig Informational - Expires April 2003 1
RSVP Security Properties October 2002 RSVP Security Properties March 2003
Abstract Abstract
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 implication for the design of a concerns about security and its implication 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 tries to summarize the security properties of RSVP and This document tries to summarize the security properties of RSVP and
to view them from a different point of view. This work in NSIS is to view them from a different point of view. This work in NSIS is
part of the overall process of analyzing other protocols and to learn part of the overall process of analyzing other signaling protocols
from their design considerations. This document should also provide a and to learn from their design considerations. This document should
starting point for security discussions. also provide a starting point for security discussions.
Table of Contents Table of Contents
1 Introduction...................................................2 1 Introduction...................................................3
2 Terminology....................................................3 2 Terminology....................................................3
3 Overview.......................................................4 3 Overview.......................................................5
3.1 The RSVP INTEGRITY Object....................................5 3.1 The RSVP INTEGRITY Object....................................5
3.2 Security Associations........................................6 3.2 Security Associations........................................6
3.3 RSVP Key Management Assumptions..............................7 3.3 RSVP Key Management Assumptions..............................7
3.4 Identity Representation......................................7 3.4 Identity Representation......................................7
3.5 RSVP Integrity Handshake....................................11 3.5 RSVP Integrity Handshake....................................11
4 Detailed Security Property Discussion.........................12 4 Detailed Security Property Discussion.........................12
4.1 Discussed Network Topology..................................12 4.1 Discussed Network Topology..................................12
4.2 Host/Router.................................................12 4.2 Host/Router.................................................13
4.3 User to PEP/PDP.............................................17 4.3 User to PEP/PDP.............................................17
4.4 Communication between RSVP aware routers....................25 4.4 Communication between RSVP aware routers....................25
4.5 Miscellaneous Issues........................................27 5 Miscellaneous Issues..........................................28
4.5.1 Dictionary Attacks and Kerberos............................27 5.1 First Hop Issue.............................................28
4.5.2 Example of User-to-PDP Authentication......................29 5.2 Next-Hop Problem............................................28
4.5.3 Open Issues................................................30 5.3 Last-Hop Issue..............................................30
5 Conclusions...................................................31 5.4 RSVP and IPsec..............................................31
6 Security Considerations.......................................32 5.5 End-to-End Security Issues and RSVP.........................33
7 IANA considerations...........................................32 5.6 IPsec protection of RSVP signaling messages.................33
8 Open Issues...................................................32 5.7 Accounting/Charging Framework...............................34
9 Acknowledgments...............................................32 6 Conclusions...................................................34
10 References....................................................33 7 Security Considerations.......................................36
11 Author's Contact Information..................................36 8 IANA considerations...........................................36
12 Full Copyright Statement......................................36 9 Open Issues...................................................36
10 Acknowledgments...............................................36
Appendix A. Dictionary Attacks and Kerberos......................36
Appendix B. Example of User-to-PDP Authentication................38
11 References....................................................39
12 Author's Contact Information..................................42
13 Full Copyright Statement......................................43
Tschofenig Informational - Expires September 2003 2
RSVP Security Properties March 2003
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 implication for the design of a concerns about security and its implication 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 tries to summarize the security properties of RSVP and This document tries to summarize the security properties of RSVP and
to view them from a different point of view. This work in NSIS is to view them from a different point of view. This work in NSIS is
part of the overall process of analyzing other signaling protocols
Tschofenig Informational - Expires April 2003 2 and to learn from their design considerations. This document should
RSVP Security Properties October 2002 also provide a starting point for further discussions.
part of the overall process of analyzing other protocols and to learn
from their design considerations. This document should also 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 by
RSVP including the INTEGRITY object, a description of the identity RSVP including the INTEGRITY object, a description of the identity
representation within the POLICY_DATA object (i.e. user representation within the POLICY_DATA object (i.e. user
authentication) and the RSVP Integrity Handshake mechanism. authentication) and the RSVP Integrity Handshake mechanism.
Section 4 provides a more detailed discussion of the used mechanism Section 4 provides a more detailed discussion of the used mechanism
and tries to describe the mechanisms provided in detail. and tries to describe the mechanisms provided in detail.
Finally the last Section briefly addresses issues like the discussion Finally a number of miscellaneous issues are described which address
of the vulnerability of Kerberos against dictionary attacks and open first-hop, next-hop and last-hop issues. Furthermore the problem of
issues in the context of RSVP and issues for further investigation. IPsec security protection of data traffic and RSVP signaling message
is discussed.
2 Terminology 2 Terminology
To begin with the description of the security properties of RSVP it To begin with the description of the security properties of RSVP it
is natural to describe some basic building-blocks. is natural to explain some terms used throughout the document.
- Chain-of-Trust - Chain-of-Trust
The security mechanisms supported by RSVP [RFC2747] heavily relies on The security mechanisms supported by RSVP [RFC2747] heavily relies on
optional hop-by-hop protection using the built-in INTEGRITY object. optional hop-by-hop protection using the built-in INTEGRITY object.
Hop-by-hop security with the INTEGRITY object inside the RSVP message Hop-by-hop security with the INTEGRITY object inside the RSVP message
thereby refers to the protection between RSVP supporting network thereby refers to the protection between RSVP supporting network
elements. Additionally there is the notion of policy aware network elements. Additionally there is the notion of policy aware network
elements that additionally understand the POLICY_DATA element within elements that additionally understand the POLICY_DATA element within
the RSVP message. Since this element also includes an INTEGRITY the RSVP message. Since this element also includes an INTEGRITY
object there is an additional hop-by-hop security mechanism that object there is an additional hop-by-hop security mechanism that
provides security between policy aware nodes. Policy ignorant nodes provides security between policy aware nodes. Policy ignorant nodes
are not affected by the inclusion of this object in the POLICY_DATA are not affected by the inclusion of this object in the POLICY_DATA
element since they do not try to interpret it. element since they do not try to interpret it.
To protect signaling messages that are possibly modified by each RSVP To protect signaling messages that are possibly modified by each RSVP
router along the path it must be assumed that each incoming request router along the path it must be assumed that each incoming request
is authenticated, integrity and replay protected. This provides is authenticated, integrity and replay protected. This provides
protection against unauthorized nodes injecting bogus messages. protection against unauthorized nodes injecting bogus messages.
Furthermore each RSVP-router is assumed to behave in the expected Furthermore each RSVP-router is assumed to behave in the expected
Tschofenig Informational - Expires September 2003 3
RSVP Security Properties March 2003
manner. Outgoing messages transmitted to the next hop network element manner. Outgoing messages transmitted to the next hop network element
experience protection according RSVP security processing. experience protection according RSVP security processing.
Using the above described mechanisms a chain-of-trust is created Using the above described mechanisms a chain-of-trust is created
whereby a signaling message transmitted by router A via router B and whereby a signaling message transmitted by router A via router B and
received by router C is supposed to be secure if router A and B and received by router C is supposed to be secure if router A and B and
router B and C share a security association and all routers behave router B and C share a security association and all routers behave
expectedly. Hence router C trusts router A although router C does not expectedly. Hence router C trusts router A although router C does not
have a direct security association with router A. We can therefore have a direct security association with router A. We can therefore
Tschofenig Informational - Expires April 2003 3
RSVP Security Properties October 2002
conclude that the protection achieved with this hop-by-hop security conclude that the protection achieved with this hop-by-hop security
for the chain-of-trust is as good as the weakest link in the chain. for the chain-of-trust is as good as the weakest link in the chain.
If one router is malicious (for example because an adversary has If one router is malicious (for example because an adversary has
control over this router) then it can arbitrarily modify messages and control over this router) then it can arbitrarily modify messages and
cause unexpected behavior and mount a number of attacks not only cause unexpected behavior and mount a number of attacks not only
restricted to QoS signaling. Additionally it must be mentioned that restricted to QoS signaling. Additionally it must be mentioned that
some protocols demand more protection than others (this depends some protocols demand more protection than others (this depends
between which nodes these protocols are executed). For example edge between which nodes these protocols are executed). For example edge
devices, where end-users are attached, may more likely be attacked in devices, where end-users are attached, may more likely be attacked in
skipping to change at line 186 skipping to change at line 192
For most of the security associations required for the protection of For most of the security associations required for the protection of
RSVP signaling messages it is assumed that they are already available RSVP signaling messages it is assumed that they are already available
and hence key management was done in advance. There is however an and hence key management was done in advance. There is however an
exception with the support for Kerberos. Using Kerberos an entity is exception with the support for Kerberos. Using Kerberos an entity is
able to distribute a session key used for RSVP signaling protection. able to distribute a session key used for RSVP signaling protection.
- RSVP INTEGRITY and POLICY_DATA INTEGRITY Object - RSVP INTEGRITY and POLICY_DATA INTEGRITY Object
RSVP uses the INTEGRITY object in two places of the message. The RSVP uses the INTEGRITY object in two places of the message. The
first usage is in the RSVP message itself and covers the entire RSVP first usage is in the RSVP message itself and covers the entire RSVP
Tschofenig Informational - Expires September 2003 4
RSVP Security Properties March 2003
message as defined in [RFC2747] whereas the latter is included in the message as defined in [RFC2747] whereas the latter is included in the
POLICY_DATA object and defined in [RFC2750]. In order to POLICY_DATA object and defined in [RFC2750]. In order to
differentiate the two objects regarding their scope of protection the differentiate the two objects regarding their scope of protection the
two terms RSVP INTEGRITY and POLICY_DATA INTEGRITY object are used. two terms RSVP INTEGRITY and POLICY_DATA INTEGRITY object are used.
The data structure of the two objects however is the same. The data structure of the two objects however is the same.
3 Overview - Hop vs. Peer
Tschofenig Informational - Expires April 2003 4 In the past there was considerable discussion about the terminology
RSVP Security Properties October 2002 of a nodes that are addressed by RSVP. In particular two favorites
have used: hop and peer. This document uses the term hop which is
different to an IP hop. Two neighboring RSVP nodes communicating with
each other are not necessarily neighboring IP nodes (i.e. one IP hop
away).
3 Overview
3.1 The RSVP INTEGRITY Object 3.1 The RSVP INTEGRITY Object
The RSVP INTEGRITY object is the major component of the RSVP security The RSVP INTEGRITY object is the major component of the RSVP security
protection. This object is used to provide integrity and replay protection. This object is used to provide integrity and replay
protect the content of the signaling message between two RSVP protect the content of the signaling message between two RSVP
participating router. Furthermore the RSVP INTEGRITY object provides participating router. Furthermore the RSVP INTEGRITY object provides
data origin authentication. The attributes of the object are briefly data origin authentication. The attributes of the object are briefly
described: described:
skipping to change at line 232 skipping to change at line 248
this field as a combination of an address, the sending interface and this field as a combination of an address, the sending interface and
a key number. We assume that the Key Identifier is simply a (keyed) a key number. We assume that the Key Identifier is simply a (keyed)
hash value computed over a number of fields with the requirement to hash value computed over a number of fields with the requirement to
be unique if more than one security association is used in parallel be unique if more than one security association is used in parallel
between two hosts (i.e. as it is the case with security association between two hosts (i.e. as it is the case with security association
that have overlapping lifetimes). A receiving system uniquely that have overlapping lifetimes). A receiving system uniquely
identifies a security association based on the Key Identifier and the 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 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 or from the source IP address of the packet if the
RSVP_HOP object is not present. The sender uses the outgoing RSVP_HOP object is not present. The sender uses the outgoing
Tschofenig Informational - Expires September 2003 5
RSVP Security Properties March 2003
interface to determine which security association to use. The term interface to determine which security association to use. The term
outgoing interface might be confusing. The sender selects the outgoing interface might be confusing. The sender selects the
security association based on the receiver's IP address (of the next security association based on the receiver's IP address (of the next
RSVP capable router). To determine which node is the next capable RSVP capable router). To determine which node is the next capable
RSVP router is not further specified and is likely to be statically RSVP router is not further specified and is likely to be statically
configured. configured.
- Sequence Number - Sequence Number
The sequence number used by the INTEGRITY object is 64-bits in length The sequence number used by the INTEGRITY object is 64-bits in length
and the starting value can be selected arbitrarily. The length of the and the starting value can be selected arbitrarily. The length of the
sequence number field was chosen to avoid exhaustion during the sequence number field was chosen to avoid exhaustion during the
lifetime of a security association as stated in Section 3 of lifetime of a security association as stated in Section 3 of
[RFC2747]. In order for the receiver to distinguish between a new and [RFC2747]. In order for the receiver to distinguish between a new and
a replayed sequence number each value must be monotonically a replayed sequence number each value must be monotonically
increasing modulo 2^64. We assume that the first sequence number seen increasing modulo 2^64. We assume that the first sequence number seen
(i.e. the starting sequence number) is stored somewhere. The modulo- (i.e. the starting sequence number) is stored somewhere. The modulo-
Tschofenig Informational - Expires April 2003 5
RSVP Security Properties October 2002
operation is required because the starting sequence number may be an operation is required because the starting sequence number may be an
arbitrary number. The receiver therefore only accepts packets with a arbitrary number. The receiver therefore only accepts packets with a
sequence number larger (modulo 2^64) than the previous packet. As sequence number larger (modulo 2^64) than the previous packet. As
explained in [RFC2747] this process is started by handshaking and explained in [RFC2747] this process is started by handshaking and
agreeing on an initial sequence number. If no such handshaking is agreeing on an initial sequence number. If no such handshaking is
available then the initial sequence number must be part of the available then the initial sequence number must be part of the
establishment of the security association. establishment of the security association.
The generation and storage of sequence numbers is an important step The generation and storage of sequence numbers is an important step
in preventing replay attacks and is largely determined by the in preventing replay attacks and is largely determined by the
skipping to change at line 287 skipping to change at line 303
noted in Section 1 of [RFC2747]. Hash algorithms other than MD5 noted in Section 1 of [RFC2747]. Hash algorithms other than MD5
[RFC1321] like SHA [SHA] may also be supported. [RFC1321] like SHA [SHA] may also be supported.
The key used for computing this Keyed Message Digest may be obtained The key used for computing this Keyed Message Digest may be obtained
from the pre-shared secret which is either manually distributed or from the pre-shared secret which is either manually distributed or
the result of a key management protocol. No key management protocol, the result of a key management protocol. No key management protocol,
however, is specified to create the desired security associations. however, is specified to create the desired security associations.
3.2 Security Associations 3.2 Security Associations
Tschofenig Informational - Expires September 2003 6
RSVP Security Properties March 2003
Different attributes are stored for security associations of sending Different attributes are stored for security associations of sending
and receiving systems (i.e. unidirectional security associations). and receiving systems (i.e. unidirectional security associations).
The sending system needs to maintain the following attributes in such The sending system needs to maintain the following attributes in such
a security association [RFC2747]: a security association [RFC2747]:
- Authentication algorithm and algorithm mode - Authentication algorithm and algorithm mode
- Key - Key
- Key Lifetime - Key Lifetime
- Sending Interface - Sending Interface
- Latest sequence number (sent with this key identifier) - Latest sequence number (sent with this key identifier)
The receiving system has to store the following fields: The receiving system has to store the following fields:
- Authentication algorithm and algorithm mode - Authentication algorithm and algorithm mode
- Key - Key
- Key Lifetime - Key Lifetime
- Source address of the sending system - Source address of the sending system
- List of last n sequence numbers (received with this key identifier) - List of last n sequence numbers (received with this key identifier)
Tschofenig Informational - Expires April 2003 6
RSVP Security Properties October 2002
Note that the security associations need to have additional fields to Note that the security associations need to have additional fields to
indicate their state. It is necessary to have an overlapping lifetime indicate their state. It is necessary to have an overlapping lifetime
of security associations to avoid interrupting an ongoing of security associations to avoid interrupting an ongoing
communication because of expired security associations. During such a communication because of expired security associations. During such a
period of overlapping lifetime it is necessary to authenticate either period of overlapping lifetime it is necessary to authenticate either
one or both active keys. As mentioned in [RFC2747] a sender and a one or both active keys. As mentioned in [RFC2747] a sender and a
receiver might have multiple active keys simultaneously. receiver might have multiple active keys simultaneously.
If more than one algorithm is supported then the algorithm used must If more than one algorithm is supported then the algorithm used must
be specified for a security association. be specified for a security association.
3.3 RSVP Key Management Assumptions 3.3 RSVP Key Management Assumptions
[RFC2205] assumes that security associations are already available. [RFC2205] assumes that security associations are already available.
Manual key distribution must be provided by an implementation as Manual key distribution must be provided by an implementation as
noted in Section 5.2 of [RFC2747]. Manual key distribution however noted in Section 5.2 of [RFC2747]. Manual key distribution however
has different requirements to a key storage ű a simple plaintext has different requirements to a key storage ľ a simple plaintext
ASCII file may be sufficient in some cases. If multiple security ASCII file may be sufficient in some cases. If multiple security
associations with different lifetimes should be supported at the same associations with different lifetimes should be supported at the same
time then a key engine, for example PF_KEY [RFC2367], would be more time then a key engine, for example PF_KEY [RFC2367], would be more
appropriate. Further security requirements listed in Section 5.2 of appropriate. Further security requirements listed in Section 5.2 of
[RFC2747] are the following: [RFC2747] are the following:
- The manual deletion of security associations must be supported. - The manual deletion of security associations must be supported.
- The key storage should persist a system restart. - The key storage should persist a system restart.
- Each key must be assigned a specific lifetime and a specific Key - Each key must be assigned a specific lifetime and a specific Key
Identifier. Identifier.
3.4 Identity Representation 3.4 Identity Representation
In addition to host-based authentication with the INTEGRITY object In addition to host-based authentication with the INTEGRITY object
inside the RSVP message user-based authentication is available as inside the RSVP message user-based authentication is available as
introduced with [RFC2750]. Section 2 of [RFC3182] stated that introduced with [RFC2750]. Section 2 of [RFC3182] stated that
˘Providing policy based admission control mechanism based on user "Providing policy based admission control mechanism based on user
identities or application is one of the prime requirements.÷ To
Tschofenig Informational - Expires September 2003 7
RSVP Security Properties March 2003
identities or application is one of the prime requirements." To
identify the user or the application, a policy element called identify the user or the application, a policy element called
AUTH_DATA, which is contained in the POLICY_DATA object, is created 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 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 message. The structure of the POLICY_DATA element is described in
[RFC2750]. Network nodes like the PDP then use the information [RFC2750]. Network nodes like the PDP then use the information
contained in the AUTH_DATA element to authenticate the user and to contained in the AUTH_DATA element to authenticate the user and to
allow policy-based admission control to be executed. As mentioned in allow policy-based admission control to be executed. As mentioned in
[RFC3182] the policy element is processed and the policy decision [RFC3182] the policy element is processed and the policy decision
point replaces the old element with a new one for forwarding to the point replaces the old element with a new one for forwarding to the
next hop router. next hop router.
A detailed description of the POLICY_DATA element can be found in A detailed description of the POLICY_DATA element can be found in
[RFC2750]. The attributes contained in the authentication data policy [RFC2750]. The attributes contained in the authentication data policy
element AUTH_DATA, which is defined in [RFC3182], are briefly element AUTH_DATA, which is defined in [RFC3182], are briefly
explained in this Section. Figure 1 shows the abstract structure of explained in this Section. Figure 1 shows the abstract structure of
the RSVP message with its security relevant objects and the scope of the RSVP message with its security relevant objects and the scope of
protection. The RSVP INTEGRITY object (outer object) covers the protection. The RSVP INTEGRITY object (outer object) covers the
Tschofenig Informational - Expires April 2003 7
RSVP Security Properties October 2002
entire RSVP message whereas the POLICY_DATA INTEGRITY object only entire RSVP message whereas the POLICY_DATA INTEGRITY object only
covers objects within the POLICY_DATA element. covers objects within the POLICY_DATA element.
+--------------------------------------------------------+ +--------------------------------------------------------+
| RSVP Message | | RSVP Message |
+--------------------------------------------------------+ +--------------------------------------------------------+
| INTEGRITY +-------------------------------------------+| | INTEGRITY +-------------------------------------------+|
| Object |POLICY_DATA Object || | Object |POLICY_DATA Object ||
| +-------------------------------------------+| | +-------------------------------------------+|
| | INTEGRITY +------------------------------+|| | | INTEGRITY +------------------------------+||
skipping to change at line 398 skipping to change at line 414
noted in Section 6.1 of [RFC3182] an RSVP may contain more than one noted in Section 6.1 of [RFC3182] an RSVP may contain more than one
POLICY_DATA object and each of them may contain more than one POLICY_DATA object and each of them may contain more than one
AUTH_DATA object. As indicated in the Figure above and in [RFC3182] AUTH_DATA object. As indicated in the Figure above and in [RFC3182]
one AUTH_DATA object contains more than one authentication attribute. one AUTH_DATA object contains more than one authentication attribute.
A typical configuration for a Kerberos-based user authentication A typical configuration for a Kerberos-based user authentication
includes at least the Policy Locator and an attribute containing the includes at least the Policy Locator and an attribute containing the
Kerberos session ticket. Kerberos session ticket.
A successful user authentication is the basis for doing policy-based A successful user authentication is the basis for doing policy-based
admission control. Additionally other information such as time-of- admission control. Additionally other information such as time-of-
Tschofenig Informational - Expires September 2003 8
RSVP Security Properties March 2003
day, application type, location information, group membership etc. day, application type, location information, group membership etc.
may be relevant for a policy. may be relevant for a policy.
The following attributes are defined for the usage in the AUTH_DATA The following attributes are defined for the usage in the AUTH_DATA
object: object:
a) Policy Locator a) Policy Locator
The policy locator string that is a X.500 distinguished name (DN) The policy locator string that is a X.500 distinguished name (DN)
used to locate the user and/or application specific policy used to locate the user and/or application specific policy
information. The following types of X.500 DNs are listed: 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
Tschofenig Informational - Expires April 2003 8
RSVP Security Properties October 2002
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 certificate
(i.e. digitally signed). The term encrypted together with a digital (i.e. digitally signed). The term encrypted together with a digital
signature is easy to misconceive. If user identity confidentiality signature is easy to misconceive. If user identity confidentiality
shall be provided then the policy locator has to be encrypted with shall be provided then the policy locator has to be encrypted with
the public key of the recipient. How to obtain this public key is not the public key of the recipient. How to obtain this public key is not
described in the document. Such an issue may be specified in a described in the document. Such an issue may be specified in a
concrete architecture where RSVP is used. 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:
skipping to change at line 454 skipping to change at line 471
| UNICODE_ID | User or application identity | | UNICODE_ID | User or application identity |
| | encoded as an Unicode string | | | encoded as an 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 |
+--------------+--------------------------------+ +--------------+--------------------------------+
Tschofenig Informational - Expires September 2003 9
RSVP Security Properties March 2003
Table 1: Credentials Supported in RSVP Table 1: Credentials Supported in RSVP
The first two credentials only contain a plaintext string and The first two credentials only contain 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 and/or the INTEGRITY object of the POLICY_DATA element is INTEGRITY and/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 ignorant
nodes are used in between. nodes are used in between.
Tschofenig Informational - Expires April 2003 9
RSVP Security Properties October 2002
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 a
server. The INTEGRITY object (e.g. of the POLICY_DATA element) 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
replay protection and shows that the user was able to retrieve the replay protection and shows that the user was able to retrieve the
session key following the Kerberos protocol. This is, however, only session key following the Kerberos protocol. This is, however, only
the case if the Kerberos session was used for the keyed message the case if the Kerberos session was used for the keyed message
digest field of the INTEGRITY object. Section 7 of [RFC2747] digest field of the INTEGRITY object. Section 7 of [RFC2747]
discusses some issues for establishment of keys for the INTEGRITY discusses some issues for establishment of keys for the INTEGRITY
skipping to change at line 507 skipping to change at line 524
transmit an Integrity Challenge message to force the sender to re- transmit an Integrity Challenge message to force the sender to re-
transmit a new service ticket. 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
the replay protection (either timestamps or sequence numbers) is the replay protection (either timestamps or sequence numbers) is
Tschofenig Informational - Expires September 2003 10
RSVP Security Properties March 2003
provided by the digital signature is an open issue as discussed in provided by the digital signature is an open issue as discussed in
Section 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 digital
signature depends on the authentication mode listed in the signature depends on the authentication mode listed in the
credential. This is only partially true since for example PGP again credential. This is only partially true since for example PGP again
allows different algorithms to be used for computing a digital allows different algorithms to be used for computing a digital
signature. The algorithm used for computing the digital signature is signature. The algorithm used for computing the digital signature is
not included in the certificate itself. The algorithm identifier not included in the certificate itself. The algorithm identifier
included in the certificate only serves the purpose to allow the included in the certificate only serves the purpose to allow the
verification of the signature computed by the certificate authority verification of the signature computed by the certificate authority
(except for the case of self-signed certificates). (except for the case of self-signed certificates).
d) Policy Error Object d) Policy Error Object
Tschofenig Informational - Expires April 2003 10
RSVP Security Properties October 2002
The Policy Error Object is used in the case of a failure of the The Policy Error Object is used in the case of a failure of the
policy based admission control or other credential verification. policy based admission control or other credential verification.
Currently available error messages allow to notify if the credentials Currently available error messages allow to notify if the credentials
are expired (EXPIRED_CREDENTIALS), if the authorization process are expired (EXPIRED_CREDENTIALS), if the authorization process
disallowed the resource request (INSUFFICIENT_PRIVILEGES) and if the disallowed the resource request (INSUFFICIENT_PRIVILEGES) and if the
given set of credentials is not supported given set of credentials is not supported
(UNSUPPORTED_CREDENTIAL_TYPE). The last error message allows the (UNSUPPORTED_CREDENTIAL_TYPE). The last error message allows the
user's host to discover the type of credentials supported although by user's host to discover the type of credentials supported although by
very inefficient means. Furthermore it is unlikely that a user very inefficient means. Furthermore it is unlikely that a user
supports different types of credentials. The purpose of the error supports different types of credentials. The purpose of the error
skipping to change at line 562 skipping to change at line 580
attacker may find it difficult to inject old messages since new attacker may find it difficult to inject old messages since new
authenticated packets with high sequence numbers arrive and get authenticated packets with high sequence numbers arrive and get
stored immediately. stored immediately.
The following description explains the details of the RSVP Integrity The following description explains the details of the 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
Tschofenig Informational - Expires September 2003 11
RSVP Security Properties March 2003
+----------+ 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 described below: The details of the messages are described below:
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)
Tschofenig Informational - Expires April 2003 11 The "Challenge Cookie" is suggested to be a MD5 hash of a local
RSVP Security Properties October 2002
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 show in the protocol flow above. As explained in Section 10 object as show in the protocol flow above. As explained in Section 10
of [RFC2747] this was done to avoid problems in situations where both of [RFC2747] this was done to avoid problems in situations where both
communication parties do not have a valid starting sequence number. communication parties do not have a valid starting sequence number.
Whether or not to use the RSVP Integrity Challenge/Response mechanism Whether or not to use the RSVP Integrity Challenge/Response mechanism
is a site-local decision since it may not be needed in all network is a site-local decision since it may not be needed in all network
environments. It is however recommended to use the RSVP Integrity environments. It is however recommended to use the RSVP Integrity
skipping to change at line 616 skipping to change at line 635
that there is only a very single domain and that two routers are RSVP that there is only a very single domain and that two routers are RSVP
and policy aware. These assumptions are relaxed in the individual and policy aware. These assumptions are relaxed in the individual
paragraphs as necessary. Layer 2 devices between the clients and paragraphs as necessary. Layer 2 devices between the clients and
their corresponding first hop routers are not shown. Other network their corresponding first hop routers are not shown. Other network
elements like a Kerberos Key Distribution Center and for example an elements like a Kerberos Key Distribution Center and for example an
LDAP server where the PDP retrieves his policies are also omitted. LDAP server where the PDP retrieves his policies are also omitted.
The security of various interfaces to the individual servers (KDC, The security of various interfaces to the individual servers (KDC,
PDP, etc.) depends very much on the security policy of a specific PDP, etc.) depends very much on the security policy of a specific
network service provider. network service provider.
Tschofenig Informational - Expires September 2003 12
RSVP Security Properties March 2003
+--------+ +--------+
|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
Tschofenig Informational - Expires April 2003 12
RSVP Security Properties October 2002
When talking about authentication in RSVP it is very important to When talking about authentication in RSVP it is very important to
make a distinction between user and host authentication of the make a distinction between user and host authentication of the
signaling messages. By using the RSVP INTEGRITY object the host is signaling messages. By using the RSVP INTEGRITY object the host is
authenticated while credentials inside the AUTH_DATA object can be authenticated while credentials inside the AUTH_DATA object can be
used to authenticate the user. In this Section the focus is on host used to authenticate the user. In this Section the focus is on host
authentication whereas the next Section covers user authentication. authentication whereas the next Section covers user authentication.
a) Authentication a) Authentication
We use the term host authentication above since the selection of the We use the term host authentication above since the selection of the
security association is bound to the hostĂs IP address as mentioned security association is bound to the hostĺs IP address as mentioned
in Section 3.1 and 3.2. Depending on the key management protocol used in Section 3.1 and 3.2. Depending on the key management protocol used
to create this security association and the identity used it is also to create this security association and the identity used it is also
possible to bind a user identity to this security association. Since possible to bind a user identity to this security association. Since
the key management protocol is not specified it is difficult to the key management protocol is not specified it is difficult to
evaluate this part and hence we speak about data origin evaluate this part and hence we speak about data origin
authentication based on the hostĂs identity for RSVP INTEGRITY authentication based on the hostĺs identity for RSVP INTEGRITY
objects. The fact that the host identity is used for selecting the objects. The fact that the host identity is used for selecting the
security association has already been described in Section 3.1. security association has already been described in Section 3.1.
Data origin authentication is provided with the keyed hash value Data origin authentication is provided with the keyed hash value
computed over the entire RSVP message excluding the keyed message computed over the entire RSVP message excluding the keyed message
digest field itself. The security association used between the userĂs digest field itself. The security association used between the userĺs
host and the first-hop router is, as previously mentioned, not host and the first-hop router is, as previously mentioned, not
established by RSVP and must therefore be available before the established by RSVP and must therefore be available before the
signaling is started. Although not mentioned in [RFC2747] it is also signaling is started.
possible to use IPSec [RFC2401] to protect the RSVP signaling traffic
from the client to the first-hop router. If we use IPSec to protect
the interface between the userĂs host and the first hop router then
the optional RSVP INTEGRITY object may not be required. It may also
be possible (which requires a further investigation) whether an
existing IPSec security association may also be (re-)used for RSVP.
IPSec allows the key exchange protocol IKE [RFC2409] to be used to
dynamically negotiate IPSec security associations. Note that KINK
[FH+01] and other protocols are available that are also able to
establish an IPSec security association. This text mainly refers to
IKE since it is the most frequently used protocol for this purpose. A
detailed description of IPSec and IKE is outside the scope of this
document. Since IKE is computationally expensive it might create a
computational burden to re-establish a new IPSec SA based of the
movement of a mobile user host. Work at the SEAMOBY group tries to
tackle this problem by using IPSec Context Transfer protocols. Hence
in this case we would avoid triggering a separate key exchange
protocol run for RSVP to protect messages at each layer if they
terminate at the same node.
It is an open issue whether it is enough to provide IPSec protection Although not mentioned in [RFC2747] it is also possible to use IPsec
of messages between the userĂs host and the first-hop router although [RFC2401] to protect the RSVP signaling traffic from the client to
the first-hop router. Note that IPsec usage for RSVP signaling
protocol requires preconditions which are described in Section 5.6.
If we use IPsec to protect the interface between the userĺs host and
the first hop router then the optional RSVP INTEGRITY object may not
be required. It may also be possible (which requires a further
investigation) whether an existing IPsec security association may
also be (re-)used for RSVP. IPsec allows the key exchange protocol
Tschofenig Informational - Expires September 2003 13
RSVP Security Properties March 2003
IKE [RFC2409] to be used to dynamically negotiate IPsec security
associations. Note that KINK [FH+01] and other protocols are
available that are also able to establish an IPsec security
association. This text mainly refers to IKE since it is the most
frequently used protocol for this purpose. A detailed description of
IPsec and IKE is outside the scope of this document. Since IKE is
computationally expensive it might create a computational burden to
re-establish a new IPsec SA based of the movement of a mobile user
host. Work at the SEAMOBY group tries to tackle this problem by using
IPsec Context Transfer protocols. Hence in this case we would avoid
triggering a separate key exchange protocol run for RSVP to protect
messages at each layer if they terminate at the same node.
It is an open issue whether it is enough to provide IPsec protection
of messages between the userĺs host and the first-hop router although
different protocols (i.e. protocols executed at different protocol different protocols (i.e. protocols executed at different protocol
layers) (possibly) terminate at different endpoints. layers) (possibly) terminate at different endpoints.
- Kerberos for the RSVP INTEGRITY object - Kerberos for the RSVP INTEGRITY object
Tschofenig Informational - Expires April 2003 13
RSVP Security Properties October 2002
As described in Section 7 of [RFC2747] Kerberos may be used to create As described in Section 7 of [RFC2747] Kerberos may be used to create
the key for the RSVP INTEGRITY object. How to learn the principal the key for the RSVP INTEGRITY object. How to learn the principal
name (and realm information) of the other node is outside the scope name (and realm information) of the other node is outside the scope
of [RFC2747]. Section 4.2.1 of [RFC2747] states that the required of [RFC2747]. Section 4.2.1 of [RFC2747] states that the required
identities can be obtained statically or dynamically via a directory identities can be obtained statically or dynamically via a directory
service or DHCP. [HA01] describes a way to distribute principal and service or DHCP. [HA01] describes a way to distribute principal and
realm information via DNS which can be used for this purpose realm information via DNS which can be used for this purpose
(assuming that the FQDN or the IP address of the other node is known (assuming that the FQDN or the IP address of the other node is known
for which this information is desired). It is only required to for which this information is desired). It is only required to
encapsulate the Kerberos ticket inside the policy element. It is encapsulate the Kerberos ticket inside the policy element. It is
skipping to change at line 723 skipping to change at line 746
An additional protocol needs to be executed after each user is An additional protocol needs to be executed after each user is
authenticated via Kerberos to establish a session key and to allow authenticated via Kerberos to establish a session key and to allow
multicast specific functionality like entering a group, leaving a multicast specific functionality like entering a group, leaving a
group to be executed securely. This would additionally allow group to be executed securely. This would additionally allow
accounting and billing to be used efficiently and on a per-user accounting and billing to be used efficiently and on a per-user
basis. This session key is then used to protect RSVP signaling basis. This session key is then used to protect RSVP signaling
messages. These issues definitely need further investigation and are messages. These issues definitely need further investigation and are
not fully described in this version of the document. not fully described in this version of the document.
Tschofenig Informational - Expires September 2003 14
RSVP Security Properties March 2003
In case that one entity crashed the established security association In case that one entity crashed the established security association
is lost and therefore the other node must retransmit the service is lost and therefore the other node must retransmit the service
ticket. The crashed entity can use an Integrity Challenge message to ticket. The crashed entity can use an Integrity Challenge message to
request a new Kerberos ticket to be retransmitted by the other node. 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 If a node receives such a request then a reply message must be
returned. returned.
b) Integrity Protection b) Integrity Protection
Integrity protection between the userĂs host and the first hop router Integrity protection between the userĺs host and the first hop router
is based on the RSVP INTEGRITY object. Since the RSVP Integrity is based on the RSVP INTEGRITY object. Since the RSVP Integrity
object is an optional element of the RSVP message IPSec protection of object is an optional element of the RSVP message IPsec protection of
the signaling message to the router may also provide integrity the signaling message to the router may also provide integrity
protection either with IPSec AH [RFC2402] or IPSec ESP [RFC2406] as protection either with IPsec AH [RFC2402] or IPsec ESP [RFC2406] as
mentioned already in the previous paragraph. mentioned already in the previous paragraph.
Furthermore it is stated that other keyed hash functions apart from Furthermore it is stated that other keyed hash functions apart from
HMAC-MD5 may be used within the RSVP INTEGRITY object and it is HMAC-MD5 may be used within the RSVP INTEGRITY object and it is
obvious that both communicating entities must have security obvious that both communicating entities must have security
Tschofenig Informational - Expires April 2003 14
RSVP Security Properties October 2002
associations indicating the algorithm used. This may be however associations indicating the algorithm used. This may be however
difficult since there is no negotiation protocol defined to agree on difficult since there is no negotiation protocol defined to agree on
a specific algorithm. Hence it is very likely that HMAC-MD5 is the a specific algorithm. Hence it is very likely that HMAC-MD5 is the
only usable algorithm for the RSVP INTEGRITY object if RSVP is used only usable algorithm for the RSVP INTEGRITY object if RSVP is used
in a mobile environment and only in local environments it may be in a mobile environment and only in local environments it may be
useful to switch to a different keyed hash algorithm. The other useful to switch to a different keyed hash algorithm. The other
possible alternative is that every implementation must support the possible alternative is that every implementation must support the
most important keyed hash algorithms for example MD5, SHA-1, RIPEMD- most important keyed hash algorithms for example MD5, SHA-1, RIPEMD-
160 etc. HMAC-MD5 was mainly chosen because of the performance 160 etc. HMAC-MD5 was mainly chosen because of the performance
characteristics. The weaknesses of MD5 [DBP96] are known and characteristics. The weaknesses of MD5 [DBP96] are known and
skipping to change at line 772 skipping to change at line 794
numbers whereby the sequence number is included in the RSVP INTEGRITY numbers whereby the sequence number is included in the RSVP INTEGRITY
object. The properties of this sequence number mechanisms are object. The properties of this sequence number mechanisms are
described in Section 3.1. The fact that the receiver stores a list of 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 sequence numbers is an indicator for a window mechanism. This somehow
conflicts with the requirement that the receiver only has to store conflicts with the requirement that the receiver only has to store
the highest number given in Section 3 of [RFC2747]. We assume that 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 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 the out-of-order delivery and the ability of an implementation to
specify the replay window. specify the replay window.
If IPSec is used to protect RSVP messages then the optional IPSec If IPsec is used to protect RSVP messages then the optional IPsec
replay protection mechanism may be used which is also based on replay protection mechanism may be used which is also based on
sequence numbers with a window mechanism. This window mechanism may sequence numbers with a window mechanism. This window mechanism may
(theoretically) also cause problems whereby an adversary reorders (theoretically) also cause problems whereby an adversary reorders
messages. This is however very difficult to exploit since the messages. This is however very difficult to exploit since the
signaling messages are exchanged at a relatively low rate compared to signaling messages are exchanged at a relatively low rate compared to
regular data traffic that may also be protected with IPSec. regular data traffic that may also be protected with IPsec.
Tschofenig Informational - Expires September 2003 15
RSVP Security Properties March 2003
- Integrity Handshake - Integrity Handshake
The mechanism of the Integrity Handshake is explained in Section 3.5. The mechanism of the Integrity Handshake is explained in Section 3.5.
The Cookie value is suggested to be hash of a local secret and a 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 timestamp. The Cookie value is not verified by the receiver. The
mechanism used by the Integrity Handshake is a simple mechanism used by the Integrity Handshake is a simple
Challenge/Response message which assumes that the key shared between Challenge/Response message which assumes that the key shared between
the two hosts survives the crash. If the security association is the two hosts survives the crash. If the security association is
however dynamically created then this assumption may not be true. however dynamically created then this assumption may not be true.
In Section 10 of [RFC2747] the authors note that an adversary can In Section 10 of [RFC2747] the authors note that an adversary can
create faked Integrity Handshake message including challenge cookies. create faked Integrity Handshake message including challenge cookies.
Subsequently he would store the received response. Later he tries to Subsequently he would store the received response. Later he tries to
replay these responses while a responder recovers from a crash or replay these responses while a responder recovers from a crash or
restart. If this replayed Integrity Response value is valid and has a restart. If this replayed Integrity Response value is valid and has a
lower sequence number than actually used then this value is stored at lower sequence number than actually used then this value is stored at
the recovering host. In order for this attack to be successful the the recovering host. In order for this attack to be successful the
adversary must either have collected a large number of adversary must either have collected a large number of
challenge/response value pairs or the adversary "discovered" the
Tschofenig Informational - Expires April 2003 15
RSVP Security Properties October 2002
challenge/response value pairs or the adversary ˘discovered÷ the
cookie generation mechanism (for example by knowing the local cookie generation mechanism (for example by knowing the local
secret). The collection of Challenge/Response pairs is even more secret). The collection of Challenge/Response pairs is even more
difficult since they depend on the Cookie value, on sequence number difficult since they depend on the Cookie value, on sequence number
included in the response message and on the shared key which is used included in the response message and on the shared key which is used
by the INTEGRITY object. by the INTEGRITY object.
d) Confidentiality d) Confidentiality
Confidentiality is not considered to be a security requirement for Confidentiality is not considered to be a security requirement for
RSVP. Hence it is not directly supported by RSVP. However, IPSec can RSVP. Hence it is not directly supported by RSVP. However, IPsec can
provide confidentiality by encrypting the transmitted signaling provide confidentiality by encrypting the transmitted signaling
traffic with IPSec ESP. traffic with IPsec ESP.
e) Authorization e) Authorization
The task of authorization consists of two subcategories: Network The task of authorization consists of two subcategories: Network
access authorization and RSVP request authorization. Access access authorization and RSVP request authorization. Access
authorization is provided when a node is authenticated to the network authorization is provided when a node is authenticated to the network
e.g. via AAA protocols (for example using RADIUS [RFC2865] or e.g. via AAA protocols (for example using RADIUS [RFC2865] or
DIAMETER [CA+02]) and authorization information is downloaded to one DIAMETER [CA+02]) and authorization information is downloaded to one
or more network elements for example to the access router/first hop or more network elements for example to the access router/first hop
router to modify filter rules to enable the IP traffic forwarding. router to modify filter rules to enable the IP traffic forwarding.
The access router is therefore acting as a firewall with dynamically The access router is therefore acting as a firewall with dynamically
created filter rules based on a successful host or user created filter rules based on a successful host or user
authentication. Issues related to network access authorization are authentication. Issues related to network access authorization are
outside the scope of RSVP. outside the scope of RSVP.
The second authorization refers to RSVP itself. Depending on the The second authorization refers to RSVP itself. Depending on the
network configuration network configuration
- the router either forwards the received RSVP request to the policy - the router either forwards the received RSVP request to the policy
decision point e.g. by using COPS (see [RFC2748] and [RFC2749]) and decision point e.g. by using COPS (see [RFC2748] and [RFC2749]) and
to request admission control procedure to be executed or to request admission control procedure to be executed or
Tschofenig Informational - Expires September 2003 16
RSVP Security Properties March 2003
- the router supports the functionality of a PDP and therefore there - the router supports the functionality of a PDP and therefore there
is no need to forward the request or is no need to forward the request or
- the router may already be configured with the appropriate policy - the router may already be configured with the appropriate policy
information to decide locally whether to grant this request or not. information to decide locally whether to grant this request or not.
Based on the result of the admission control the request may be Based on the result of the admission control the request may be
granted or rejected. Without a policy element being embedded inside granted or rejected. Without a policy element being embedded inside
the RSVP message no policy-based admission control can be done. the RSVP message no policy-based admission control can be done.
The interaction between the two access authorization procedures (and The interaction between the two access authorization procedures (and
the filter-installation at the various network devices) will likely the filter-installation at the various network devices) will likely
be investigated in more detail in the MIDCOM working group. be investigated in more detail in the MIDCOM working group.
f) Performance f) Performance
The computation of the keyed message digest for a RSVP INTEGRITY The computation of the keyed message digest for a RSVP INTEGRITY
object does not represent a performance problem. The same is true for object does not represent a performance problem. The same is true for
IPSec AH (or IPSec ESP). The protection of signaling messages is IPsec AH (or IPsec ESP). The protection of signaling messages is
usually not a problem since these messages are transmitted at a low usually not a problem since these messages are transmitted at a low
Tschofenig Informational - Expires April 2003 16
RSVP Security Properties October 2002
rate. Even a high number of messages does not cause performance rate. Even a high number of messages does not cause performance
problems for a RSVP routers because of the characteristics of the problems for a RSVP routers because of the efficiency of the keyed
keyed message digest routine. message digest routine.
The key management which is computationally more demanding is more The key management which is computationally more demanding is more
important for scalability. Since RSVP does not specify a particular important for scalability. Since RSVP does not specify a particular
key exchange protocol to be used it is difficult to estimate the key exchange protocol to be used it is difficult to estimate the
effort to create the required security associations. Furthermore the effort to create the required security associations. Furthermore the
number of key exchanges to be triggered depends on security policy number of key exchanges to be triggered depends on security policy
issues like lifetime of a security association, required security issues like lifetime of a security association, required security
properties of the key exchange protocol, authentication mode used by properties of the key exchange protocol, authentication mode used by
the key exchange protocol etc. In a stationary environment with a the key exchange protocol etc. In a stationary environment with a
single administrative domain the manual security association single administrative domain the manual security association
skipping to change at line 890 skipping to change at line 911
authenticate to the first hop router or to the PDP as specified in authenticate to the first hop router or to the PDP as specified in
[RFC2747] depending on the infrastructure provided by the network [RFC2747] depending on the infrastructure provided by the network
domain or on the architecture used (e.g. the integration of RSVP and domain or on the architecture used (e.g. the integration of RSVP and
Kerberos V5 into the Windows 2000 Operating System [MADS01]). Another Kerberos V5 into the Windows 2000 Operating System [MADS01]). Another
architecture where RSVP is tightly integrated is the one specified by architecture where RSVP is tightly integrated is the one specified by
the PacketCable organization. The interested reader is referred to the PacketCable organization. The interested reader is referred to
[PKTSEC] for a discussion of the security architecture. [PKTSEC] for a discussion of the security architecture.
a) Authentication a) Authentication
Tschofenig Informational - Expires September 2003 17
RSVP Security Properties March 2003
When a user sends a RSVP PATH or RESV message then this message may When a user sends a RSVP PATH or RESV message then this message may
include some information to authenticate the user. [RFC3182] include some information to authenticate the user. [RFC3182]
describes how user and application information is embedded into the describes how user and application information is embedded into the
RSVP message (AUTH_DATA object) and how to protect it. A router RSVP message (AUTH_DATA object) and how to protect it. A router
receiving such a message can use this information to authenticate the receiving such a message can use this information to authenticate the
client and forward the user/application information to the policy client and forward the user/application information to the policy
decision point (PDP). Optionally the PDP itself can authenticate the decision point (PDP). Optionally the PDP itself can authenticate the
user, which is described in the next section. In order to be able to user, which is described in the next section. In order to be able to
authenticate the user, to verify the integrity and to check for authenticate the user, to verify the integrity and to check for
replays the entire POLICY_DATA element has to be forwarded from the 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. router to the PDP e.g. by including the element into a COPS message.
It is assumed that the INTEGRITY object within the POLICY_DATA It is assumed that the INTEGRITY object within the POLICY_DATA
element is sent to the PDP along with all other attributes although element is sent to the PDP along with all other attributes although
not clearly specified in [RFC3182]. not clearly specified in [RFC3182].
Certificate Verification Certificate Verification
Using the policy element as described in [RFC3182] it is not possible Using the policy element as described in [RFC3182] it is not possible
to provide a certificate revocation list or other information to to provide a certificate revocation list or other information to
proof the validity of the certificate inside the policy element. A proof the validity of the certificate inside the policy element. A
Tschofenig Informational - Expires April 2003 17
RSVP Security Properties October 2002
specific mechanism for certificate verification is not discussed in specific mechanism for certificate verification is not discussed in
[RFC3182] and hence a number of them can be used for this purpose. [RFC3182] and hence a number of them can be used for this purpose.
For certificate verification the network element (a router or the For certificate verification the network element (a router or the
policy decision point), which has to authenticate the user, could policy decision point), which has to authenticate the user, could
frequently download certificate revocation lists or should use a frequently download certificate revocation lists or should use a
protocol like the Online Certificate Status Protocol (OCSP) [RFC2560] protocol like the Online Certificate Status Protocol (OCSP) [RFC2560]
and the Simple Certificate Validation Protocol (SCVP) [MHHF01] to and the Simple Certificate Validation Protocol (SCVP) [MHHF01] to
determine the current status of a digital certificate. determine the current status of a digital certificate.
User Authentication to the PDP User Authentication to the PDP
skipping to change at line 945 skipping to change at line 965
If Kerberos is used to authenticate the user then first a session If Kerberos is used to authenticate the user then first a session
ticket for the PDP needs to be requested. If the user roams between ticket for the PDP needs to be requested. If the user roams between
different routers in the same administrative domain then he does not different routers in the same administrative domain then he does not
need to request a new service ticket since the PDP is likely to be need to request a new service ticket since the PDP is likely to be
used by most or all first-hop routers within the same administrative used by most or all first-hop routers within the same administrative
domain. This is different if a session ticket for a router has to be domain. This is different if a session ticket for a router has to be
obtained and authentication to a router is required. The router obtained and authentication to a router is required. The router
therefore plays a passive role of forwarding the request only to the therefore plays a passive role of forwarding the request only to the
PDP and executing the policy decision returned by the PDP. PDP and executing the policy decision returned by the PDP.
Section 4.5.3 describes one example of user-to-PDP authentication. Appendix B describes one example of user-to-PDP authentication.
Tschofenig Informational - Expires September 2003 18
RSVP Security Properties March 2003
User authentication with the policy element only provides unilateral User authentication with the policy element only provides unilateral
authentication where the client authenticates to the router or to the authentication where the client authenticates to the router or to the
PDP. If a RSVP message is sent to the userĂs host and public keyed PDP. If a RSVP message is sent to the userĺs host and public keyed
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 can
be assumed. In case of Kerberos mutual authentication may be 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 with
an INTEGRITY object computed with the session key retrieved from the an INTEGRITY object computed with the session key retrieved from the
Kerberos ticket or if the Kerberos ticket included in the policy Kerberos ticket or if the Kerberos ticket included in the policy
element is also used for the RSVP INTEGRITY object as described in element is also used for the RSVP INTEGRITY object as described in
Section 4.2. This procedure only works if a previous message was Section 4.2. This procedure only works if a previous message was
transmitted from the end-host to the network and such key is already transmitted from the end host to the network and such key is already
established. [RFC3182] does not discuss this issue and therefore established. [RFC3182] does not discuss this issue and therefore
there is no particular requirement dealing with transmitting network there is no particular requirement dealing with transmitting network
specific credentials back to the end-user's host. specific credentials back to the end-user's host.
b) Integrity Protection b) Integrity Protection
Tschofenig Informational - Expires April 2003 18
RSVP Security Properties October 2002
The integrity protection of the RSVP message and the POLICY_DATA The integrity protection of the RSVP message and the POLICY_DATA
element are protected separately as shown in Figure 1. In case of a element are protected separately as shown in Figure 1. In case of a
policy ignorant node along the path the RSVP INTEGRITY object and the policy 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 credentials of the user if nodes. Basically the same is true for the credentials of the user if
they are verified at the policy decision point instead of the first they are verified at the policy decision point instead of the first
hop router. hop router.
- Kerberos - Kerberos
skipping to change at line 1001 skipping to change at line 1021
number field inside the Authenticator is used for KRB_PRIV/KRB_SAFE number field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
messages as described in Section 5.3.2 of [RFC1510]) . 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 the digital signature. As authentication is accomplished with the digital signature. As
explained in Section 3.3.3 of [RFC3182] the DIGITAL_SIGNATURE explained in Section 3.3.3 of [RFC3182] the DIGITAL_SIGNATURE
attribute must be the last attribute in the AUTH_DATA object and the attribute must be the last attribute in the AUTH_DATA object and the
digital signature covers the entire AUTH_DATA object. Which hash digital signature covers the entire AUTH_DATA object. Which hash
Tschofenig Informational - Expires September 2003 19
RSVP Security Properties March 2003
algorithm and public key algorithm is used for the digital signature algorithm and public key algorithm is used for the digital signature
computation is described in [RFC2440] in case that PGP is used. In computation is described in [RFC2440] in case that PGP is used. In
case of X.509 credentials the situation is more complex since case of X.509 credentials the situation is more complex since
different mechanisms like CMS [RFC2630] or PKCS#7 [RFC2315] may be different mechanisms like CMS [RFC2630] or PKCS#7 [RFC2315] may be
used for the digitally signing the message element. X.509 only used for the digitally signing the message element. X.509 only
provides the standard for the certificate layout which seems to provides the standard for the certificate layout which seems to
provide 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 only public key based [RFC3182], which provides more than only public key based
authentication (e.g. CRL distribution, key transport, key agreement, authentication (e.g. CRL distribution, key transport, key agreement,
etc.). Furthermore the usage of PGP in RSVP is vague since there are etc.). Furthermore the usage of PGP in RSVP is vague since there are
different versions of PGP (including a OpenPGP [RFC2440]) and there different versions of PGP (including a OpenPGP [RFC2440]) and there
has been no indication which version should be used. When thinking has been no indication which version should be used. When thinking
about CMS support for RSVP the main question that has to be answered about CMS support for RSVP the main question that has to be answered
is whether a public key based authentication (and key agreement is whether a public key based authentication (and key agreement
mechanism) should be supported for a QoS signaling protocol. mechanism) should be supported for a QoS signaling protocol.
Tschofenig Informational - Expires April 2003 19
RSVP Security Properties October 2002
Especially the risks of denial of service attacks, large processing, Especially the risks of denial of service attacks, large processing,
memory and bandwidth utilization should be considered. memory and bandwidth utilization should be considered.
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 or
not sent to the PDP then we have to make the following observation: not sent to the PDP then we have to make the following observation:
a) For the digital signature case only the replay protection provided a) For the digital signature case only the replay protection provided
by the digital signature algorithm can be used. It is however not by the digital signature algorithm can be used. It is however not
clear whether this usage was anticipated or not. Hence we might clear whether this usage was anticipated or not. Hence we might
assume that the replay protection is based on the availability of assume that the replay protection is based on the availability of
skipping to change at line 1057 skipping to change at line 1077
therefore uses the policy data element with PEP2 since PEP1 is not therefore uses the policy data element with PEP2 since PEP1 is not
policy aware. The interfaces between the client and the PEP1 and policy aware. The interfaces between the client and the PEP1 and
between the PEP1 and PEP2 are protected with the RSVP INTEGRITY between the PEP1 and PEP2 are protected with the RSVP INTEGRITY
object. The link between the PEP2 and the PDP is protected for object. The link between the PEP2 and the PDP is protected for
example by using the COPS built-in INTEGRITY object. The dotted line example by using the COPS built-in INTEGRITY object. The dotted line
between the Client and the PDP indicates the protection provided by between the Client and the PDP indicates the protection provided by
the AUTH_DATA element which has no RSVP INTEGRITY object included. the AUTH_DATA element which has no RSVP INTEGRITY object included.
AUTH_DATA +----+ AUTH_DATA +----+
+- - - - - - - - - - - - - - - - - - - - - - - - - -+PDP +-+ +- - - - - - - - - - - - - - - - - - - - - - - - - -+PDP +-+
Tschofenig Informational - Expires September 2003 20
RSVP Security Properties March 2003
+----+ | +----+ |
| | | |
| |
| 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
Tschofenig Informational - Expires April 2003 20
RSVP Security Properties October 2002
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 replay mechanism. The length of the element both use the same 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 is already explained in Section 3.1. Handshake is already explained in Section 3.1.
Section 9 in [RFC3182] states ˘RSVP INTEGRITY object is used to Section 9 in [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.÷. Hence the public key based security (replay) attacks.". Hence the public key based
authentication does not support the RSVP based replay protection authentication does not support the RSVP based replay protection
since the digital signature does not cover the POLICY_DATA INTEGRITY since the digital signature does not cover the POLICY_DATA INTEGRITY
object with its Sequence Number field. The digital signature covers object with its Sequence Number field. The digital signature covers
the entire AUTH_DATA object. the entire AUTH_DATA object.
The use of public key systems within the AUTH_DATA object complicates The use of public key systems within the AUTH_DATA object complicates
replay protection. Digital signature computation with PGP is replay protection. Digital signature computation with PGP is
described in [PGP] and in [RFC2440]. The data structure preceding the described in [PGP] and in [RFC2440]. The data structure preceding the
signed message digest includes information about the message digest signed message digest includes information about the message digest
algorithm used and a 32-bit timestamp when the signature was created algorithm used and a 32-bit timestamp when the signature was created
skipping to change at line 1112 skipping to change at line 1133
for replay protection requires different synchronization mechanisms for replay protection requires different synchronization mechanisms
in case of clock-screws. Traditionally "loosely" synchronized clocks in case of clock-screws. Traditionally "loosely" synchronized clocks
are assumed in those cases but also requires specifying a replay- are assumed in those cases but also requires specifying a replay-
window. 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 user's credentials without destroying the digital replace the user's credentials without destroying the digital
signature. Additionally the RSVP initiating host, where multiple signature. Additionally the RSVP initiating host, where multiple
users may have access, must be trustworthy even if a smartcard is users may have access, must be trustworthy even if a smartcard is
Tschofenig Informational - Expires September 2003 21
RSVP Security Properties March 2003
used since otherwise, replay attacks with a recorded AUTH_DATA object used since otherwise, replay attacks with a recorded AUTH_DATA object
are possible. Note that this however violates the hop-by-hop security are possible. Note that this however violates the hop-by-hop security
assumption. It is therefore assumed that replay protection of the assumption. It is therefore assumed that replay protection of the
user credentials is not considered as an important security user credentials is not considered as an important security
requirement since the hop-by-hop processing of the RSVP message requirement since the hop-by-hop processing of the RSVP message
protects the message against modification by an adversary between two protects the message against modification by an adversary between two
communicating nodes. communicating nodes.
There are two additional issues related to a Kerberos based user There are two additional issues related to a Kerberos based user
authentication in the context of replay protection. The lifetime of authentication in the context of replay protection. The lifetime of
the Kerberos ticket is based on the fields starttime and endtime of the Kerberos ticket is based on the fields starttime and endtime of
the EncTicketPart structure of the ticket as described in Section the EncTicketPart structure of the ticket as described in Section
5.3.1 of [RFC1510]. Since the ticket is created by the KDC located at 5.3.1 of [RFC1510]. Since the ticket is created by the KDC located at
the network of the verifying entity it is not difficult to have the the network of the verifying entity it is not difficult to have the
clocks roughly synchronized for the purpose of lifetime verification. clocks roughly synchronized for the purpose of lifetime verification.
Additional information about clock-synchronization and Kerberos can Additional information about clock-synchronization and Kerberos can
be found at [DG96]. be found at [DG96].
Tschofenig Informational - Expires April 2003 21
RSVP Security Properties October 2002
If we assume that the Kerberos session key is used for RSVP then If we assume that the Kerberos session key is used for RSVP then
there may be a need for rekeying. If we assume that a policy at the there may be a need for rekeying. If we assume that a policy at the
user's host indicates when to rekey then the next RSVP message user's host indicates when to rekey then the next RSVP message
includes a new Kerberos session ticket that is then used by the includes a new Kerberos session ticket that is then used by the
verifying entity. If the lifetime of the Kerberos ticket or other verifying entity. If the lifetime of the Kerberos ticket or other
policies do not affect rekeying then an RSVP security association may policies do not affect rekeying then an RSVP security association may
never require rekeying at all because of the large sequence number never require rekeying at all because of the large sequence number
space. space.
d) (User Identity) Confidentiality d) (User Identity) Confidentiality
skipping to change at line 1162 skipping to change at line 1184
There has often been the discussion whether the effort for protecting There has often been the discussion whether the effort for protecting
user identity is worth the additional complexity. With the increasing user identity is worth the additional complexity. With the increasing
privacy awareness there must be at least a discussion on the privacy awareness there must be at least a discussion on the
mechanisms provided by the given protocol. The main question in this mechanisms provided by the given protocol. The main question in this
context is about the threat model i.e. against which entity the user context is about the threat model i.e. against which entity the user
identity should be protected. Since RSVP does not make any identity should be protected. Since RSVP does not make any
assumptions about the underlying key management protocol for most assumptions about the underlying key management protocol for most
parts it is difficult to make a judgment. However for the identity parts it is difficult to make a judgment. However for the identity
representation part of the protocol it is possible to make some representation part of the protocol it is possible to make some
observations. We assume that the most important threat for a user is observations. We assume that the most important threat for a user is
to reveal his identity to an adversary located between the userĂs to reveal his identity to an adversary located between the userĺs
host and the first-hop router. Identities should furthermore not be host and the first-hop router. Identities should furthermore not be
transmitted outside the domain of the visited network provider i.e. transmitted outside the domain of the visited network provider i.e.
the user identity information inside the policy data element should the user identity information inside the policy data element should
be removed or modified by the PDP to prevent revealing information to be removed or modified by the PDP to prevent revealing information to
Tschofenig Informational - Expires September 2003 22
RSVP Security Properties March 2003
other (non-authorized) entities along the signaling path. We cannot other (non-authorized) entities along the signaling path. We cannot
however provide user identity confidentiality against the network however provide user identity confidentiality against the network
provider to which the user is attached. Different mechanisms must be provider to which the user is attached. Different mechanisms must be
deployed to disallow the network provider to create a profile of the deployed to disallow the network provider to create a profile of the
user. These mechanisms are outside the scope of this document since user. These mechanisms are outside the scope of this document since
there is a strong involvement with the initial authentication and key there is a strong involvement with the initial authentication and key
agreement protocol executed between the user and the visited network. agreement protocol executed between the user and the visited network.
If the link between the userĂs host and the first hop router is If the link between the userĺs host and the first hop router is
protected with IPSec ESP then confidentiality of the entire signaling protected with IPsec ESP then confidentiality of the entire signaling
messages is provided. Note however that the IPSec protection may messages is provided. Note however that the IPsec protection may
terminate at the different node than the RSVP policy aware signaling terminate at the different node than the RSVP policy aware signaling
does. The focus of this Section is, however, the functionality does. The focus of this Section is, however, the functionality
provided by RSVP. provided by RSVP.
The ASCII or Unicode distinguished name of user or application inside The ASCII or Unicode distinguished name of user or application inside
the POLICY_LOCATOR attribute of the AUTH_DATA element may be the POLICY_LOCATOR attribute of the AUTH_DATA element may be
Tschofenig Informational - Expires April 2003 22
RSVP Security Properties October 2002
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. Since the private key is used we usually speak of a authentication. Since the private key is used we usually speak of a
digital signature which can be verified by everyone possessing the digital signature which can be verified by everyone possessing the
public key. Since the certificate with the public key is included in public key. Since the certificate with the public key is included in
the message itself this is no obstacle. Furthermore the included the message itself this is no obstacle. Furthermore the included
certificate provides enough identity information for an eavesdropper certificate provides enough identity information for an eavesdropper
together with the additional (unencrypted) information provided in together with the additional (unencrypted) information provided in
the RSVP message. Hence the possibility of encrypting the policy the RSVP message. Hence the possibility of encrypting the policy
locator in case of public key based authentication is less obvious. locator in case of public key based authentication is less obvious.
To encrypt the identities using asymmetric cryptography the userĂs To encrypt the identities using asymmetric cryptography the userĺs
host must be able to somehow retrieve the public key of the entity host must be able to somehow 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). Currently no such mechanism is defined in [RFC3182]. the PDP). Currently no such mechanism is defined in [RFC3182].
There is no option to encrypt the user or application identity There is no option to encrypt the user or application identity
without Kerberos or public key mechanisms are used since the without Kerberos or public key mechanisms are used since the
selection of an appropriate security association is not possible. selection of an appropriate security association is not possible.
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
skipping to change at line 1223 skipping to change at line 1245
algorithms. [Rae01] defines new encryption algorithms (Rijndael, algorithms. [Rae01] defines new encryption algorithms (Rijndael,
Serpent, and Twofish) that were published in the context of the AES Serpent, and Twofish) that were published in the context of the AES
competition. competition.
The task of evaluating the confidentiality provided for the user The task of evaluating the confidentiality provided for the user
requires to look at protocols executed outside of RSVP (for example requires to look at protocols executed outside of RSVP (for example
to look at the Kerberos protocol). The ticket included in the to look at the Kerberos protocol). The ticket included in the
CREDENTIAL attribute may provide user identity protection by not CREDENTIAL attribute may provide user identity protection by not
including the optional cname attribute inside the unencrypted part of including the optional cname attribute inside the unencrypted part of
the Ticket. Since the Authenticator is not transmitted with the RSVP the Ticket. Since the Authenticator is not transmitted with the RSVP
Tschofenig Informational - Expires September 2003 23
RSVP Security Properties March 2003
message the cname and the crealm of the unencrypted part of the message the cname and the crealm of the unencrypted part of the
Authenticator are not revealed. In order for the user to request the Authenticator are not revealed. In order for the user to request the
Kerberos session ticket, for inclusion in the CREDENTIAL attribute, Kerberos session ticket, for inclusion in the CREDENTIAL attribute,
the Kerberos protocol exchange must be executed. Then the the Kerberos protocol exchange must be executed. Then the
Authenticator sent with the TGS_REQ reveals the identity of the user. Authenticator sent with the TGS_REQ reveals the identity of the user.
The AS_REQ must also include the user identity to allow the Kerberos The AS_REQ must also include the user identity to allow the Kerberos
Authentication Server to respond with an AS_REP message that is Authentication Server to respond with an AS_REP message that is
encrypted with the user's secret key. Using Kerberos, it is therefore encrypted with the user's secret key. Using Kerberos, it is therefore
only possible not to reveal content of the encrypted policy locator, only possible not to reveal content of the encrypted policy locator,
which is only useful if this value differs from the user identity which is only useful if this value differs from the user identity
used with Kerberos. Hence using Kerberos it is not "entirely" used with Kerberos. Hence using Kerberos it is not "entirely"
possible to provide user identity confidentiality. possible to provide user 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 element
may be changed by a policy aware router or by the policy decision may be changed by a policy aware router or by the policy decision
point. Which parts are changed depends upon whether multicast or point. Which parts are changed depends upon whether multicast or
unicast is used, how the policy server reacts, where the user is unicast is used, how the policy server reacts, where the user is
Tschofenig Informational - Expires April 2003 23
RSVP Security Properties October 2002
authenticated and whether he needs to be re-authenticated in other authenticated and whether he needs to be re-authenticated in other
network nodes etc. Hence user and application specific information network nodes etc. Hence user and application specific information
can leak after the messages leave the first hop within the network can leak after the messages leave the first hop within the network
where the user's host is attached. As mentioned at the beginning of where the user's host is attached. As mentioned at the beginning of
this Section this information leakage is assumed to be intentional. this Section this information leakage is assumed to be intentional.
e) Authorization e) Authorization
Additional to the description of the authorization steps of the Additional to the description of the authorization steps of the
Host/Router interface, user based authorization is added with the Host/Router interface, user based authorization is added with the
skipping to change at line 1279 skipping to change at line 1301
the policy decision point may use information from an initial the policy decision point may use information from an initial
authentication and key agreement protocol which may already required authentication and key agreement protocol which may already required
cross-realm communication with the user's home domain to only assume cross-realm communication with the user's home domain to only assume
that the home domain knows the user and that the user is entitled to that the home domain knows the user and that the user is entitled to
roam and to be able to forward accounting messages to this domain. roam and to be able to forward accounting messages to this domain.
This represents the traditional subscriber based accounting scenario. This represents the traditional subscriber based accounting scenario.
Non-traditional or alternative means of accounting might be deployed Non-traditional or alternative means of accounting might be deployed
in the near future that do not require the any type of inter-domain in the near future that do not require the any type of inter-domain
communication. Obviously there is a strong interrelationship between communication. Obviously there is a strong interrelationship between
the authorization and the process of accounting. Note that the term the authorization and the process of accounting. Note that the term
Tschofenig Informational - Expires September 2003 24
RSVP Security Properties March 2003
accounting in this context is not only related to process of accounting in this context is not only related to process of
metering. Metering is only the process of measuring and collecting metering. Metering is only the process of measuring and collecting
resource usage information. Instead the term unites metering, resource usage information. Instead the term unites metering,
pricing, charging and billing. pricing, charging and billing.
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 since a performance optimization allows the session to be sent once since a performance optimization allows the session
key to be cached as noted in Section 7.1 of [RFC2747]. It is assumed key to be cached as noted in Section 7.1 of [RFC2747]. It is assumed
that subsequent RSVP messages only include the POLICY_DATA INTEGRITY that subsequent RSVP messages only include the POLICY_DATA INTEGRITY
object with a keyed message digest that uses the Kerberos session object with a keyed message digest that uses the Kerberos session
key. This however assumes that the security association required for key. This however assumes that the security association required for
the POLICY_DATA INTEGRITY object is created after (or modified) to the POLICY_DATA INTEGRITY object is created after (or modified) to
Tschofenig Informational - Expires April 2003 24
RSVP Security Properties October 2002
allow the selection of the correct key. Otherwise it difficult to say allow the selection of the correct key. Otherwise it difficult to say
which identifier is used to index the security association. which identifier is used to index the security 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, then the message exchange to obtain the performance perspective, then the message exchange to obtain the
session key needs to be considered although the exchange only needs session key needs to be considered although the exchange only needs
to be done once in a long time frame depending on the lifetime of the to be done once in a long time frame depending on the lifetime of the
session ticket. This is particularly true in a mobile environment session ticket. This is particularly true in a mobile environment
with a fast roaming user's host. with a fast roaming user's host.
skipping to change at line 1331 skipping to change at line 1353
Status Protocol [RFC2560] and the Simple Certificate Validation Status Protocol [RFC2560] and the Simple Certificate Validation
Protocol [MHHF01]. Then the integrity of the AUTH_DATA object via the Protocol [MHHF01]. Then the integrity of the AUTH_DATA object via the
digital signature is verified. digital signature is 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. against modification and replay using the RSVP INTEGRITY object.
IPSec may also provide RSVP signaling message protection. The RSVP IPsec may also provide RSVP signaling message protection is it,
message flow between routers is protected based on the chain of trust however, not suggested because of the problems described in Section
and hence each router only needs to have a security association with 5.6. Only in certain environments IPsec protection might not cause
its neighboring routers. This assumption was made because of problems. The RSVP message flow between routers is protected based on
performance advantages and because of special security
characteristics of the core network where no user hosts are directly
attached. In the core network the network structure does not change
frequently and the manual distribution of shared secrets for the RSVP
INTEGRITY object may be acceptable. The shared secrets may be either
manually configured or distributed by using network management
protocols like SNMP.
If IPSec is used in a hop-by-hop fashion then the required security Tschofenig Informational - Expires September 2003 25
RSVP Security Properties March 2003
the chain of trust and hence each router only needs to have a
security association with its neighboring routers. This assumption
was made because of performance advantages and because of special
security characteristics of the core network where no user hosts are
directly attached. In the core network the network structure does not
change frequently and the manual distribution of shared secrets for
the RSVP INTEGRITY object may be acceptable. The shared secrets may
be either manually configured or distributed by using network
management protocols like SNMP.
If IPsec is used in a hop-by-hop fashion then the required security
associations may be manually created or dynamically distributed with associations may be manually created or dynamically distributed with
IKE by either using symmetric or asymmetric authentication modes. A IKE by either using symmetric or asymmetric authentication modes. A
description of the existing IKE authentication modes and IKE security description of the existing IKE authentication modes and IKE security
properties is outside the scope of this document. The reader is properties is outside the scope of this document. The reader is
referred to the relevant documents at the IPSec working group. referred to the relevant documents at the IPsec working group.
Tschofenig Informational - Expires April 2003 25
RSVP Security Properties October 2002
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. In case of IPSec host authentication is exchanged symmetric key. In case of IPsec host authentication is
accomplished with the keyed message digest included in the accomplished with the keyed message digest included in the
Authentication Data field of the IPSec Authentication Header included Authentication Data field of the IPsec Authentication Header included
in every IP packet. in every IP packet.
b) Integrity Protection b) Integrity Protection
Integrity protection is either accomplished with the RSVP INTEGRITY Integrity protection is either accomplished with the RSVP INTEGRITY
object with the variable length Keyed Message Digest field or with object with the variable length Keyed Message Digest field or with
the IPSec Authentication Header. A description of the IPSec AH is the IPsec Authentication Header. A description of the IPsec AH is
found in [RFC2402] and IPSec ESP [RFC2406] with null encryption is found in [RFC2402] and IPsec ESP [RFC2406] with null encryption is
found in [RFC2410]. The main difference between IPSec and RSVP found in [RFC2410]. The main difference between IPsec and RSVP
protection is the layer at which the security is applied. protection is the layer at which the security is applied.
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. IPSec provides an optional window- described in previous Sections. IPsec provides an optional window-
based replay protection, which may cause problems if a strict message based replay protection, which may cause problems if a strict message
ordering of RSVP messages is required. This problem was already ordering of RSVP messages is required. This problem was already
discussed in a previous Section and a possible solution is to include discussed in a previous Section and a possible solution is to include
the RSVP INTEGRITY object without a key, which reduces the RSVP the RSVP INTEGRITY object without a key, which reduces the RSVP
integrity protection to a simple MD5 hash. This modification must integrity protection to a simple MD5 hash. This modification must
however be integrated into an existing implementation and it is not however be integrated into an existing implementation and it is not
clear whether the RSVP standard allows this modification. If the RSVP clear whether the RSVP standard allows this modification. If the RSVP
implementation is able to access the IPSec Security Association implementation is able to access the IPsec Security Association
Database and retrieve the required security association then no such Database and retrieve the required security association then no such
modification to RSVP is required and IKE is only used to distribute modification to RSVP is required and IKE is only used to distribute
the security associations. This however requires the RSVP the security associations. This however requires the RSVP
implementation to trigger the IKE exchange. implementation to trigger the IKE exchange.
Tschofenig Informational - Expires September 2003 26
RSVP Security Properties March 2003
To enable crashed hosts to learn the latest sequence number used the To enable crashed hosts to learn the latest sequence number used the
Integrity Handshake mechanism is used in RSVP as explained in a Integrity Handshake mechanism is used in RSVP as explained in a
Section above. IPSec does not provide such a mechanism since a Section above. IPsec does not provide such a mechanism since a
crashed host looses its negotiated security associations and crashed host looses its negotiated security associations and
therefore has to re-negotiate them using IKE. Note that manually therefore has to re-negotiate them using IKE. Note that manually
configured IPSec security associations do not provide replay configured IPsec security associations do not provide replay
protection because a sequence number rollover would require the protection because a sequence number rollover would require the
establishment of a new SA. This is obviously not possible when using establishment of a new SA. This is obviously not possible when using
manually configured IPSec SAs. Using IKE with pre-shared secrets is manually configured IPsec SAs. Using IKE with pre-shared secrets is
therefore a simple solution. therefore a simple solution.
d) Confidentiality d) Confidentiality
Confidentiality is not provided by RSVP but using IPSec ESP in a hop- Confidentiality is not provided by RSVP but using IPsec ESP in a hop-
by-hop mode can provide it. The usage of IPSec ESP for RSVP is not by-hop mode can provide it. The usage of IPsec ESP for RSVP is not
recommended because of the additional overhead for little additional recommended because of the additional overhead for little additional
security benefit if we think of the underlying assumed trust model of security benefit if we think of the underlying assumed trust model of
chain of trust. Hence there must be a good reason why to require chain of trust. Hence there must be a good reason why to require
Tschofenig Informational - Expires April 2003 26
RSVP Security Properties October 2002
confidentiality in a hop-by-hop fashion in the core network of the confidentiality in a hop-by-hop fashion in the core network of the
same administrative domain. If the RSVP network spawns different same administrative domain. If the RSVP network spawns different
provider networks then it is possible to encapsulate RSVP messages provider networks then it is possible to encapsulate RSVP messages
between RSVP networks over a non-RSVP cloud similar to a VPN. Such a between RSVP networks over a non-RSVP cloud similar to a VPN. Such a
configuration is mainly determined by the network structure of a configuration is mainly determined by the network structure of a
provider. provider.
e) Authorization e) Authorization
Depending on the RSVP network QoS resource authorization at different Depending on the RSVP network QoS resource authorization at different
skipping to change at line 1430 skipping to change at line 1454
to modify the policy element, a token may be added to the policy to modify the policy element, a token may be added to the policy
element to increase the efficiency of the re-authorization procedure. element to increase the efficiency of the re-authorization procedure.
This token is used to refer to an already computed policy decision. This token is used to refer to an already computed policy decision.
The communications interface from the PEP to the PDP must be properly The communications interface from the PEP to the PDP must be properly
secured. secured.
f) Performance f) Performance
The performance characteristics the protection of the RSVP signaling The performance characteristics the protection of the RSVP signaling
messages is largely determined by the key exchange protocol since the messages is largely determined by the key exchange protocol since the
RSVP INTEGRITY object or IPSec AH are only used to compute a keyed RSVP INTEGRITY object or IPsec AH are only used to compute a keyed
message digest of the transmitted messages. Furthermore only RSVP message digest of the transmitted messages. Furthermore only RSVP
signaling messages are protected and the protection of the signaling messages are protected and the protection of the
application data stream is outside the scope of RSVP. IPSec ESP application data stream is outside the scope of RSVP. IPsec ESP
provides a performance penalty but may only be rarely used. A network provides a performance penalty but may only be rarely used. A network
administrator may however use IPSec ESP in transport mode with NULL administrator may however use IPsec ESP in transport mode with NULL
encryption to provide the same functionality as IPSec AH but with the encryption to provide the same functionality as IPsec AH but with the
chance of better hardware support. chance of better hardware support.
The security associations within the core network i.e. between The security associations within the core network i.e. between
individual routers (in comparison to the security association between individual routers (in comparison to the security association between
the userĂs host and the first-hop router or with the attached network the userĺs host and the first-hop router or with the attached network
in general) can be established more easily because of the strong in general) can be established more easily because of the strong
Tschofenig Informational - Expires September 2003 27
RSVP Security Properties March 2003
trust assumptions. Furthermore it is possible to use security trust assumptions. Furthermore it is possible to use security
associations with an increased lifetime to avoid too frequent associations with an increased lifetime to avoid too frequent
rekeying. Hence there is less impact for the performance compared to rekeying. Hence there is less impact for the performance compared to
the user to network interface. The security association storage the user to network interface. The security association storage
requirements are also less problematic. requirements are also less problematic.
4.5 Miscellaneous Issues 5 Miscellaneous Issues
4.5.1 Dictionary Attacks and Kerberos This section describes a number of issues which illustrate some of
the short-comings of RSVP with respect to security.
This Section addresses issues related to Kerberos and its 5.1 First Hop Issue
In case of end-to-end signaling an end host starts signaling to its
attached network. The first-hop communication is often more difficult
because of the different requirements and a missing trust
relationship. An end host must therefore obtain some information to
start RSVP signaling:
- Does this network support RSVP signaling?
- Which node supports RSVP signaling?
- To which node is authentication required?
- Which identity is used for authentication?
- Which security mechanisms are used for authentication?
- Which algorithms have to be used?
- Where should the keys/security association come from?
- Should a security association be established?
RSVP, as specified today, is used as a building block. Hence these
questions have to be answered as part of overall architectural
considerations. Without giving an answer to this question "ad-hoc"
RSVP communication by an end host roaming to an unknown network is
not possible. A negotiation of security mechanisms and algorithms is
not supported for RSVP.
5.2 Next-Hop Problem
Throughout the document it was always assumed that the next RSVP node
along the path is always known. Knowing your next hop is important to
be able to select the correct key for the RSVP Integrity object to
provide proper protection. In case that an RSVP node assumes to know
which node is the next hop then the following protocol exchange can
occur:
Integrity
(A<->C) +------+
(3) | RSVP |
+------------->+ Node |
| | B |
Integrity | +--+---+
(A<->C) | |
+------+ (2) +--+----+ |
Tschofenig Informational - Expires September 2003 28
RSVP Security Properties March 2003
(1) | RSVP +----------->+Router | | Error
----->| Node | | or +<-----------+ (I am B)
| A +<-----------+Network| (4)
+------+ (5) +--+----+
Error .
(I am B) . +------+
. | RSVP |
...............+ Node |
| C |
+------+
Figure 5: Next-Hop Issue
When RSVP node A in Figure x receives an incoming RSVP Path message
then standard RSVP message processing takes place. Node A then has to
decide which key to select to protect the signaling message. We
assume that some mechanism which is not further specified is used to
make this decision. In this example node A assumes that the message
will travel to RSVP node C. However because of some reasons (e.g. a
route change, inability to learn the next RSVP hop along the path,
etc.) the message travels to node B via a non-RSVP supporting router
which cannot verify the integrity of the message (or cannot decrypt
the Kerberos service ticket). The processing failure causes a PathErr
message to be returned to the originating sender of the Path message.
This error message also contains information about the node
recognizing the error. In many cases a security association might not
be available. Node A receiving the PathErr message might use the
information returned with the PathErr message to select a different
security association (or to establish one). The RSVP Path message
therefore provides a number of functions: path discovery, detecting
route changes, learning of QoS capabilities along the path using the
Adspec object, (with some interpretation) next-hop discovery and
possibly security association establishment (for example in case of
Kerberos).
From a security point of view there is a conflict between
- Idempotent messages delivery and efficiency
Especially the RSVP Path message performs a number of functions.
Supporting idempotent message delivery somehow contradicts with
security association establishment and efficient message delivery and
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, very 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
Tschofenig Informational - Expires September 2003 29
RSVP Security Properties March 2003
To protect an RSVP signaling message (and a RSVP Path message in
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 is not supported 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 a
security association with all immediately neighboring RSVP nodes.
Especially for inter-domain signaling, IntServ over DiffServ or for
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 to properly protect 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 this might be possible due to
manual configuration in case of a dense distribution of RSVP nodes.
There is nothing which prevents an adversary from continuously
flooding an RSVP node with bogus PathErr messages. It might be
possible to protect the PathErr message with an existing security
association if available. A legitimate RSVP node would believe that a
change in the path took place. Hence this node would try to select a
different security association or try to create one with the
indicated node. Hence an adversary can send a PathErr message at any
time to confuse an RSVP node. If an adversary is located along
somewhere along the path then it might also be possible to act as a
man-in-the-middle adversary if either authentication and/or
authorization is not performed with the necessary accuracy.
5.3 Last-Hop Issue
This section tries to address practical difficulties when
authentication and key establishment is accomplished with a protocol
which shows some asymmetry in message processing when executed
between two nodes. Kerberos is such a protocol and also the only
supported protocol which provides dynamic session key establishment
for RSVP. For first-hop communication authentication is typically
done between a user and some network in the network (for example the
access router). Especially in a mobile environment it is not feasible
to authenticate end hosts based on their IP or MAC address. To show
the problem the typical processing steps for Kerberos are shown for
first-hop communication:
Tschofenig Informational - Expires September 2003 30
RSVP Security Properties March 2003
a) The end host A learns the identity (i.e. Kerberos principal name)
of some entity B. This entity B is either the next RSVP node or a PDP
or the next policy aware RSVP node.
b) Entity A then requests a ticket granting ticket for the network
domain. This assumes that the identity of the network domain is
known.
c) Entity A then requests a service ticket for entity B which was
learned in step (a).
d) Entity A includes the service ticket to the RSVP signaling message
(inside the policy object). The Kerberos session key is used to
protect the entire RSVP signaling message.
For last-hop communication this processing step theoretically has to
be reversed; entity A is then a node in the network (for example the
access router) and entity B is the other end host. This assumes that
RSVP signaling is accomplished between two end hosts and not between
an end host and a application server. The access router might however
in step (a) not be able to learn the identity of the user's principal
name since 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 described above.
IAKERB is however not supported.
5.4 RSVP and IPsec protected data traffic
QoS signaling requires flow information to be established at routers
along a path. This flow identifier installed at each devices tells
the router which data packets should experience QoS treatment. RSVP
typically establishes a flow identifier based on the 5-tuple (source
IP address, destination IP address, transport protocol type, source
port and destination port). If this 5-tuple information is not
available then other identifiers have to be used. IPsec protected
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
substitute for them. RFC 2207 considers these IPsec implications for
RSVP and is based on three assumptions:
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
interaction with the IPsec SADB and SPD. An application usually does
not know the SPI of the protected flow and cannot provide the desired
values. It can provide the signaling protocol daemon with flow
identifiers. The signaling daemon would then need to query the IPsec
security association database by providing the flow identifiers as
input parameters and the SPI as an output parameter.
b) RFC 2207 assumes an end-to-end IPsec protection of the data
traffic. In IPsec is applied in a nested fashion then parts of the
path do not experience QoS treatment. This problem can be treated as
Tschofenig Informational - Expires September 2003 31
RSVP Security Properties March 2003
a tunneling problem but is initiated by the end host. A figure better
illustrates the problem in case of enforcing secure network access:
+------+ +---------------+ +--------+ +------+
| Host | | Security | | Router | | Host |
| A | | Gateway (SGW) | | Rx | | B |
+--+---+ +-------+-------+ +----+---+ +--+---+
| | | |
|IPsec-Data( | | |
| OuterSrc=A, | | |
| OuterDst=SGW, | | |
| SPI=SPI1, | | |
| InnerSrc=A, | | |
| OuterDst=B, | | |
| Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | |
|=====================>| Protocol=X, |IPsec-Data( |
| | SrcPort=Y, | SrcIP=A, |
| --IPsec protected-> | DstPort=Z) | DstIP=B, |
| data traffic |------------------>| Protocol=X, |
| | | SrcPort=Y, |
| | | DstPort=Z) |
| | |---------------->|
| | | |
| | --Unprotected data traffic-> |
| | | |
Figure 6: RSVP and IPsec protected data traffic
Host A transmitting data traffic would either indicate a 3-tuple <A,
SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. In any case it is not
possible to make a QoS reservation for the entire path. Similar
examples are remote access using a VPN, protection of data traffic
between the home agent (or a security gateway in the home network)
and the mobile node and other. With a nested application of IPsec
(for example IPsec between A and SGW and between A and B) the same
problem occurs.
One possible solution to this problem is to change the flow
identifier along the path to capture the new flow identifier after an
IPsec endpoint.
IPsec tunnels which neither start nor terminate at one of the
signaling end points (for example between two networks) should be
addressed differently by recursively applying an RSVP signaling
exchange for the IPsec tunnel. RSVP signaling within tunnels is
addressed in [RFC2746].
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
SPI is allocated for the security association. To reflect this change
either a new reservation has to be established or the flow identifier
Tschofenig Informational - Expires September 2003 32
RSVP Security Properties March 2003
of the existing reservation has to be updated. Since IPsec SAs have a
longer lifetime this issue does not seem to be a major issue. IPsec
protection of SCTP data traffic might more often require an IPsec SA
(and an SPI) change to reflect added and removed IP addresses from an
SCTP association.
5.5 End-to-End Security Issues and RSVP
End-to-end security for RSVP has not been discussed throughout the
document. In this context end-to-end security refers to credentials
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
process and modify the signaling messages according to the processing
procedure. Some objects however could be used for end-to-end
protection. The main question however is what the benefit of such an
end-to-end security is. First there is the question how to establish
the required security association. Between two arbitrary hosts on the
Internet this might turn out to be quite difficult. Furthermore it
depends on an architecture where RSVP is deployed whether it is
useful to provide end-to-end security. If RSVP is only used to signal
QoS information into the network and other protocols have to be
executed beforehand to negotiate the parameters and to decide which
entity is charged for the QoS reservation then no end-to-end security
is likely to be required. Introducing end-to-end security to RSVP
would then cause problems with extensions like RSVP proxy [GD+02],
Localized RSVP [MS+02] and others which terminate RSVP signaling
somewhere along the path without reaching the destination end host.
Such a behavior could then be interpreted as a man-in-the-middle
attack.
5.6 IPsec protection of RSVP signaling messages
In this document it was assumed that RSVP signaling messages can also
be protected by IPsec in a hop-by-hop fashion between two adjacent
RSVP nodes. RSVP uses a special processing of signaling messages
which complicates IPsec protection. As we explain in this section
IPsec should only be used for protection of RSVP signaling messages
in a point-to-point communication environment (i.e. a RSVP message
can only reach one RSVP router and not possibly more than one). This
circumstance is caused by the combination of signaling message
delivery and discovery into a single message. Furthermore the end-to-
end addressing complicates IPsec handling considerably. This section
tries to describe these complications.
RSVP messages are transmitted as raw IP packets with protocol number
46. It might be possible to encapsulate them in UDP as described in
Appendix C of [RFC2205]. Some RSVP messages (Path, PathTear, and
ResvConf) must have the Router Alert IP Option set in the IP header.
These messages are addressed to the (unicast or multicast)
destination address and not to the next RSVP node along the path.
Hence an IPsec traffic selector can only use these fields for IPsec
SA selection. If there is only a single path (and possibly every
Tschofenig Informational - Expires September 2003 33
RSVP Security Properties March 2003
traffic is protected) then there is no problem for IPsec protection
of signaling messages. This type of protection is not common and
might only be used to secure network access between an end host and
its first-hop router. Since the described RSVP messages are addressed
to the destination address instead of the next RSVP node it is not
possible to use IPsec in transport mode - only IPsec in tunnel mode
is possible.
If there is more than one possible path which an RSVP message can
take then the IPsec engine will experience difficulties to protect
the message. Even if the RSVP daemon installs a traffic selector with
the destination IP address then still there is no distinguishing
element which allows to select the correct security association of
one of the possible RSVP nodes along. Even if it possible to apply
IPsec protection (in tunnel mode) for RSVP signaling messages by
incorporating some additional information then there is still the
possibility that the tunneled messages do not recognize a path change
in a non-RSVP router. Then the signaling messages would simply follow
different path than the data.
RSVP messages like RESV can be protected by IPsec since they are
contain enough information to create IPsec traffic selectors which
allow a differentiation between different next RSVP nodes. A traffic
selector would then contain the protocol number and the source /
destination address pair.
5.7 Accounting/Charging Framework
In [TB+03] two trust models (NJ Turnpike and NJ Parkway model) and
two authorization models (per-session and per-channel financial
settlement). The NJ Turnpike model gives a justification for the hop-
by-hop security protection. RSVP supports the NJ Parkway model and
per-channel financial settlement to some extend only. The
communication procedures defined for policy object [Her95] can be
improved to support the more efficient per-channel financial
settlement by avoiding policy handling between inter-domain networks
at a signaling message granularity.
6 Conclusions
RSVP was the first QoS signaling protocol which provided some
security protection. Whether RSVP provides enough security protection
heavily depends on the environment where it is deployed. As RSVP is
specified today should be seen as a building block that has to be
adapted to a given architecture.
This document aims to provide more insights into the security of
RSVP. It cannot not be interpreted as a pass or fail evaluation of
the security provided by RSVP.
Certainly this document is not complete to describe all security
issues related to RSVP. Some issues that require further
Tschofenig Informational - Expires September 2003 34
RSVP Security Properties March 2003
considerations are RSVP extensions (for example [RFC2207]), multicast
issues and other security properties like traffic analysis etc.
Additionally the interaction with mobility protocols (micro- and
macro-mobility) from a security point of view demands further
investigation.
What can be learned from a practical protocol experience and from the
increased awareness regarding security is that some of the available
credential types have received more acceptance. Kerberos is such a
system which is integrated in many IETF protocols today.
Public key based authentication techniques are however still
considered to be too heavy-weight (computationally and from a
bandwidth perspective) to be used for a per-flow signaling. The
increased focus on denial of service attacks additionally demands a
closer look on public key based authentication.
The following list briefly summarizes a few security or architectural
issues which desire improvement:
* Discovery and signaling message delivery should be separated.
* For some applications and scenarios it cannot be assumed that
neighboring RSVP aware nodes know each other. Hence some in-path
discovery mechanism should be provided.
* Addressing for signaling messages should be done in a hop-by-hop
fashion.
* Standard security protocols (IPsec, TLS or CMS) should be used
whenever possible. Authentication and key exchange should separated
from signaling message protection. In general it is necessary to
provide key management to dynamically establish a security
association for signaling message protection. Relying on manually
configured keys between neighboring RSVP nodes is insufficient.
* The usage of public key cryptography for authorization tokens,
identity representation, selective object protection, etc. is likely
to cause fragmentation and problems.
* Public key authentication and user identity confidentiality
provided with RSVP require some improvement.
* Public key based user authentication only provides entity
authentication. An additional security association is required to
protect the signaling message.
* Data origin authentication should not be provided by non-RSVP nodes
(such as the PDP). Such a procedure could be accomplished by entity
authentication during the authentication and key exchange phase.
* Authorization and charging should be better integrated in the base
protocol.
Tschofenig Informational - Expires September 2003 35
RSVP Security Properties March 2003
* Selective message protection should be provided. A protected
message should be recognizable from a flag in the header.
* Confidentiality protection is missing and should therefore be added
to the protocol.
* Parameter and mechanism negotiation should be provided.
7 Security Considerations
This document discusses security properties of RSVP and as such, it
is concerned entirely with security.
8 IANA considerations
This document does not address any IANA considerations.
9 Open Issues
A future version of this draft will restructure and shorten the
document and include references to other RSVP security related
activities and papers.
10 Acknowledgments
I would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu and
Guenther Schaefer for their valuable comments. Additionally I would
like to thank Robert and Jorge for their time to discuss various
issues with me. Furthermore I would like to thank Marc De Vuyst for
his comments to the draft.
Appendix A. Dictionary Attacks and Kerberos
This section addresses issues related to Kerberos and its
vulnerability against dictionary attacks since there often seems to vulnerability against dictionary attacks since there often seems to
be a misunderstanding. The reason for including this discussion in be a misunderstanding. The reason for including this discussion in
this document is that Kerberos seems to be one of the most widely this document is that Kerberos seems to be one of the most widely
supported authentication and key distribution systems available. supported authentication and key distribution systems available.
The initial Kerberos AS_REQ request (without pre-authentication, The initial Kerberos AS_REQ request (without pre-authentication,
various extensions and without PKINIT) is unprotected. The response various extensions and without PKINIT) is unprotected. The response
Tschofenig Informational - Expires April 2003 27
RSVP Security Properties October 2002
message AS_REP is encrypted with the client's long-term key. An message AS_REP is encrypted with the client's long-term key. An
adversary can take advantage of this fact by requesting AS_REP adversary can take advantage of this fact by requesting AS_REP
messages to mount an off-line dictionary attack. Using pre- messages to mount an off-line dictionary attack. Using pre-
authentication ([Pat92]) can be used to reduce this problem. authentication ([Pat92]) can be used to reduce this problem.
However pre-authentication does not entirely prevent dictionary However pre-authentication does not entirely prevent dictionary
attacks by an adversary since he can still eavesdrop Kerberos attacks by an adversary since he can still eavesdrop Kerberos
messages if being located at the path between the mobile node and the messages if being located at the path between the mobile node and the
KDC. With mandatory pre-authentication for the initial request an KDC. With mandatory pre-authentication for the initial request an
adversary cannot request a Ticket Granting Ticket for an arbitrary adversary cannot request a Ticket Granting Ticket for an arbitrary
Tschofenig Informational - Expires September 2003 36
RSVP Security Properties March 2003
user. On-line password guessing attacks are still possible by user. On-line password guessing attacks are still possible by
choosing a password (e.g. from a dictionary) and then transmitting an choosing a password (e.g. from a dictionary) and then transmitting an
initial request including pre-authentication data field. An initial request including pre-authentication data field. An
unsuccessful authentication by the KDC results in an error message unsuccessful authentication by the KDC results in an error message
and the gives the adversary a hint to try a new password and restart and the gives the adversary a hint to try a new password and restart
the protocol again. the protocol again.
There are however some proposals that prevent dictionary attacks from There are however some proposals that prevent dictionary attacks from
happening. The use of Public Key Cryptography for initial happening. The use of Public Key Cryptography for initial
authentication [TN+01] (PKINIT) is one such solution. Other proposals authentication [TN+01] (PKINIT) is one such solution. Other proposals
use strong-password based authenticated key agreement protocols like use strong-password based authenticated key agreement protocols like
the Encrypted Key Exchange protocol (EKE) to avoid leaking of user the Encrypted Key Exchange protocol (EKE) to avoid leaking of user
password information. B. Jaspan investigated the use of EKE for password information. B. Jaspan investigated the use of EKE for
Kerberos V5 called ˘Dual-workfactor Encrypted Key Exchange÷ [Jas96] Kerberos V5 called "Dual-workfactor Encrypted Key Exchange" [Jas96]
which is described below. which is described below.
With the PA-ENC-DH pre-authentication Jaspan included the Diffie- With the PA-ENC-DH pre-authentication Jaspan included the Diffie-
Hellman ˘public key÷ of the client encrypted with the user password Hellman "public key" of the client encrypted with the user password
in the initial AS_REQ to the Authentication Server. Additionally the in the initial AS_REQ to the Authentication Server. Additionally the
modulus m is included since the client can choose this value modulus m is included since the client can choose this value
dynamically. dynamically.
It is interesting to note that pre-authentication was orginally It is interesting to note that pre-authentication was orginally
introduced to allow the user to authenticate to the AS with the introduced to allow the user to authenticate to the AS with the
inital AS_REQ message . The use of the Encrypted Key Exchange inital AS_REQ message . The use of the Encrypted Key Exchange
protocol [BM92] as a pre-authentication mechanism does not allow the protocol [BM92] as a pre-authentication mechanism does not allow the
Authentication Server to authenticate the client since this would Authentication Server to authenticate the client since this would
require the client to include verifiable data (e.g. a keyed message require the client to include verifiable data (e.g. a keyed message
skipping to change at line 1518 skipping to change at line 2014
The client is not authenticated to the Authentication Server. The client is not authenticated to the Authentication Server.
It is obvious that both the client and the Authentication Server must It is obvious that both the client and the Authentication Server must
be able to provide good random numbers for the creation of the be able to provide good random numbers for the creation of the
Diffie-Hellman key pair. Jaspan additionally noted that the timestamp Diffie-Hellman key pair. Jaspan additionally noted that the timestamp
in the response from the Authentication Server (AS_REP message) can in the response from the Authentication Server (AS_REP message) can
be used to eliminate the dependency on time synchronization of the be used to eliminate the dependency on time synchronization of the
Kerberos protocol. The client can use this value to adjust his clock Kerberos protocol. The client can use this value to adjust his clock
after successful authentication of the Authentication Server. after successful authentication of the Authentication Server.
Tschofenig Informational - Expires April 2003 28
RSVP Security Properties October 2002
The vulnerability against denial of service attacks is a disadvantage The vulnerability against denial of service attacks is a disadvantage
common to many strong-password based authenticated key agreement common to many strong-password based authenticated key agreement
protocols. Nothing prevents an adversary from flooding the protocols. Nothing prevents an adversary from flooding the
Authentication Server with bogus AS_REQ messages using the pre- Authentication Server with bogus AS_REQ messages using the pre-
authentication method PA-ENC-DH. This forces the Authentication authentication method PA-ENC-DH. This forces the Authentication
Server to create a Diffie-Hellman public/private key pair, to decrypt Server to create a Diffie-Hellman public/private key pair, to decrypt
the received response and to compute the session key k(a,as) and to the received response and to compute the session key k(a,as) and to
return a message to the source IP address of the previously received return a message to the source IP address of the previously received
Tschofenig Informational - Expires September 2003 37
RSVP Security Properties March 2003
message. Even if the Authentication Server does not re-create a new message. Even if the Authentication Server does not re-create a new
public/private key pair with every session he still has to compute public/private key pair with every session he still has to compute
the session key which requires multiprecision operations and this is the session key which requires multiprecision operations and this is
time consuming. time consuming.
Jaspan furthermore noted that the missing client authentication can Jaspan furthermore noted that the missing client authentication can
be used by an undetectable on-line password guessing attack as be used by an undetectable on-line password guessing attack as
described in [DH95]. An adversary sends an AS_REQ for a user B described in [DH95]. An adversary sends an AS_REQ for a user B
encrypted with a password k(bĂ). The Authentication Server decrypts encrypted with a password k(bĺ). The Authentication Server decrypts
the value of the pre-authentication field with the real user password the value of the pre-authentication field with the real user password
k(b) and encrypts his response to the adversary. If the adversary k(b) and encrypts his response to the adversary. If the adversary
correctly guessed the password of user B then the receive response correctly guessed the password of user B then the receive response
verifies correctly. Jaspan proposed to modify the KDC to allow only a verifies correctly. Jaspan proposed to modify the KDC to allow only a
certain number of requests per day but this can be used by an certain number of requests per day but this can be used by an
attacker to mount a denial of service attack against such users to attacker to mount a denial of service attack against such users to
lock their accounts by sending a number of incorrect requests to the lock their accounts by sending a number of incorrect requests to the
KDC. The KDC would then reject Ticket Granting Ticket or even a KDC. The KDC would then reject Ticket Granting Ticket or even a
service ticket from legitimate users. service ticket from legitimate users.
Tom Wu mentioned in [Wu99] the use of a variant of SRP [Wu98] and the Tom Wu mentioned in [Wu99] the use of a variant of SRP [Wu98] and the
use of SPEKE [Jab96] to be used in the pre-authentication process as use of SPEKE [Jab96] to be used in the pre-authentication process as
possible candidates to prevent dictionary attacks. Unfortunately Wu possible candidates to prevent dictionary attacks. Unfortunately Wu
does not explain the proposals in detail. does not explain the proposals in detail.
Currently only PKINIT is available for preventing off-line dictionary Currently only PKINIT is available for preventing off-line dictionary
attacks. Other proposals described above like SPEKE, SRP etc. are not attacks. Other proposals described above like SPEKE, SRP etc. are not
included in the current Kerberos version. IPR issues may be one of included in the current Kerberos version. IPR issues may be one of
the reasons. the reasons.
4.5.2 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 in
[MADS01]. The steps for authenticating the user to the PDP in an [MADS01]. The steps for authenticating the user to the PDP in an
intra-realm scenario are the following: intra-realm scenario are the following:
Tschofenig Informational - Expires April 2003 29
RSVP Security Properties October 2002
- 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 local
realm. realm.
- This ticket is then embedded in the AUTH_DATA element and included - This ticket is then embedded in the AUTH_DATA element and included
in either the PATH or the RESV message. In case of MicrosoftĂs in either the PATH or the RESV message. In case of Microsoftĺs
implementation the user identity encoded as a distinguished name is implementation the user identity encoded as a distinguished name is
encrypted with the session key provided with the Kerberos ticket. The encrypted with the session key provided with the Kerberos ticket. The
Kerberos ticket is sent without the Kerberos authdata element that Kerberos ticket is sent without the Kerberos authdata element that
contains authorization information as explained in [MADS01]. contains authorization information as explained in [MADS01].
Tschofenig Informational - Expires September 2003 38
RSVP Security Properties March 2003
- The RSVP message is then intercepted by the PEP who forwards it to - The RSVP message is then intercepted by the PEP who forwards it to
the PDP. [MADS01] does not state which protocol is used to forward the PDP. [MADS01] does not state which protocol is used to forward
the RSVP message to the PDP. the RSVP message to the PDP.
- The PDP who finally receives the message decrypts the received - The PDP who finally receives the message decrypts the received
service ticket. The ticket contains the session key which was used by service ticket. The ticket contains the session key which was used by
the user's host to the user's host to
a) Encrypt the principal name inside the policy locator field of the a) Encrypt the principal name inside the policy locator field of the
AUTH_DATA object and to 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 the
skipping to change at line 1605 skipping to change at line 2102
here is between the user's host and the PDP. The RSVP INTEGRITY here is between the user's host and the PDP. The RSVP INTEGRITY
object on the other hand is used to protect the path between the object on the other hand is used to protect the path between the
users host and the first-hop router since the two message parts users host and the first-hop router since the two message parts
terminate at a different node and a different security association terminate at a different node and a different security association
must be used. The interface between the message intercepting first- must be used. The interface between the message intercepting first-
hop router and the PDP must be protected as well. hop router and the PDP must be protected as well.
c) The PDP does not maintain a user database and [MADS01] describes c) The PDP does not maintain a user database and [MADS01] describes
that the PDP may query the Active Directory (a LDAP based directory that the PDP may query the Active Directory (a LDAP based directory
service) for user policy information. service) for user policy information.
4.5.3 Open Issues 11 References
The following issues have often been mentioned in the context of
RSVP. However a design decision with regard to end-to-end security
and a framework for accounting and charging cannot be found in the
main RSVP documents.
a) End-to-End Security Issues and RSVP
End-to-end security for RSVP has not been discussed throughout the
document. In this context end-to-end security refers to credentials
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
process and modify the signaling messages according to the processing
procedure. Some objects however could be used for end-to-end
protection. The main question however is what the benefit of such an
end-to-end security is. First there is the question how to establish
the required security association which turned out to be quite
difficult between two arbitrary hosts. Furthermore it depends on an
architecture where RSVP is deployed whether it is useful to provide
Tschofenig Informational - Expires April 2003 30
RSVP Security Properties October 2002
end-to-end security. If RSVP is only used to signal QoS information
into the network and other protocols have to be executed beforehand
to negotiate the parameters and to decide which entity actually has
to pay for the reservation then no end-to-end security is likely to
be required. End-to-end security if introduced into RSVP would then
cause problem with extensions like RSVP proxy [GD+02], Localized RSVP
[MS+02] and others which terminate RSVP signaling somewhere along the
path without reaching the destination end-host. Such a behavior could
then be interpreted as a man-in-the-middle attack.
b) Accounting/Charging Framework
Many documents have been published in the context of accounting and
charging for RSVP/IntServ, pricing, business models etc. The reasons
for large number of proposals and the ˘rare÷ number of used
mechanisms are manifold. The lack of a defined framework makes it
difficult to argument whether the processing of credentials within
the policy element and a possible forwarding to other network domains
is required. Forwarding user credentials would allow other networks
to authenticate the identity acting as a signaling source. If
credentials are however removed then no such behavior can be achieved
and each neighboring domain only exchanges accounting data to the
next domain without taking the length of the real number of visited
domains into consideration. Scalability problems in the core network
speak against solutions that verify the user credentials by every
network along the path or solutions that create an analogon to a
long-distance call. A long-distance call in terms of RSVP can be
simulated by adding a monetary value for the requested resource at
each network along the path. Issues related to accounting will
receive further attention in the NSIS framework discussion.
5 Conclusions
It is often argued that RSVP cannot be used in particular
environments. Whether this is true or not cannot be answered by the
author but what can be observed is the following: RSVP should be seen
as a building block that has to be adapted to provide the desired
services for a given architecture. The point to stress is
"architecture". Hence it is difficult to state whether RSVP provides
the adequate security for a given architecture without a particular
framework. The author represents the opinion that the RSVP designers
and architects did a good job in providing the necessary blocks
(including security relevant parts) that allows RSVP to be easily
adapted to most architectures. By including some RSVP extensions
additional flexibility and features are provided.
This document aims to provide more insights into the security of RSVP
explained with different words from a different view. It must not be
interpreted as a pass or fail evaluation of the security provided by
RSVP.
Tschofenig Informational - Expires April 2003 31
RSVP Security Properties October 2002
Certainly this document is not complete to describe all issues
related to RSVP but it serves as a starting point. Some issues that
require further considerations are RSVP extensions (for example
[RFC2207]), multicast issues and other security properties like
traffic analysis etc. Additionally the interaction with mobility
protocols (micro- and macro-mobility) from a security point of view
demands further investigation. As stated in the previous Section the
interaction with accounting/charging issues are worth a closer look.
What can be learned from a practical protocol experience and from the
increased awareness regarding security is that some of the available
credential types have received more acceptance. Kerberos is such a
system which is integrated in many IETF protocols today.
Public key based authentication techniques are however still
considered to be too heavy-weight (computationally and from a
bandwidth perspective) to be used for a per-flow signaling. The
increased focus on denial of service attacks additionally demands a
closer look on public key based authentication.
6 Security Considerations
This document discusses security properties of RSVP and as such, it
is concerned entirely with security.
7 IANA considerations
This document does not address any IANA considerations.
8 Open Issues
A future version of this document might include a description of the
following issues:
. Security Algorithm Negotiation
. Denial of Service Attacks
. IPSec implications for RSVP
o VPN issues
o Implications for flow identification
o IPSec protection of signaling messages
o Nested IPSec Tunnels
. First-Peer Problem
. Next-Peer Problem
. Last-Peer problem
. Possibly: Reservation Ownership Issues
9 Acknowledgments
I would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu and
Guenther Schaefer for their valuable comments. Additionally I would
like to thank Robert and Jorge for their time to discuss various
issues with me. Furthermore I would like to thank Marc De Vuyst for
his comments to the draft.
Tschofenig Informational - Expires April 2003 32
RSVP Security Properties October 2002
10 References
[BM92] Bellovin, B., Merrit, M.: ˘Encrypted Key Exchange: [BM92] Bellovin, B., Merrit, M.: "Encrypted Key Exchange:
Password-based protocols secure against dictionary attacks÷, in Password-based protocols secure against dictionary attacks", in
˘Proceedings of the IEEE Symposium on Research in Security and "Proceedings of the IEEE Symposium on Research in Security and
Privacy÷, May, 1992. Privacy", May, 1992.
[CA+02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G., [CA+02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G.,
Loughney, J.: "DIAMETER Base Protocol", <draft-ietf-aaa-diameter- Loughney, J.: "DIAMETER Base Protocol", <draft-ietf-aaa-diameter-
15.txt>, (work in progress), October, 2002. 17.txt>, (work in progress), December, 2002.
[DBP96] Dobbertin, H., Bosselaers, A., Preneel, B.: "RIPEMD- [DBP96] Dobbertin, H., Bosselaers, A., Preneel, B.: "RIPEMD-
160: A strengthened version of RIPEMD", in ˘Fast Software Encryption, 160: A strengthened version of RIPEMD", in "Fast Software Encryption,
LNCS Vol 1039, pp. 71-82÷, 1996. LNCS Vol 1039, pp. 71-82", 1996.
[DG96] Davis, D., Geer, D.: ˘Kerberos With Clocks Adrift: [DG96] Davis, D., Geer, D.: "Kerberos With Clocks Adrift:
History, Protocols and Implementation÷, in ˘USENIX Computing Systems History, Protocols and Implementation", in "USENIX Computing Systems
Volume 9 no. 1, Winter÷, 1996. Volume 9 no. 1, Winter", 1996.
[DH95] Ding, Y., Horster, P.: ˘Undetectable On-line Password [DH95] Ding, Y., Horster, P.: "Undetectable On-line Password
Guessing Attacks÷, Operating Systems Review, 29(No. 4), pp. 77-86, Guessing Attacks", Operating Systems Review, 29(No. 4), pp. 77-86,
1995. 1995.
[Dob96] Dobbertin, H.: "The Status of Md5 After a Recent [Dob96] Dobbertin, H.: "The Status of Md5 After a Recent
Attack," RSA Laboratories' CryptoBytes, Volume 2, Number 2, 1996. Attack," RSA Laboratories' CryptoBytes, Volume 2, Number 2, 1996.
[FH+01] Thomas, M., Vilhuber, J.: "Kerberized Internet [FH+01] Thomas, M., Vilhuber, J.: "Kerberized Internet
Negotiation of Keys (KINK)", <draft-ietf-kink-kink-03.txt>, (work in Negotiation of Keys (KINK)", <draft-ietf-kink-kink-05.txt>, (work in
progress), May, 2002. progress), January, 2003.
Tschofenig Informational - Expires September 2003 39
RSVP Security Properties March 2003
[GD+02] Gai, S., Dutt, D., Elfassy, N., Bernet, Y.: "RSVP [GD+02] Gai, S., Dutt, D., Elfassy, N., Bernet, Y.: "RSVP
Proxy", <draft-ietf-rsvp-proxy-03.txt>, (work in progress), March, Proxy", <draft-ietf-rsvp-proxy-03.txt>, (expired), March, 2002.
2002.
[HA01] Hornstein, K., Altman, J.: "Distributing Kerberos KDC [HA01] Hornstein, K., Altman, J.: "Distributing Kerberos KDC
and Realm Information with DNS", <draft-ietf-krb-wg-krb-dns-locate- and Realm Information with DNS", <draft-ietf-krb-wg-krb-dns-locate-
03.txt>, (work in progress), July, 2002. 03.txt>, (work in progress), July, 2002.
[HH01] Hess, R., Herzog, S.: "RSVP Extensions for Policy [HH01] Hess, R., Herzog, S.: "RSVP Extensions for Policy
Control", <draft-ietf-rap-new-rsvp-ext-00.txt>, (expired), June, Control", <draft-ietf-rap-new-rsvp-ext-00.txt>, (expired), June,
2001. 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.
[Jas96] Jaspan, B.: ˘Dual-workfactor Encrypted Key Exchange: [Jas96] Jaspan, B.: "Dual-workfactor Encrypted Key Exchange:
Efficiently Preventing Password Chaining and Dictionary Attacks÷, in Efficiently Preventing Password Chaining and Dictionary Attacks", in
˘Proceedings of the Sixth Annual USENIX Security Conference÷, pp. 43- "Proceedings of the Sixth Annual USENIX Security Conference", pp. 43-
50, July, 1996. 50, July, 1996.
Tschofenig Informational - Expires April 2003 33 [MADS01] "Microsoft Authorization Data Specification v. 1.0 for
RSVP Security Properties October 2002 Microsoft Windows 2000 Operating Systems", April, 2000, available at:
[MADS01] ˘Microsoft Authorization Data Specification v. 1.0 for
Microsoft Windows 2000 Operating Systems÷, April, 2000, available at:
http://www.microsoft.com/technet/security/kerberos/default.asp, http://www.microsoft.com/technet/security/kerberos/default.asp,
February, 2001. February, 2001.
[MHHF01] Malpani, A., Hoffman, P., Housley, R., Freeman, T.: [MHHF01] Malpani, A., Hoffman, P., Housley, R., Freeman, T.:
˘Simple Certificate Validation Protocol (SCVP)÷, <draft-ietf-pkix- "Simple Certificate Validation Protocol (SCVP)", <draft-ietf-pkix-
scvp-09.txt>, (work in progress), June, 2002. scvp-11.txt>, (work in progress), December, 2002.
[MS+02] Manner, J., Suihko, T., Kojo, M., Liljeberg, [MS+02] Manner, J., Suihko, T., Kojo, M., Liljeberg,
M., Raatikainen, K.: "Localized RSVP", <draft-manner-lrsvp-00.txt>, M., Raatikainen, K.: "Localized RSVP", <draft-manner-lrsvp-00.txt>,
(work in progress), May, 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- [PKTSEC] PacketCable Security Specification, PKT-SP-SEC-I01-
991201, Cable Television Laboratories, Inc., December 1, 1999, 991201, Cable Television Laboratories, Inc., December 1, 1999,
http://www.PacketCable.com/. http://www.PacketCable.com/.
[Rae01] Raeburn, K.: "Rijndael, Serpent, and Twofish [Rae01] Raeburn, K.: "Rijndael, Serpent, and Twofish
Cryptosystems for Kerberos 5", <draft-raeburn-krb-rijndael-krb- Cryptosystems for Kerberos 5", <draft-raeburn-krb-rijndael-krb-
01.txt>, (expired), July, 2001. 01.txt>, (expired), July, 2001.
[RF2367] McDonald, D., Metz, C., Phan, B.: ˘PF_KEY Key [RF2367] McDonald, D., Metz, C., Phan, B.: "PF_KEY Key
Management API, Version 2÷, RFC 2367, July, 1998. Management API, Version 2", RFC 2367, July, 1998.
Tschofenig Informational - Expires August 2002 40
RSVP Security Properties March 2003
[RFC1321] Rivest, R.: "The MD5 Message-Digest Algorithm", RFC [RFC1321] Rivest, R.: "The MD5 Message-Digest Algorithm", RFC
1321, April, 1992. 1321, April, 1992.
[RFC1510] Kohl, J., Neuman, C.: "The Kerberos Network [RFC1510] Kohl, J., Neuman, C.: "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993. Authentication 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, [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin,
S.: ńResource ReSerVation Protocol (RSVP) ű Version 1 Functional S.: äResource ReSerVation Protocol (RSVP) ľ Version 1 Functional
Specification˘, RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[RFC2207] Berger, L., OĂMalley, T.: ńRSVP Extensions for IPSEC [RFC2207] Berger, L., OĺMalley, T.: äRSVP Extensions for IPSEC
Data Flows˘, RFC 2207, September 1997. Data Flows", RFC 2207, September 1997.
[RFC2315] Kaliski, B.: " PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B.: " PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March, 1998. Version 1.5", RFC 2315, March, 1998.
[RFC2367] McDonald, D., Metz, C., Phan, B.: "PF_KEY Key [RFC2367] McDonald, D., Metz, C., Phan, B.: "PF_KEY Key
Management API, Version 2", RFC 2367, July, 1998. Management API, Version 2", RFC 2367, July, 1998.
Tschofenig Informational - Expires August 2002 34
RSVP Security Properties October 2002
[RFC2401] Kent, S., Atkinson, R.: "Security Architecture for the [RFC2401] Kent, S., Atkinson, R.: "Security Architecture for the
Internet Protocol", RFC 2401, November, 1998. Internet Protocol", RFC 2401, November, 1998.
[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 [RFC2406] Kent, S., Atkinson, R.: "IP Encapsulating Security
Payload (ESP)", RFC 2406, November, 1998. Payload (ESP)", RFC 2406, November, 1998.
[RFC2409] Harkins, D., Carrel, D.: ˘The Internet Key Exchange [RFC2409] Harkins, D., Carrel, D.: "The Internet Key Exchange
(IKE)÷, RFC 2409, November, 1998. (IKE)", RFC 2409, November, 1998.
[RFC2410] Glenn, R., Kent, S.: "The NULL Encryption Algorithm and [RFC2410] Glenn, R., Kent, S.: "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November, 1998. Its Use With IPsec", RFC 2410, November, 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 [RFC2495] Housley, R., Ford, W., Polk, W., Solo, D.: "Internet
X.509 Public Key Infrastructure Certificate and CRL Profile", RFC X.509 Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January, 1999. 2459, January, 1999.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S.,
Adams, C.: ˘X.509 Internet Public Key Infrastructure Online Adams, C.: "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol ű OCSP÷, RFC 2560, June, 1999. Certificate 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.
[RFC2747] Baker, F., Lindell, B., Talwar, M.: ˘RSVP Cryptographic Tschofenig Informational - Expires August 2002 41
Authentication÷, RC 2747, January, 2000. RSVP Security Properties March 2003
[RFC2747] Baker, F., Lindell, B., Talwar, M.: "RSVP Cryptographic
Authentication", RC 2747, January, 2000.
[RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan,
R., Sastry, A.: ˘The COPS(Common Open Policy Service) Protocol÷, RFC R., 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, [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan,
R., Sastry, A.: ˘COPS usage for RSVP÷, RFC 2749, January, 2000. R., Sastry, A.: "COPS usage for RSVP", RFC 2749, January, 2000.
[RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC [RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC
2750, January, 2000. 2750, January, 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.: [RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.:
"Remote Authentication Dial In User Service (RADIUS)", RFC 2865, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865,
June, 2000. June, 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., Hess, R.: ˘Identity Representation for RSVP÷, RFC T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC
3182, October, 2001. 3182, October, 2001.
[SHA] NIST, FIPS PUB 180-1, "Secure Hash Standard", April, 1995. [SHA] NIST, FIPS PUB 180-1, "Secure Hash Standard", April, 1995.
Tschofenig Informational - Expires August 2002 35
RSVP Security Properties October 2002
[TN+01] Tung, B., Neuman, C., Hur, M., Medvinsky, A., [TN+01] Tung, B., Neuman, C., Hur, M., Medvinsky, A.,
Medvinsky, S., Wray, J., Trostle, J.: ˘Public Key Cryptography for Medvinsky, S., Wray, J., Trostle, J.: "Public Key Cryptography for
Initial Authentication in Kerberos÷, <draft-ietf-cat-kerberos-pk- Initial Authentication in Kerberos", <draft-ietf-cat-kerberos-pk-
init-16.txt>, (work in progress), October, 2001. init-16.txt>, (work in progress), October, 2001.
[Wu98] Wu, T.: ˘The Secure Remote Password Protocol˘, in [Wu98] Wu, T.: "The Secure Remote Password Protocol", in
˘Proceedings of the Internet Society Network and Distributed System "Proceedings of the Internet Society Network and Distributed System
Security Symposium÷, pp. 97-111, March, 1998. Security Symposium", pp. 97-111, March, 1998.
[Wu99] Wu, T.: ˘A Real-World Analysis of Kerberos Password [Wu99] Wu, T.: "A Real-World Analysis of Kerberos Password
Security÷, in ˘Proceedings of the 1999 Network and Distributed System Security", in "Proceedings of the 1999 Network and Distributed System
Security÷, February, 1999. Security", February, 1999.
11 Author's Contact Information [TB+03] H. Tschofenig, M. Buechli, S. Van den Bosch, H.
Schulzrinne: "NSIS Authentication, Authorization and Accounting
Issues", <draft-tschofenig-nsis-aaa-issues-01.txt>, (work in
progress), March, 2003.
[Her95] Herzog, S.: " Accounting and Access Control in RSVP",
<draft-ietf-rsvp-lpm-arch-00.txt>, (expired), November, 1995.
12 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
12 Full Copyright Statement Tschofenig Informational - Expires August 2002 42
RSVP Security Properties March 2003
13 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 are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at line 1956 skipping to change at line 2329
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
Tschofenig Informational - Expires August 2002 36
RSVP Security Properties October 2002
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.
Tschofenig Informational - Expires August 2002 37 Tschofenig Informational - Expires August 2002 43
 End of changes. 

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