idnits 2.17.1
draft-ietf-nsis-rsvp-sec-properties-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1.a on line 18.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 2027.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2004.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2011.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2017.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
This document is an Internet-Draft and is subject to all provisions of
Section 3 of RFC 3667.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 20, 2005) is 6977 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: '16' is defined on line 1736, but no explicit
reference was found in the text
== Unused Reference: '17' is defined on line 1739, but no explicit
reference was found in the text
== Unused Reference: '49' is defined on line 1856, but no explicit
reference was found in the text
== Unused Reference: '50' is defined on line 1861, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
** Obsolete normative reference: RFC 3588 (ref. '9') (Obsoleted by RFC 6733)
-- Possible downref: Non-RFC (?) normative reference: ref. '10'
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
-- Possible downref: Non-RFC (?) normative reference: ref. '13'
-- Possible downref: Non-RFC (?) normative reference: ref. '14'
== Outdated reference: A later version (-34) exists of
draft-ietf-cat-kerberos-pk-init-24
== Outdated reference: A later version (-11) exists of
draft-ietf-kink-kink-06
== Outdated reference: A later version (-33) exists of
draft-ietf-pkix-scvp-11
== Outdated reference: A later version (-04) exists of draft-manner-lrsvp-00
-- No information found for draft-ietf-rsvp-lpm-arch - is the name correct?
-- Duplicate reference: draft-ietf-rap-new-rsvp-ext, mentioned in '49', was
also mentioned in '18'.
Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 21 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NSIS H. Tschofenig
3 Internet-Draft Siemens
4 Expires: August 21, 2005 R. Graveman
5 RFG Security
6 February 20, 2005
8 RSVP Security Properties
9 draft-ietf-nsis-rsvp-sec-properties-06.txt
11 Status of this Memo
13 This document is an Internet-Draft and is subject to all provisions
14 of section 3 of RFC 3667. By submitting this Internet-Draft, each
15 author represents that any applicable patent or other IPR claims of
16 which he or she is aware have been or will be disclosed, and any of
17 which he or she become aware will be disclosed, in accordance with
18 RFC 3668.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as
23 Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on August 21, 2005.
38 Copyright Notice
40 Copyright (C) The Internet Society (2005).
42 Abstract
44 This document summarizes the security properties of RSVP. The goal
45 of this analysis is to benefit from previous work done on RSVP and to
46 capture knowledge about past activities.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
51 2. Terminology and Architectural Assumptions . . . . . . . . . . 4
52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
53 3.1 The RSVP INTEGRITY Object . . . . . . . . . . . . . . . . 6
54 3.2 Security Associations . . . . . . . . . . . . . . . . . . 8
55 3.3 RSVP Key Management Assumptions . . . . . . . . . . . . . 9
56 3.4 Identity Representation . . . . . . . . . . . . . . . . . 9
57 3.5 RSVP Integrity Handshake . . . . . . . . . . . . . . . . . 13
58 4. Detailed Security Property Discussion . . . . . . . . . . . . 15
59 4.1 Network Topology . . . . . . . . . . . . . . . . . . . . . 15
60 4.2 Host/Router . . . . . . . . . . . . . . . . . . . . . . . 15
61 4.3 User to PEP/PDP . . . . . . . . . . . . . . . . . . . . . 19
62 4.4 Communication between RSVP-Aware Routers . . . . . . . . . 26
63 5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 29
64 5.1 First Hop Issue . . . . . . . . . . . . . . . . . . . . . 29
65 5.2 Next-Hop Problem . . . . . . . . . . . . . . . . . . . . . 29
66 5.3 Last-Hop Issue . . . . . . . . . . . . . . . . . . . . . . 32
67 5.4 RSVP and IPsec protected data traffic . . . . . . . . . . 33
68 5.5 End-to-End Security Issues and RSVP . . . . . . . . . . . 35
69 5.6 IPsec protection of RSVP signaling messages . . . . . . . 35
70 5.7 Authorization . . . . . . . . . . . . . . . . . . . . . . 36
71 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37
72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
73 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 40
74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
76 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 42
77 10.2 Informative References . . . . . . . . . . . . . . . . . . . 43
78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45
79 A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . . 47
80 B. Example of User-to-PDP Authentication . . . . . . . . . . . . 48
81 C. Literature on RSVP Security . . . . . . . . . . . . . . . . . 49
82 Intellectual Property and Copyright Statements . . . . . . . . 50
84 1. Introduction
86 As the work of the NSIS working group has begun, there are also
87 concerns about security and its implications for the design of a
88 signaling protocol. In order to understand the security properties
89 and available options of RSVP a number of documents have to be read.
90 This document summarizes the security properties of RSVP and is part
91 of the overall process of analyzing other signaling protocols and
92 learning from their design considerations. This document should also
93 provide a starting point for further discussions.
95 The content of this document is organized as follows:
97 Section 3 provides an overview of the security mechanisms provided by
98 RSVP including the INTEGRITY object, a description of the identity
99 representation within the POLICY_DATA object (i.e., user
100 authentication), and the RSVP Integrity Handshake mechanism. Section
101 4 provides a more detailed discussion of the mechanisms used and
102 tries to describe in detail the mechanisms provided.
104 RSVP also supports multicast but this document does not address
105 security aspects for supporting multicast QoS signaling. Multicast
106 is currently outside the scope of the NSIS working group.
108 Although a variation of RSVP, namely RSVP-TE, is used in the context
109 of MPLS to distribute labels for a label switched path its usage is
110 different than the usage scenarios envisioned for NSIS. Hence, this
111 document does not address RSVP-TE and the security properties of it.
113 2. Terminology and Architectural Assumptions
115 This section describes some important terms and explains some
116 architectural assumptions:
118 Chain-of-Trust:
120 The security mechanisms supported by RSVP [1] heavily rely on
121 optional hop-by-hop protection using the built-in INTEGRITY
122 object. Hop-by-hop security with the INTEGRITY object inside the
123 RSVP message thereby refers to the protection between
124 RSVP-supporting network elements. Additionally, there is the
125 notion of policy-aware network elements that understand the
126 POLICY_DATA element within the RSVP message. Because this element
127 also includes an INTEGRITY object, there is an additional
128 hop-by-hop security mechanism that provides security between
129 policy-aware nodes. Policy-ignorant nodes are not affected by the
130 inclusion of this object in the POLICY_DATA element, because they
131 do not try to interpret it.
133 To protect signaling messages that are possibly modified by each
134 RSVP router along the path, it must be assumed that each incoming
135 request is authenticated, integrity protected, and replay
136 protected. This provides protection against unauthorized nodes'
137 injecting bogus messages. Furthermore, each RSVP-aware router is
138 assumed to behave in the expected manner. Outgoing messages
139 transmitted to the next hop network element receive protection
140 according RSVP security processing.
142 Using the above described mechanisms, a chain-of-trust is created
143 whereby a signaling message transmitted by router A via router B
144 and received by router C is supposed to be secure if routers A and
145 B and routers B and C share security associations and all routers
146 behave as expected. Hence router C trusts router A although
147 router C does not have a direct security association with router
148 A. We can therefore conclude that the protection achieved with
149 this hop-by-hop security for the chain-of-trust is no better than
150 the weakest link in the chain.
152 If one router is malicious (for example because an adversary has
153 control over this router), then it can arbitrarily modify
154 messages, cause unexpected behavior, and mount a number of attacks
155 not limited only to QoS signaling. Additionally, it must be
156 mentioned that some protocols demand more protection than others
157 (which depends in part on which nodes are executing these
158 protocols). For example, edge devices, where end-users are
159 attached, may more likely be attacked in comparison with the more
160 secure core network of a service provider. In some cases a
161 network service provider may choose not to use the RSVP-provided
162 security mechanisms inside the core network because a different
163 security protection is deployed.
165 Section 6 of [2] mentions the term chain-of-trust in the context
166 of RSVP integrity protection. In Section 6 of [18] the same term
167 is used in the context of user authentication with the INTEGRITY
168 object inside the POLICY_DATA element . Unfortunately the term is
169 not explained in detail and the assumptions behind it are not
170 clearly specified.
172 Host and User Authentication:
174 The presence of RSVP protection and a separate user identity
175 representation leads to the fact that both user-identity and
176 host-identity are used for RSVP protection. Therefore, user-based
177 security and host-based security are covered separately, because
178 of the different authentication mechanisms provided. To avoid
179 confusion about the different concepts, Section 3.4 describes the
180 concept of user authentication in more detail.
182 Key Management:
184 It is assumed that most of the security associations required for
185 the protection of RSVP signaling messages are already available,
186 and hence key management was done in advance. There is, however,
187 an exception with respect to support for Kerberos. Using
188 Kerberos, an entity is able to distribute a session key used for
189 RSVP signaling protection.
191 RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
193 RSVP uses an INTEGRITY object in two places in a message. The
194 first is in the RSVP message itself and covers the entire RSVP
195 message as defined in [1]. The second is included in the
196 POLICY_DATA object and defined in [2]. To differentiate the two
197 objects regarding their scope of protection, the two terms RSVP
198 INTEGRITY and POLICY_DATA INTEGRITY object are used, respectively.
199 The data structure of the two objects, however, is the same.
201 Hop versus Peer:
203 In the past, the terminology for nodes addressed by RSVP has been
204 discussed considerably. In particular, two favorite terms have
205 been used: hop and peer. This document uses the term hop, which
206 is different from an IP hop. Two neighboring RSVP nodes
207 communicating with each other are not necessarily neighboring IP
208 nodes (i.e., they may be more than one IP hop away).
210 3. Overview
212 This section describes the security mechanisms provided by RSVP.
213 Although use of IPsec is mentioned in Section 10 of [1], the security
214 mechanisms primarily envisioned for RSVP are described.
216 3.1 The RSVP INTEGRITY Object
218 The RSVP INTEGRITY object is the major component of RSVP security
219 protection. This object is used to provide integrity and replay
220 protection for the content of the signaling message between two RSVP
221 participating routers or between an RSVP router and host.
222 Furthermore, the RSVP INTEGRITY object provides data origin
223 authentication. The attributes of the object are briefly described:
225 Flags field:
227 The Handshake Flag is the only defined flag. It is used to
228 synchronize sequence numbers if the communication gets out of sync
229 (e.g., it allows a restarting host to recover the most recent
230 sequence number). Setting this flag to one indicates that the
231 sender is willing to respond to an Integrity Challenge message.
232 This flag can therefore be seen as a negotiation capability
233 transmitted within each INTEGRITY object.
235 Key Identifier:
237 The Key Identifier selects the key used for verification of the
238 Keyed Message Digest field and, hence, must be unique for the
239 sender. It has a fixed 48-bit length. The generation of this Key
240 Identifier field is mostly a decision of the local host. [1]
241 describes this field as a combination of an address, sending
242 interface, and key number. We assume that the Key Identifier is
243 simply a (keyed) hash value computed over a number of fields with
244 the requirement to be unique if more than one security association
245 is used in parallel between two hosts (e.g., as is the case with
246 security associations having overlapping lifetimes). A receiving
247 system uniquely identifies a security association based on the Key
248 Identifier and the sender's IP address. The sender's IP address
249 may be obtained from the RSVP_HOP object or from the source IP
250 address of the packet if the RSVP_HOP object is not present. The
251 sender uses the outgoing interface to determine which security
252 association to use. The term outgoing interface may be confusing.
253 The sender selects the security association based on the
254 receiver's IP address (i.e., the address of the next RSVP-capable
255 router). The process of determining which node is the next
256 RSVP-capable router is not further specified and is likely to be
257 statically configured.
259 Sequence Number:
261 The sequence number used by the INTEGRITY object is 64 bits in
262 length, and the starting value can be selected arbitrarily. The
263 length of the sequence number field was chosen to avoid exhaustion
264 during the lifetime of a security association as stated in Section
265 3 of [1]. In order for the receiver to distinguish between a new
266 and a replayed message, the sequence number must be monotonically
267 incremented modulo 2^64 for each message. We assume that the
268 first sequence number seen (i.e., the starting sequence number) is
269 stored somewhere. The modulo-operation is required because the
270 starting sequence number may be an arbitrary number. The receiver
271 therefore only accepts packets with a sequence number larger
272 (modulo 2^64) than the previous packet. As explained in [1] this
273 process is started by handshaking and agreeing on an initial
274 sequence number. If no such handshaking is available then the
275 initial sequence number must be part of the establishment of the
276 security association.
278 The generation and storage of sequence numbers is an important
279 step in preventing replay attacks and is largely determined by the
280 capabilities of the system in presence of system crashes, failures
281 and restarts. Section 3 of [1] explains some of the most
282 important considerations. However, the description of how the
283 receiver distinguishes proper from improper sequence numbers is
284 incomplete--it implicitly assumes that gaps large enough to cause
285 the sequence number to wrap around cannot occur.
287 If delivery in order were guaranteed, the following procedure
288 would work: The receiver keeps track of the first sequence number
289 received, INIT-SEQ, and most recent sequence number received,
290 LAST-SEQ, for each key identifier in a security association. When
291 the first message is received, set INIT-SEQ = LAST-SEQ = value
292 received and accept. When a subsequent message is received, if
293 its sequence number is strictly between LAST-SEQ and INIT-SEQ,
294 modulo 2^64, accept and update LAST-SEQ with the value just
295 received. If it is between INIT-SEQ and LAST-SEQ, inclusive,
296 modulo 2^64, reject and leave the value of LAST-SEQ unchanged.
297 Because delivery in order is not guaranteed, the above rules need
298 to be combined with a method of allowing a fixed sized window in
299 the neighborhood of LAST-SEQ for out-of-order delivery, for
300 example, as described in Appendix C of [3].
302 Keyed Message Digest:
304 The Keyed Message Digest is a security mechanism built into RSVP
305 and used to provide integrity protection of a signaling message
306 (including its sequence number). Prior to computing the value for
307 the Keyed Message Digest field, the Keyed Message Digest field
308 itself must be set to zero and a keyed hash computed over the
309 entire RSVP packet. The Keyed Message Digest field is variable in
310 length but must be a multiple of four octets. If HMAC-MD5 is
311 used, then the output value is 16 bytes long. The keyed hash
312 function HMAC-MD5 [4] is required for a RSVP implementation as
313 noted in Section 1 of [1]. Hash algorithms other than MD5 [5]
314 like SHA-1 [19] may also be supported.
316 The key used for computing this Keyed Message Digest may be
317 obtained from the pre-shared secret, which is either manually
318 distributed or the result of a key management protocol. No key
319 management protocol, however, is specified to create the desired
320 security associations. Also, no guidelines for key length are
321 given. It should be recommended that HMAC-MD5 keys be 128 bits
322 and SHA-1 key 160 bits, as in IPsec AH [20] and ESP [21].
324 3.2 Security Associations
326 Different attributes are stored for security associations of sending
327 and receiving systems (i.e., unidirectional security associations).
328 The sending system needs to maintain the following attributes in such
329 a security association [1]:
331 o Authentication algorithm and algorithm mode
332 o Key
333 o Key Lifetime
334 o Sending Interface
335 o Latest sequence number (received with this key identifier)
337 The receiving system has to store the following fields:
339 o Authentication algorithm and algorithm mode
340 o Key
341 o Key Lifetime
342 o Source address of the sending system
343 o List of last n sequence numbers (received with this key
344 identifier)
346 Note that the security associations need to have additional fields to
347 indicate their state. It is necessary to have an overlapping
348 lifetime of security associations to avoid interrupting an ongoing
349 communication because of expired security associations. During such
350 a period of overlapping lifetime it is necessary to authenticate
351 either one or both active keys. As mentioned in [1], a sender and a
352 receiver may have multiple active keys simultaneously.If more than
353 one algorithm is supported then the algorithm used must be specified
354 for a security association.
356 3.3 RSVP Key Management Assumptions
358 [6] assumes that security associations are already available. An
359 implementation must support manual key distribution as noted in
360 Section 5.2 of [1]. Manual key distribution, however, has different
361 requirements for key storage - a simple plaintext ASCII file may be
362 sufficient in some cases. If multiple security associations with
363 different lifetimes need to be supported at the same time, then a key
364 engine would be more appropriate. Further security requirements
365 listed in Section 5.2 of [1] are the following:
367 o The manual deletion of security associations must be supported.
368 o The key storage should persist a system restart.
369 o Each key must be assigned a specific lifetime and a specific Key
370 Identifier.
372 3.4 Identity Representation
374 In addition to host-based authentication with the INTEGRITY object
375 inside the RSVP message, user-based authentication is available as
376 introduced in [2]. Section 2 of [7] states that "Providing policy
377 based admission control mechanism based on user identities or
378 application is one of the prime requirements." To identify the user
379 or the application, a policy element called AUTH_DATA, which is
380 contained in the POLICY_DATA object, is created by the RSVP daemon at
381 the user's host and transmitted inside the RSVP message. The
382 structure of the POLICY_DATA element is described in [2]. Network
383 nodes like the policy decision point (PDP) then use the information
384 contained in the AUTH_DATA element to authenticate the user and to
385 allow policy-based admission control to be executed. As mentioned in
386 [7], the policy element is processed and the PDP replaces the old
387 element with a new one for forwarding to the next hop router.
389 A detailed description of the POLICY_DATA element can be found in
390 [2]. The attributes contained in the authentication data policy
391 element AUTH_DATA, which is defined in [7], are briefly explained in
392 this Section. Figure 1 shows the abstract structure of the RSVP
393 message with its security-relevant objects and the scope of
394 protection. The RSVP INTEGRITY object (outer object) covers the
395 entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
396 covers objects within the POLICY_DATA element.
398 +--------------------------------------------------------+
399 | RSVP Message |
400 +--------------------------------------------------------+
401 | Object |POLICY_DATA Object ||
402 | +-------------------------------------------+|
403 | | INTEGRITY +------------------------------+||
404 | | Object | AUTH_DATA Object |||
405 | | +------------------------------+||
406 | | | Various Authentication |||
407 | | | Attributes |||
408 | | +------------------------------+||
409 | +-------------------------------------------+|
410 +--------------------------------------------------------+
412 Figure 1: Security Relevant Objects and Elements within the RSVP
413 Message
415 The AUTH_DATA object contains information for identifying users and
416 applications together with credentials for those identities. The
417 main purpose of these identities seems to be usage for policy-based
418 admission control and not authentication and key management. As
419 noted in Section 6.1 of [7], an RSVP message may contain more than
420 one POLICY_DATA object and each of them may contain more than one
421 AUTH_DATA object. As indicated in Figure 1 and in [7], one AUTH_DATA
422 object may contain more than one authentication attribute. A typical
423 configuration for Kerberos-based user authentication includes at
424 least the Policy Locator and an attribute containing the Kerberos
425 session ticket.
427 Successful user authentication is the basis for executing
428 policy-based admission control. Additionally, other information such
429 as time-of-day , application type, location information, group
430 membership, etc. may be relevant to implement an access control
431 policy.
433 The following attributes are defined for the usage in the AUTH_DATA
434 object:
436 1. Policy Locator
437 * ASCII_DN
438 * UNICODE_DN
439 * ASCII_DN_ENCRYPT
440 * UNICODE_DN_ENCRYPT
441 The policy locator string that is an X.500 distinguished name
442 (DN) used to locate user or application specific policy
443 information. The following types of X.500 DNs are listed:
444 The first two types are the ASCII and the Unicode representation
445 of the user or application DN identity. The two "encrypted"
446 distinguished name types are either encrypted with the Kerberos
447 session key or with the private key of the user's digital
448 certificate (i.e., digitally signed). The term encrypted
449 together with a digital signature is easy to misconceive. If
450 user identity confidentiality is provided, then the policy
451 locator has to be encrypted with the public key of the recipient.
452 How to obtain this public key is not described in the document.
453 Such an issue may be specified in a concrete architecture where
454 RSVP is used.
455 2. Credentials
456 Two cryptographic credentials are currently defined for a user:
457 Authentication with Kerberos V5 [8], and authentication with the
458 help of digital signatures based on X.509 [22] and PGP [23]. The
459 following list contains all defined credential types currently
460 available and defined in [7]:
462 +--------------+--------------------------------+
463 | Credential | Description |
464 | Type | |
465 +===============================================|
466 | ASCII_ID | User or application identity |
467 | | encoded as an ASCII string |
468 +--------------+--------------------------------+
469 | UNICODE_ID | User or application identity |
470 | | encoded as a Unicode string |
471 +--------------+--------------------------------+
472 | KERBEROS_TKT | Kerberos V5 session ticket |
473 +--------------+--------------------------------+
474 | X509_V3_CERT | X.509 V3 certificate |
475 +--------------+--------------------------------+
476 | PGP_CERT | PGP certificate |
477 +--------------+--------------------------------+
479 Figure 2: Credentials Supported in RSVP
481 The first two credentials contain only a plaintext string, and
482 therefore they do not provide cryptographic user authentication.
483 These plaintext strings may be used to identify applications,
484 which are included for policy-based admission control. Note that
485 these plain-text identifiers may, however, be protected if either
486 the RSVP INTEGRITY or the INTEGRITY object of the POLICY_DATA
487 element is present. Note that the two INTEGRITY objects can
488 terminate at different entities depending on the network
489 structure. The digital signature may also provide protection of
490 application identifiers. A protected application identity (and
491 the entire content of the POLICY_DATA element) cannot be modified
492 as long as no policy ignorant nodes are encountered in between.
493 A Kerberos session ticket, as previously mentioned, is the ticket
494 of a Kerberos AP_REQ message [8] without the Authenticator.
495 Normally, the AP_REQ message is used by a client to authenticate
496 to a server. The INTEGRITY object (e.g., of the POLICY_DATA
497 element) provides the functionality of the Kerberos
498 Authenticator, namely protecting against replay and showing that
499 the user was able to retrieve the session key following the
500 Kerberos protocol. This is, however, only the case if the
501 Kerberos session was used for the keyed message digest field of
502 the INTEGRITY object. Section 7 of [1] discusses some issues for
503 establishment of keys for the INTEGRITY object. The
504 establishment of the security association for the RSVP INTEGRITY
505 object with the inclusion of the Kerberos Ticket within the
506 AUTH_DATA element may be complicated by the fact that the ticket
507 can be decrypted by node B whereas the RSVP INTEGRITY object
508 terminates at a different host C. The Kerberos session ticket
509 contains, among many other fields, the session key. The Policy
510 Locator may also be encrypted with the same session key. The
511 protocol steps that need to be executed to obtain such a Kerberos
512 service ticket are not described in [7] and may involve several
513 roundtrips depending on many Kerberos-related factors. The
514 Kerberos ticket does not need to be included in every RSVP
515 message as an optimization, as described in Section 7.1 of [1].
516 Thus the receiver must store the received service ticket. If the
517 lifetime of the ticket has expired, then a new service ticket
518 must be sent. If the receiver lost its state information
519 (because of a crash or restart) then it may transmit an Integrity
520 Challenge message to force the sender to re-transmit a new
521 service ticket.
522 If either the X.509 V3 or the PGP certificate is included in the
523 policy element, then a digital signature must be added. The
524 digital signature computed over the entire AUTH_DATA object
525 provides authentication and integrity protection. The SubType of
526 the digital signature authentication attribute is set to zero
527 before computing the digital signature. Whether or not a
528 guarantee of freshness with replay protection (either timestamps
529 or sequence numbers) is provided by the digital signature is an
530 open issue as discussed in Section 4.3
531 3. Digital Signature
532 The digital signature computed over the data of the AUTH_DATA
533 object must be the last attribute. The algorithm used to compute
534 the digital signature depends on the authentication mode listed
535 in the credential. This is only partially true, because, for
536 example, PGP again allows different algorithms to be used for
537 computing a digital signature. The algorithm identifier used for
538 computing the digital signature is not included in the
539 certificate itself. The algorithm identifier included in the
540 certificate only serves the purpose of allowing the verification
541 of the signature computed by the certificate authority (except
542 for the case of self-signed certificates).
543 4. Policy Error Object
544 The Policy Error Object is used in the case of a failure of
545 policy-based admission control or other credential verification.
546 Currently available error messages allow notification if the
547 credentials are expired (EXPIRED_CREDENTIALS), if the
548 authorization process disallowed the resource request
549 (INSUFFICIENT_PRIVILEGES), or if the given set of credentials is
550 not supported (UNSUPPORTED_CREDENTIAL_TYPE). The last error
551 message returned by the network allows the user's host to
552 discover the type of credentials supported. Particularly for
553 mobile environments this might be quite inefficient.
554 Furthermore, it is unlikely that a user supports different types
555 of credentials. The purpose of the error message
556 IDENTITY_CHANGED is unclear. Also, the protection of the error
557 message is not discussed in [7].
559 3.5 RSVP Integrity Handshake
561 The Integrity Handshake protocol was designed to allow a crashed or
562 restarted host to obtain the latest valid challenge value stored at
563 the receiving host. Due to the absence of key management, it must be
564 guaranteed that two messages do not use the same sequence number with
565 the same key. A host stores the latest sequence number of a
566 cryptographically verified message. An adversary can replay
567 eavesdropped packets if the crashed host has lost its sequence
568 numbers. A signaling message from the real sender with a new
569 sequence number would therefore allow the crashed host to update the
570 sequence number field and prevent further replays. Hence, if there
571 is a steady flow of RSVP protected messages between the two hosts, an
572 attacker may find it difficult to inject old messages, because new,
573 authenticated messages with higher sequence numbers arrive and get
574 stored immediately.
576 The following description explains the details of a RSVP Integrity
577 Handshake that is started by Node A after recovering from a
578 synchronization failure:
580 Integrity Challenge
582 (1) Message (including
583 +----------+ a Cookie) +----------+
584 | |-------------------------->| |
585 | Node A | | Node B |
586 | |<--------------------------| |
587 +----------+ Integrity Response +----------+
588 (2) Message (including
589 the Cookie and the
590 INTEGRITY object)
592 Figure 3: RSVP Integrity Handshake
594 The details of the messages are as follows:
596 CHALLENGE:=(Key Identifier, Challenge Cookie)
597 Integrity Challenge Message:=(Common Header, CHALLENGE)
598 Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
600 The "Challenge Cookie" is suggested to be a MD5 hash of a local
601 secret and a timestamp [1].
603 The Integrity Challenge message is not protected with an INTEGRITY
604 object as shown in the protocol flow above. As explained in Section
605 10 of [1] this was done to avoid problems in situations where both
606 communicating parties do not have a valid starting sequence number.
608 Using the RSVP Integrity Handshake protocol is recommended although
609 it is not mandatory (since it may not be needed in all network
610 environments).
612 4. Detailed Security Property Discussion
614 The purpose of this section is to describe the protection of the
615 RSVP-provided mechanisms individually for authentication,
616 authorization, integrity and replay protection, user identity
617 confidentiality, and confidentiality of the signaling messages.
619 4.1 Network Topology
621 The main purpose of this paragraph is to show the basic interfaces in
622 a simple RSVP network architecture. The architecture below assumes
623 that there is only a single domain and that two routers are RSVP and
624 policy aware. These assumptions are relaxed in the individual
625 paragraphs as necessary. Layer 2 devices between the clients and
626 their corresponding first hop routers are not shown. Other network
627 elements like a Kerberos Key Distribution Center and for example a
628 LDAP server, from which the PDP retrieves its policies are also
629 omitted. The security of various interfaces to the individual
630 servers (KDC, PDP, etc.) depends very much on the security policy of
631 a specific network service provider.
633 +--------+
634 | Policy |
635 +----|Decision|
636 | | Point +---+
637 | +--------+ |
638 | |
639 | |
640 +------+ +-+----+ +---+--+ +------+
641 |Client| |Router| |Router| |Client|
642 | A +-------+ 1 +--------+ 2 +----------+ B |
643 +------+ +------+ +------+ +------+
645 Figure 4: Simple RSVP Architecture
647 4.2 Host/Router
649 When considering authentication in RSVP it is important to make a
650 distinction between user and host authentication of the signaling
651 messages . By using the RSVP INTEGRITY object the host is
652 authenticated while credentials inside the AUTH_DATA object can be
653 used to authenticate the user. In this section the focus is on host
654 authentication whereas the next section covers user authentication.
656 1. Authentication
657 The term host authentication is used above, because the selection
658 of the security association is bound to the host's IP address as
659 mentioned in Section 3.1. and Section 3.2. Depending on the key
660 management protocol used to create this security association and
661 the identity used, it is also possible to bind a user identity to
662 this security association. Because the key management protocol
663 is not specified, it is difficult to evaluate this part and hence
664 we speak about data origin authentication based on the host's
665 identity for RSVP INTEGRITY objects. The fact that the host
666 identity is used for selecting the security association has
667 already been described in Section 3.1.
668 Data origin authentication is provided with the keyed hash value
669 computed over the entire RSVP message excluding the keyed message
670 digest field itself. The security association used between the
671 user's host and the first-hop router is, as previously mentioned,
672 not established by RSVP and must therefore be available before
673 signaling is started.
674 * Kerberos for the RSVP INTEGRITY object
675 As described in Section 7 of [1], Kerberos may be used to create
676 the key for the RSVP INTEGRITY object. How to learn the
677 principal name (and realm information) of the other node is
678 outside the scope of [1]. [24] describes a way to distribute
679 principal and realm information via DNS, which can be used for
680 this purpose (assuming that the FQDN or the IP address of the
681 other node for which this information is desired is known). All
682 that is required is to encapsulate the Kerberos ticket inside the
683 policy element. It is furthermore mentioned that Kerberos
684 tickets with expired lifetime must not be used and the initiator
685 is responsible for requesting and exchanging a new service ticket
686 before expiration.
687 RSVP multicast processing in combination with Kerberos requires
688 additional considerations:
689 Section 7 of [1] states that in the multicast case all receivers
690 must share a single key with the Kerberos Authentication Server,
691 i.e., a single principal used for all receivers). From a
692 personal discussion with Rodney Hess it seems that there is
693 currently no other solution available in the context of Kerberos.
694 Multicast handling therefore leaves some open questions in this
695 context.
696 In the case where one entity crashed, the established security
697 association is lost and therefore the other node must retransmit
698 the service ticket . The crashed entity can use an Integrity
699 Challenge message to request a new Kerberos ticket to be
700 retransmitted by the other node. If a node receives such a
701 request, then a reply message must be returned.
702 2. Integrity protection
703 Integrity protection between the user's host and the first hop
704 router is based on the RSVP INTEGRITY object. HMAC-MD5 is
705 preferred, although other keyed hash functions may also be used
706 within the RSVP INTEGRITY object. In any case, both
707 communicating entities must have a security association that
708 indicates the algorithm to use. This may, however, be difficult,
709 because no negotiation protocol is defined to agree on a specific
710 algorithm. Hence, if RSVP is used in a mobile environment, it is
711 likely that HMAC-MD5 is the only usable algorithm for the RSVP
712 INTEGRITY object. Only in local environments may it be useful to
713 switch to a different keyed hash algorithm. The other possible
714 alternative is that every implementation must support the most
715 important keyed hash algorithms for example MD5, SHA-1,
716 RIPEMD-160, etc. HMAC-MD5 was mainly chosen because of its
717 performance characteristics. The weaknesses of MD5 [25] are
718 known and described in [26]. Other algorithms like SHA-1 [19]
719 and RIPEMD-160 [25] have stronger security properties.
720 3. Replay Protection
721 The main mechanism used for replay protection in RSVP is based on
722 sequence numbers, whereby the sequence number is included in the
723 RSVP INTEGRITY object. The properties of this sequence number
724 mechanism are described in Section 3.1. The fact that the
725 receiver stores a list of sequence numbers is an indicator for a
726 window mechanism. This somehow conflicts with the requirement
727 that the receiver only has to store the highest number given in
728 Section 3 of [1]. We assume that this is a typo. Section 4.2 of
729 [1] gives a few comments about the out-of-order delivery and the
730 ability of an implementation to specify the replay window.
731 Appendix C of [3] describes a window mechanism for handling
732 out-of-sequence delivery.
733 4. Integrity Handshake
734 The mechanism of the Integrity Handshake is explained in Section
735 Section 3.5. The Cookie value is suggested to be hash of a local
736 secret and a timestamp. The Cookie value is not verified by the
737 receiver. The mechanism used by the Integrity Handshake is a
738 simple Challenge/Response message, which assumes that the key
739 shared between the two hosts survives the crash. If, however,
740 the security association is dynamically created, then this
741 assumption may not be true.
742 In Section 10 of [1] the authors note that an adversary can
743 create a faked Integrity Handshake message including challenge
744 cookies. Subsequently it could store the received response and
745 later try to replay these responses while a responder recovers
746 from a crash or restart. If this replayed Integrity Response
747 value is valid and has a lower sequence number than actually
748 used, then this value is stored at the recovering host. In order
749 for this attack to be successful the adversary must either have
750 collected a large number of challenge/response value pairs or
751 have "discovered" the cookie generation mechanism (for example by
752 knowing the local secret). The collection of Challenge/Response
753 pairs is even more difficult, because they depend on the Cookie
754 value, the sequence number included in the response message, and
755 the shared key used by the INTEGRITY object.
756 5. Confidentiality
757 Confidentiality is not considered to be a security requirement
758 for RSVP. Hence it is not supported by RSVP, except as described
759 in paragraph d) of Section 4.3. This assumption may not hold,
760 however, for enterprises or carriers who want to protect, in
761 addition to users' identities, also billing data, network usage
762 patterns, or network configurations from eavesdropping and
763 traffic analysis. Confidentiality may also help make certain
764 other attacks more difficult. For example, the PathErr attack
765 described in Section 5.2 is harder to carry out if the attacker
766 cannot observe the Path message to which the PathErr corresponds.
767 6. Authorization
768 The task of authorization consists of two subcategories: network
769 access authorization and RSVP request authorization. Access
770 authorization is provided when a node is authenticated to the
771 network, e.g., using EAP [27] in combination with AAA protocols
772 (for example using RADIUS [28] or DIAMETER [9]). Issues related
773 to network access authentication and authorization are outside
774 the scope of RSVP.
775 The second authorization refers to RSVP itself. Depending on the
776 network configuration:
777 * the router either forwards the received RSVP request to the
778 policy decision point, e.g., by using COPS [10] and [11],to
779 request that an admission control procedure be executed or
780 * the router supports the functionality of a PDP and therefore
781 there is no need to forward the request or
782 * the router may already be configured with the appropriate
783 policy information to decide locally whether to grant this
784 request or not
785 Based on the result of the admission control, the request may be
786 granted or rejected. Information about the resource-requesting
787 entity must be available to provide policy-based admission
788 control.
789 7. Performance
790 The computation of the keyed message digest for a RSVP INTEGRITY
791 object does not represent a performance problem. The protection
792 of signaling messages is usually not a problem, because these
793 messages are transmitted at a low rate. Even a high volume of
794 messages does not cause performance problems for a RSVP routers
795 due to the efficiency of the keyed message digest routine.
796 Dynamic key management, which is computationally more demanding,
797 is more important for scalability. Because RSVP does not specify
798 a particular key exchange protocol, it is difficult to estimate
799 the effort to create the required security associations.
800 Furthermore, the number of key exchanges to be triggered depends
801 on security policy issues like lifetime of a security
802 association, required security properties of the key exchange
803 protocol, authentication mode used by the key exchange protocol,
804 etc. In a stationary environment with a single administrative
805 domain, manual security association establishment may be
806 acceptable and may provide the best performance characteristics.
807 In a mobile environment, asymmetric authentication methods are
808 likely to be used with a key exchange protocol, and some sort of
809 public key or certificate verification needs to be supported.
811 4.3 User to PEP/PDP
813 As noted in the previous section, both user-based and host-based
814 authentication are supported by RSVP. Using RSVP, a user may
815 authenticate to the first hop router or to the PDP as specified in
816 [1], depending on the infrastructure provided by the network domain
817 or the architecture used (e.g., the integration of RSVP and Kerberos
818 V5 into the Windows 2000 Operating System [29]. Another architecture
819 in which RSVP is tightly integrated is the one specified by the
820 PacketCable organization. The interested reader is referred to [30]
821 for a discussion of their security architecture.
823 1. Authentication
824 When a user sends a RSVP PATH or RESV message, this message may
825 include some information to authenticate the user. [7] describes
826 how user and application information is embedded into the RSVP
827 message (AUTH_DATA object) and how to protect it. A router
828 receiving such a message can use this information to authenticate
829 the client and forward the user or application information to the
830 policy decision point (PDP). Optionally the PDP itself can
831 authenticate the user, which is described in the next section.
832 To be able to authenticate the user, to verify the integrity, and
833 to check for replays, the entire POLICY_DATA element has to be
834 forwarded from the router to the PDP, e.g., by including the
835 element into a COPS message. It is assumed, although not clearly
836 specified in [7], that the INTEGRITY object within the
837 POLICY_DATA element is sent to the PDP along with all other
838 attributes.
839 * Certificate Verification
840 Using the policy element as described in [7] it is not possible
841 to provide a certificate revocation list or other information to
842 prove the validity of the certificate inside the policy element.
843 A specific mechanism for certificate verification is not
844 discussed in [7] and hence a number of them can be used for this
845 purpose. For certificate verification, the network element (a
846 router or the policy decision point), which has to authenticate
847 the user, could frequently download certificate revocation lists
848 or use a protocol like the Online Certificate Status Protocol
849 (OCSP) [31] and the Simple Certificate Validation Protocol (SCVP)
851 [32] to determine the current status of a digital certificate.
852 * User Authentication to the PDP
853 This alternative authentication procedure uses the PDP to
854 authenticate the user instead of the first hop router. In
855 Section 4.2.1 of [7] the choice is given for the user to obtain a
856 session ticket either for the next hop router or for the PDP. As
857 noted in the same Section, the identity of the PDP or the next
858 hop router is statically configured or dynamically retrieved.
859 Subsequently, user authentication to the PDP is considered.
860 * Kerberos-based Authentication to the PDP
861 If Kerberos is used to authenticate the user, then a session
862 ticket for the PDP needs to be requested first. A user who roams
863 between different routers in the same administrative domain does
864 not need to request a new service ticket, because the PDP is
865 likely to be used by most or all first-hop routers within the
866 same administrative domain. This is different from the case in
867 which a session ticket for a router has to be obtained and
868 authentication to a router is required. The router therefore
869 plays a passive role of forwarding the request only to the PDP
870 and executing the policy decision returned by the PDP.
871 Appendix B describes one example of user-to-PDP authentication.
872 User authentication with the policy element only provides
873 unilateral authentication whereby the client authenticates to the
874 router or to the PDP. If a RSVP message is sent to the user's
875 host and public key based authentication is used, then the
876 message does not contain a certificate and digital signature.
877 Hence no mutual authentication can be assumed. In case of
878 Kerberos, mutual authentication may be accomplished if the PDP or
879 the router transmits a policy element with an INTEGRITY object
880 computed with the session key retrieved from the Kerberos ticket
881 or if the Kerberos ticket included in the policy element is also
882 used for the RSVP INTEGRITY object as described in Section 4.2.
883 This procedure only works if a previous message was transmitted
884 from the end host to the network and such key is already
885 established. [7] does not discuss this issue and therefore there
886 is no particular requirement dealing with transmitting
887 network-specific credentials back to the end-user's host.
888 2. Integrity Protection
889 Integrity protection is applied separately to the RSVP message
890 and the POLICY_DATA element as shown in Figure 1. In case of a
891 policy-ignorant node along the path, the RSVP INTEGRITY object
892 and the INTEGRITY object inside the policy element terminate at
893 different nodes. Basically, the same is true for the user
894 credentials if they are verified at the policy decision point
895 instead of the first hop router.
896 * Kerberos
897 If Kerberos is used to authenticate the user to the first hop
898 router, then the session key included in the Kerberos ticket may
899 be used to compute the INTEGRITY object of the policy element.
900 It is the keyed message digest that provides the authentication.
901 The existence of the Kerberos service ticket inside the AUTH_DATA
902 object does not provide authentication and a guarantee of
903 freshness for the receiving host. Authentication and guarantee
904 of freshness are provided by the keyed hash value of the
905 INTEGRITY object inside the POLICY_DATA element. This shows that
906 the user actively participated in the Kerberos protocol and was
907 able to obtain the session key to compute the keyed message
908 digest. The Authenticator used in the Kerberos V5 protocol
909 provides similar functionality, but replay protection is based on
910 timestamps (or on a sequence number if the optional seq-number
911 field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
912 messages as described in Section 5.3.2 of [8]).
913 * Digital Signature
914 If public key based authentication is provided, then user
915 authentication is accomplished with a digital signature. As
916 explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE
917 attribute must be the last attribute in the AUTH_DATA object, and
918 the digital signature covers the entire AUTH_DATA object. Which
919 hash algorithm and public key algorithm are used for the digital
920 signature computation is described in [23] in the case of PGP.
921 In the case of X.509 credentials the situation is more complex,
922 because different mechanisms like CMS [33] or PKCS#7 [34] may be
923 used for digitally signing the message element. X.509 only
924 provides the standard for the certificate layout, which seems to
925 provide insufficient information for this purpose. Therefore,
926 X.509 certificates are supported for example by CMS and PKCS#7.
927 [7], however, does not make any statements about the usage of CMS
928 and PKCS#7. Currently there is no support for CMS or PKCS#7
929 described in [7], which provides more than just public key based
930 authentication (e.g., CRL distribution, key transport, key
931 agreement, etc.). Furthermore, the use of PGP in RSVP is vaguely
932 defined, because there are different versions of PGP (including
933 OpenPGP [23]), and no indication is given as to which should be
934 used.
935 Supporting public key based mechanisms in RSVP might increase the
936 risks of denial of service attacks. Additionally, the large
937 processing, memory, and bandwidth utilization should be
938 considered. Fragmentation might also be an issue here.
939 If the INTEGRITY object is not included in the POLICY_DATA
940 element or not sent to the PDP, then we have to make the
941 following observations:
942 3. For the digital signature case, only the replay protection
943 provided by the digital signature algorithm can be used. It
944 is not clear, however, whether this usage was anticipated or
945 not. Hence, we might assume that replay protection is based
946 on the availability of the RSVP INTEGRITY object used with a
947 security association that is established by other means.
948 4. Including only the Kerberos session ticket is insufficient,
949 because freshness is not provided (since the Kerberos
950 Authenticator is missing). Obviously there is no guarantee
951 that the user actually followed the Kerberos protocol and was
952 able to decrypt the received TGS_REP (or in rare cases the
953 AS_REP if a session ticket is requested with the initial
954 AS_REQ).
955 5. Replay Protection
956 Figure 5 shows the interfaces relevant for replay protection
957 of signaling messages in a more complicated architecture. In
958 this case, the client uses the policy data element with PEP2,
959 because PEP1 is not policy aware. The interfaces between the
960 client and PEP1 and between PEP1 and PEP2 are protected with
961 the RSVP INTEGRITY object. The link between the PEP2 and the
962 PDP is protected, for example, by using the COPS built-in
963 INTEGRITY object. The dotted line between the Client and the
964 PDP indicates the protection provided by the AUTH_DATA
965 element, which has no RSVP INTEGRITY object included.
967 AUTH_DATA +----+
968 +---------------------------------------------------+PDP +-+
969 | +----+ |
970 | |
971 | |
972 | COPS |
973 | INTEGRITY|
974 | |
975 | |
976 | |
977 +--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
978 |Client+-------------------+PEP1+----------------------+PEP2+-+
979 +--+---+ +----+ +-+--+
980 | |
981 +-----------------------------------------------------+
982 POLICY_DATA INTEGRITY
984 Figure 5: Replay Protection
986 Host authentication with the RSVP INTEGRITY object and user
987 authentication with the INTEGRITY object inside the
988 POLICY_DATA element both use the same anti-replay mechanism.
989 The length of the Sequence Number field, sequence number
990 rollover, and the Integrity Handshake have already been
991 explained in Section 3.1.
992 Section 9 of [7] states: "RSVP INTEGRITY object is used to
993 protect the policy object containing user identity
994 information from security (replay) attacks." When using
995 public key based authentication, RSVP based replay protection
996 is not supported, because the digital signature does not
997 cover the POLICY_DATA INTEGRITY object with its Sequence
998 Number field. The digital signature covers only the entire
999 AUTH_DATA object.
1000 The use of public key cryptography within the AUTH_DATA
1001 object complicates replay protection. Digital signature
1002 computation with PGP is described in [35] and in [23]. The
1003 data structure preceding the signed message digest includes
1004 information about the message digest algorithm used and a
1005 32-bit timestamp of when the signature was created
1006 ("Signature creation time"). The timestamp is included in
1007 the computation of the message digest. The IETF standardized
1008 OpenPGP version [23] contains more information and describes
1009 the different hash algorithms (MD2, MD5, SHA-1, RIPEMD-160)
1010 supported. [7] does not make any statements as to whether
1011 the "Signature creation time" field is used for replay
1012 protection. Using timestamps for replay protection requires
1013 different synchronization mechanisms in the case of
1014 clock-skew. Traditionally, these cases assume "loosely
1015 synchronized" clocks but also require specifying a
1016 replay-window.
1017 If the "Signature creation time" is not used for replay
1018 protection, then a malicious, policy-ignorant node can use
1019 this weakness to replace the AUTH_DATA object without
1020 destroying the digital signature. If this was not simply an
1021 oversight, it is therefore assumed that replay protection of
1022 the user credentials was not considered an important security
1023 requirement, because the hop-by-hop processing of the RSVP
1024 message protects the message against modification by an
1025 adversary between two communicating nodes.
1026 The lifetime of the Kerberos ticket is based on the fields
1027 starttime and endtime of the EncTicketPart structure in the
1028 ticket, as described in Section 5.3.1 of [8]. Because the
1029 ticket is created by the KDC located at the network of the
1030 verifying entity, it is not difficult to have the clocks
1031 roughly synchronized for the purpose of lifetime
1032 verification. Additional information about
1033 clock-synchronization and Kerberos can be found in [36].
1034 If the lifetime of the Kerberos ticket expires, then a new
1035 ticket must be requested and used. Rekeying is implemented
1036 with this procedure.
1037 3. (User Identity) Confidentiality
1038 This section discusses privacy protection of identity information
1039 transmitted inside the policy element. User identity
1040 confidentiality is of particular interest because there is no
1041 built-in RSVP mechanism for encrypting the POLICY_DATA object or
1042 the AUTH_DATA elements. Encryption of one of the attributes
1043 inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
1044 discussed.
1045 To protect the user's privacy it is important not to reveal the
1046 user's identity to an adversary located between the user's host
1047 and the first-hop router (e.g., on a wireless link). User
1048 identities should furthermore not be transmitted outside the
1049 domain of the visited network provider, i.e., the user identity
1050 information inside the policy data element should be removed or
1051 modified by the PDP to prevent revealing its contents to other
1052 (non-authorized) entities along the signaling path. It is not
1053 possible (with the offered mechanisms) to hide the user's
1054 identity in such a way that it is not visible to the first
1055 policy-aware RSVP node (or to the attached network in general).
1056 The ASCII or Unicode distinguished name of user or application
1057 inside the POLICY_LOCATOR attribute of the AUTH_DATA element may
1058 be encrypted as specified in Section 3.3.1 of [7]. The user (or
1059 application) identity is then encrypted with either the Kerberos
1060 session key or with the private key in case of public key based
1061 authentication. When the private key is used, we usually speak
1062 of a digital signature that can be verified by everyone
1063 possessing the public key. Because the certificate with the
1064 public key is included in the message itself, decryption is no
1065 obstacle. Furthermore, the included certificate together with
1066 the additional (unencrypted) information in the RSVP message
1067 provides enough identity information for an eavesdropper. Hence,
1068 the possibility of encrypting the policy locator in case of
1069 public key based authentication is problematic. To encrypt the
1070 identities using asymmetric cryptography, the user's host must be
1071 able somehow to retrieve the public key of the entity verifying
1072 the policy element (i.e., the first policy aware router or the
1073 PDP). Then, this public key could be used to encrypt a symmetric
1074 key, which in turn encrypts the user's identity and certificate,
1075 as is done, e.g., by PGP. Currently no such mechanism is defined
1076 in [7].
1077 The algorithm used to encrypt the POLICY_LOCATOR with the
1078 Kerberos session key is assumed to be the same as the one used
1079 for encrypting the service ticket. The information about the
1080 algorithm used is available in the etype field of the
1081 EncryptedData ASN.1 encoded message part. Section 6.3 of [8]
1082 lists the supported algorithms. [12] defines new encryption
1083 algorithms (Rijndael, Serpent, and Twofish).
1084 Evaluating user identity confidentiality requires also looking at
1085 protocols executed outside of RSVP (for example, the Kerberos
1086 protocol). The ticket included in the CREDENTIAL attribute may
1087 provide user identity protection by not including the optional
1088 cname attribute inside the unencrypted part of the Ticket.
1089 Because the Authenticator is not transmitted with the RSVP
1090 message, the cname and the crealm of the unencrypted part of the
1091 Authenticator are not revealed. In order for the user to request
1092 the Kerberos session ticket for inclusion in the CREDENTIAL
1093 attribute, the Kerberos protocol exchange must be executed. Then
1094 the Authenticator sent with the TGS_REQ reveals the identity of
1095 the user. The AS_REQ must also include the user's identity to
1096 allow the Kerberos Authentication Server to respond with an
1097 AS_REP message that is encrypted with the user's secret key.
1098 Using Kerberos, it is therefore only possible to hide the content
1099 of the encrypted policy locator, which is only useful if this
1100 value differs from the Kerberos principal name. Hence using
1101 Kerberos it is not "entirely" possible to provide user identity
1102 confidentiality.
1103 It is important to note that information stored in the policy
1104 element may be changed by a policy-aware router or by the policy
1105 decision point. Which parts are changed depends upon whether
1106 multicast or unicast is used, how the policy server reacts, where
1107 the user is authenticated, whether the user needs to be
1108 re-authenticated in other network nodes, etc. Hence, user and
1109 application specific information can leak after the messages
1110 leave the first hop within the network where the user's host is
1111 attached. As mentioned at the beginning of this section, this
1112 information leakage is assumed to be intentional.
1113 4. Authorization
1114 In addition to the description of the authorization steps of the
1115 Host-to-Router interface, user-based authorization is performed
1116 with the policy element providing user credentials. The
1117 inclusion of user and application specific information enables
1118 policy-based admission control with special user policies that
1119 are likely to be stored at a dedicated server. Hence a Policy
1120 Decision Point can query, for example, a LDAP server for a
1121 service level agreement stating the amount of resources a certain
1122 user is allowed to request. In addition to the user identity
1123 information, group membership and other non-security-related
1124 information may contribute to the evaluation of the final policy
1125 decision . If the user is not registered to the currently
1126 attached domain, then there is the question of how much
1127 information the home domain of the user is willing to exchange.
1128 This also impacts the user's privacy policy. In general, the
1129 user may not want to distribute much of this policy information.
1130 Furthermore, the lack of a standardized authorization data format
1131 may create interoperability problems when exchanging policy
1132 information. Hence, we can assume that the policy decision point
1133 may use information from an initial authentication and key
1134 agreement protocol, which may have already required cross-realm
1135 communication with the user's home domain if only to assume that
1136 the home domain knows the user and that the user is entitled to
1137 roam and to be able to forward accounting messages to this
1138 domain. This represents the traditional subscriber-based
1139 accounting scenario. Non-traditional or alternative means of
1140 access might be deployed in the near future that do not require
1141 any type of inter-domain communication.
1142 Additional discussions are required to determine the expected
1143 authorization procedures. [37] and [38] discuss authorization
1144 issues for QoS signaling protocols. Furthermore, a number of
1145 mobililty implications for policy handling in RSVP are described
1146 in [39]
1147 5. Performance
1148 If Kerberos is used for user authentication, then a Kerberos
1149 ticket must be included in the CREDENTIAL Section of the
1150 AUTH_DATA element. The Kerberos ticket has a size larger than
1151 500 bytes but only needs to be sent once, because a performance
1152 optimization allows the session key to be cached as noted in
1153 Section 7.1 of [1]. It is assumed that subsequent RSVP messages
1154 only include the POLICY_DATA INTEGRITY object with a keyed
1155 message digest that uses the Kerberos session key. This,
1156 however, assumes that the security association required for the
1157 POLICY_DATA INTEGRITY object is created (or modified) to allow
1158 the selection of the correct key. Otherwise, it difficult to say
1159 which identifier is used to index the security association.
1160 When Kerberos is used as an authentication system then, from a
1161 performance perspective, the message exchange to obtain the
1162 session key needs to be considered, although the exchange only
1163 needs to be done once in the lifetime of the session ticket.
1164 This is particularly true in a mobile environment with a fast
1165 roaming user's host.
1166 Public key based authentication usually provides the best
1167 scalability characteristics for key distribution, but the
1168 protocols are performance demanding. A major disadvantage of the
1169 public key based user authentication in RSVP is the lack of a
1170 method to derive a session key. Hence every RSVP PATH or RESV
1171 message includes the certificate and a digital signature, which
1172 is a huge performance and bandwidth penalty. For a mobile
1173 environment with low power devices, high latency, channel noise,
1174 and low bandwidth links, this seems to be less encouraging. Note
1175 that a public key infrastructure is required to allow the PDP (or
1176 the first-hop router) to verify the digital signature and the
1177 certificate. To check for revoked certificates, certificate
1178 revocation lists or protocols like the Online Certificate Status
1179 Protocol [31] and the Simple Certificate Validation Protocol [32]
1180 are needed. Then the integrity of the AUTH_DATA object via the
1181 digital signature can be verified.
1183 4.4 Communication between RSVP-Aware Routers
1185 1. Authentication
1186 RSVP signaling messages are data origin authenticated and
1187 protected against modification and replay using the RSVP
1188 INTEGRITY object. The RSVP message flow between routers is
1189 protected based on the chain of trust and hence each router only
1190 needs to have a security association with its neighboring
1191 routers. This assumption was made because of performance
1192 advantages and because of special security characteristics of the
1193 core network where no user hosts are directly attached. In the
1194 core network the network structure does not change frequently and
1195 the manual distribution of shared secrets for the RSVP INTEGRITY
1196 object may be acceptable. The shared secrets may be either
1197 manually configured or distributed by using appropriately secured
1198 network management protocols like SNMPv3.
1199 Independent of the key distribution mechanism, host
1200 authentication with RSVP built-in mechanisms is accomplished with
1201 the keyed message digest in the RSVP INTEGRITY object computed
1202 using the previously exchanged symmetric key.
1203 2. Integrity Protection
1204 Integrity protection is accomplished with the RSVP INTEGRITY
1205 object with the variable length Keyed Message Digest field.
1206 3. Replay Protection
1207 Replay protection with the RSVP INTEGRITY object is extensively
1208 described in previous sections. To enable crashed hosts to learn
1209 the latest sequence number used, the Integrity Handshake
1210 mechanism is provided in RSVP.
1211 4. Confidentiality
1212 Confidentiality is not provided by RSVP.
1213 5. Authorization
1214 Depending on the RSVP network, QoS resource authorization at
1215 different routers may need to contact the PDP again. Because the
1216 PDP is allowed to modify the policy element, a token may be added
1217 to the policy element to increase the efficiency of the
1218 re-authorization procedure. This token is used to refer to an
1219 already computed policy decision. The communications interface
1220 from the PEP to the PDP must be properly secured.
1221 6. Performance
1222 The performance characteristics for the protection of the RSVP
1223 signaling messages is largely determined by the key exchange
1224 protocol, because the RSVP INTEGRITY object is only used to
1225 compute a keyed message digest of the transmitted signaling
1226 messages.
1227 The security associations within the core network, i.e., between
1228 individual routers (in comparison with the security association
1229 between the user's host and the first-hop router or with the
1230 attached network in general) can be established more easily
1231 because of the normally strong trust assumptions. Furthermore,
1232 it is possible to use security associations with an increased
1233 lifetime to avoid frequent rekeying. Hence, there is less impact
1234 on the performance compared with the user-to-network interface.
1236 The security association storage requirements are also less
1237 problematic.
1239 5. Miscellaneous Issues
1241 This section describes a number of issues that illustrate some of the
1242 shortcomings of RSVP with respect to security.
1244 5.1 First Hop Issue
1246 In case of end-to-end signaling, an end host starts signaling to its
1247 attached network. The first-hop communication is often more
1248 difficult to secure because of the different requirements and a
1249 missing trust relationship. An end host must therefore obtain some
1250 information to start RSVP signaling:
1252 o Does this network support RSVP signaling?
1253 o Which node supports RSVP signaling?
1254 o To which node is authentication required?
1255 o Which security mechanisms are used for authentication?
1256 o Which algorithms have to be used?
1257 o Where should the keys and security association come from?
1258 o Should a security association be established?
1260 RSVP, as specified today, is used as a building block. Hence, these
1261 questions have to be answered as part of overall architectural
1262 considerations. Without giving an answer to this question, ad hoc
1263 RSVP communication by an end host roaming to an unknown network is
1264 not possible. A negotiation of security mechanisms and algorithms is
1265 not supported for RSVP.
1267 5.2 Next-Hop Problem
1269 Throughout the document it was assumed that the next RSVP node along
1270 the path is always known. Knowing your next hop is important to be
1271 able to select the correct key for the RSVP Integrity object and to
1272 apply the proper protection. In case in which an RSVP node assumes
1273 it knows which node is the next hop the following protocol exchange
1274 can occur:
1276 Integrity
1277 (A<->C) +------+
1278 (3) | RSVP |
1279 +------------->+ Node |
1280 | | B |
1281 Integrity | +--+---+
1282 (A<->C) | |
1283 +------+ (2) +--+----+ |
1284 (1) | RSVP +----------->+Router | | Error
1285 ----->| Node | | or +<-----------+ (I am B)
1286 | A +<-----------+Network| (4)
1287 +------+ (5) +--+----+
1288 Error .
1289 (I am B) . +------+
1290 . | RSVP |
1291 ...............+ Node |
1292 | C |
1293 +------+
1295 Figure 6: Next-Hop Issue
1297 When RSVP node A in Figure 6 receives an incoming RSVP Path message,
1298 standard RSVP message processing takes place. Node A then has to
1299 decide which key to select to protect the signaling message. We
1300 assume that some unspecified mechanism is used to make this decision.
1301 In this example node A assumes that the message will travel to RSVP
1302 node C. However, because of some reasons (e.g. a route change,
1303 inability to learn the next RSVP hop along the path, etc.) the
1304 message travels to node B via a non-RSVP supporting router that
1305 cannot verify the integrity of the message (or cannot decrypt the
1306 Kerberos service ticket). The processing failure causes a PathErr
1307 message to be returned to the originating sender of the Path message.
1308 This error message also contains information about the node
1309 recognizing the error. In many cases a security association might
1310 not be available. Node A receiving the PathErr message might use the
1311 information returned with the PathErr message to select a different
1312 security association (or to establish one).
1314 Figure 6 describes a behavior that might help node A learn that an
1315 error occurred. However, the description of Section 4.2 of [1]
1316 describes in step (5) that a signaling message is silently discarded
1317 if the receiving host cannot properly verify the message: "If the
1318 calculated digest does not match the received digest, the message is
1319 discarded without further processing." For RSVP Path and similar
1320 messages this functionality is not really helpful.
1322 The RSVP Path message therefore provides a number of functions: path
1323 discovery, detecting route changes, learning of QoS capabilities
1324 along the path using the Adspec object, (with some interpretation)
1325 next-hop discovery, and possibly security association establishment
1326 (for example, in the case of Kerberos).
1328 From a security point of view there is a conflict between
1330 o Idempotent message delivery and efficiency
1332 The RSVP Path message especially performs a number of functions.
1333 Supporting idempotent message delivery somehow contradicts with
1334 security association establishment, efficient message delivery,
1335 and message size. For example, a "real" idempotent signaling
1336 message would contain enough information to perform security
1337 processing without depending on a previously executed message
1338 exchange. Adding a Kerberos ticket with every signaling message
1339 is, however, inefficient. Using public key based mechanisms is
1340 even more inefficient when included in every signaling message.
1341 With public key based protection for idempotent messages, there is
1342 additionally a risk of introducing denial of service attacks.
1344 o RSVP Path message functionality and next-hop discovery
1346 To protect an RSVP signaling message (and a RSVP Path message in
1347 particular) it is necessary to know the identity of the next
1348 RSVP-aware node (and some other parameters). Without a mechanism
1349 for next-hop discovery, an RSVP Path message is also responsible
1350 for this task. Without knowing the identity of the next hop, the
1351 Kerberos principal name is also unknown. The so-called Kerberos
1352 user-to-user authentication mechanism, which would allow the
1353 receiver to trigger the process of establishing Kerberos
1354 authentication, is not supported. This issue will again be
1355 discussed in relationship with the last-hop problem.
1357 It is fair to assume that a RSVP-supporting node might not have
1358 security associations with all immediately neighboring RSVP nodes.
1359 Especially for inter-domain signaling, IntServ over DiffServ, or
1360 some new applications such as firewall signaling, the next
1361 RSVP-aware node might not be known in advance. The number of next
1362 RSVP nodes might be considerably large if they are separated by a
1363 large number of non-RSVP aware nodes. Hence, a node transmitting
1364 a RSVP Path message might experience difficulties in properly
1365 protecting the message if it serves as a mechanism to detect both
1366 the next RSVP node (i.e., Router Alert Option added to the
1367 signaling message and addressed to the destination address) and to
1368 detect route changes. It is fair to note that in an intra-domain
1369 case with a dense distribution of RSVP nodes this might be
1370 possible with manual configuration.
1372 Nothing prevents an adversary from continuously flooding an RSVP
1373 node with bogus PathErr messages, although it might be possible to
1374 protect the PathErr message with an existing, available security
1375 association. A legitimate RSVP node would believe that a change
1376 in the path took place. Hence, this node might try to select a
1377 different security association or try to create one with the
1378 indicated node. If an adversary is located somewhere along the
1379 path and either authentication or authorization is not performed
1380 with the necessary strength and accuracy, then it might also be
1381 possible to act as a man-in-the-middle. One method of reducing
1382 susceptibility to this attack is as follows: when a PathErr
1383 message is received from a node with which no security association
1384 exists, attempt to establish a security association and then
1385 repeat the action that led to the PathErr message.
1387 5.3 Last-Hop Issue
1389 This section tries to address practical difficulties when
1390 authentication and key establishment are accomplished with a
1391 two-party protocol that shows some asymmetry in message processing.
1392 Kerberos is such a protocol and also the only supported protocol that
1393 provides dynamic session key establishment for RSVP. For first-hop
1394 communication, authentication is typically done between a user and
1395 some router (for example the access router). Especially in a mobile
1396 environment, it is not feasible to authenticate end hosts based on
1397 their IP or MAC address. To illustrate this problem, the typical
1398 processing steps for Kerberos are shown for first-hop communication:
1400 1. The end host A learns the identity (i.e., Kerberos principal
1401 name) of some entity B. This entity B is either the next RSVP
1402 node, a PDP, or the next policy-aware RSVP node.
1403 2. Entity A then requests a ticket granting ticket for the network
1404 domain. This assumes that the identity of the network domain is
1405 known.
1406 3. Entity A then requests a service ticket for entity B, whose name
1407 was learned in step (a).
1408 4. Entity A includes the service ticket with the RSVP signaling
1409 message (inside the policy object). The Kerberos session key is
1410 used to protect the integrity of the entire RSVP signaling
1411 message.
1413 For last-hop communication this processing step theoretically has to
1414 be reversed; entity A is then a node in the network (for example the
1415 access router) and entity B is the other end host (under the
1416 assumption that RSVP signaling is accomplished between two end hosts
1417 and not between an end host and a application server). The access
1418 router might, however, in step (a) not be able to learn the user's
1419 principal name, because this information might not be available.
1421 Entity A could reverse the process by triggering an IAKERB exchange.
1422 This would cause entity B to request a service ticket for A as
1423 described above. IAKERB is however not supported in RSVP.
1425 5.4 RSVP and IPsec protected data traffic
1427 QoS signaling requires flow information to be established at routers
1428 along a path. This flow identifier installed at each device tells
1429 the router which data packets should receive QoS treatment. RSVP
1430 typically establishes a flow identifier based on the 5-tuple (source
1431 IP address, destination IP address, transport protocol type, source
1432 port, and destination port). If this 5-tuple information is not
1433 available, then other identifiers have to be used. IPsec-protected
1434 data traffic is such an example where the transport protocol and the
1435 port numbers are not accessible. Hence the IPsec SPI is used as a
1436 substitute for them. [13] considers these IPsec implications for
1437 RSVP and is based on three assumptions:
1439 1. An end host, which initiates the RSVP signaling message exchange,
1440 has to be able to retrieve the SPI for given flow. This requires
1441 some interaction with the IPsec security association database
1442 (SAD) and security policy database (SPD) [3]. An application
1443 usually does not know the SPI of the protected flow and cannot
1444 provide the desired values. It can provide the signaling
1445 protocol daemon with flow identifiers. The signaling daemon
1446 would then need to query the SAD by providing the flow
1447 identifiers as input parameters and the SPI as an output
1448 parameter.
1449 2. [13] assumes end-to-end IPsec protection of the data traffic. If
1450 IPsec is applied in a nested fashion, then parts of the path do
1451 not experience QoS treatment. This can be treated as a tunneling
1452 problem, but it is initiated by the end host. A figure better
1453 illustrates the problem in the case of enforcing secure network
1454 access:
1456 +------+ +---------------+ +--------+ +-----+
1457 | Host | | Security | | Router | | Host|
1458 | A | | Gateway (SGW) | | Rx | | B |
1459 +--+---+ +-------+-------+ +----+---+ +--+--+
1460 | | | |
1461 |IPsec-Data( | | |
1462 | OuterSrc=A, | | |
1463 | OuterDst=SGW, | | |
1464 | SPI=SPI1, | | |
1465 | InnerSrc=A, | | |
1466 | OuterDst=B, | | |
1467 | Protocol=X, |IPsec-Data( | |
1468 | SrcPort=Y, | SrcIP=A, | |
1469 | DstPort=Z) | DstIP=B, | |
1470 |=====================>| Protocol=X, |IPsec-Data( |
1471 | | SrcPort=Y, | SrcIP=A, |
1472 | --IPsec protected-> | DstPort=Z) | DstIP=B, |
1473 | data traffic |------------------>| Protocol=X, |
1474 | | | SrcPort=Y, |
1475 | | | DstPort=Z) |
1476 | | |---------------->|
1477 | | | |
1478 | | --Unprotected data traffic-> |
1479 | | | |
1481 Figure 7: RSVP and IPsec protected data traffic
1483 Host A transmitting data traffic would either indicate a 3-tuple
1484 or a 5-tuple . In any case it is
1485 not possible to make a QoS reservation for the entire path. Two
1486 similar examples are remote access using a VPN and protection of
1487 data traffic between a home agent (or a security gateway in the
1488 home network) and a mobile node. With a nested application of
1489 IPsec (for example, IPsec between A and SGW and between A and B)
1490 the same problem occurs.
1491 One possible solution to this problem is to change the flow
1492 identifier along the path to capture the new flow identifier
1493 after an IPsec endpoint.
1494 IPsec tunnels that neither start nor terminate at one of the
1495 signaling end points (for example between two networks) should be
1496 addressed differently by recursively applying an RSVP signaling
1497 exchange for the IPsec tunnel. RSVP signaling within tunnels is
1498 addressed in [14].
1499 3. It is assumed that SPIs do not change during the lifetime of the
1500 established QoS reservation. If a new IPsec SA is created, then
1501 a new SPI is allocated for the security association. To reflect
1502 this change, either a new reservation has to be established or
1503 the flow identifier of the existing reservation has to be
1504 updated. Because IPsec SAs usually have a longer lifetime, this
1505 does not seem to be a major issue. IPsec protection of SCTP data
1506 traffic might more often require an IPsec SA (and an SPI) change
1507 to reflect added and removed IP addresses from an SCTP
1508 association.
1510 5.5 End-to-End Security Issues and RSVP
1512 End-to-end security for RSVP has not been discussed throughout the
1513 document. In this context end-to-end security refers to credentials
1514 transmitted between the two end hosts using RSVP. It is obvious that
1515 care must be taken to ensure that routers along the path are able to
1516 process and modify the signaling messages according to prescribed
1517 processing procedures. Some objects or mechanisms, however, could be
1518 used for end-to-end protection. The main question however is what
1519 the benefit of such an end-to-end security is. First, there is the
1520 question of how to establish the required security association.
1521 Between two arbitrary hosts on the Internet this might turn out to be
1522 quite difficult. Furthermore, te usefulness of end-to-end security
1523 depends on the architecture in which RSVP is deployed. If RSVP is
1524 only used to signal QoS information into the network, and other
1525 protocols have to be executed beforehand to negotiate the parameters
1526 and to decide which entity is charged for the QoS reservation, then
1527 no end-to-end security is likely to be required. Introducing
1528 end-to-end security to RSVP would then cause problems with extensions
1529 like RSVP proxy [40], Localized RSVP [41], and others that terminate
1530 RSVP signaling somewhere along the path without reaching the
1531 destination end host. Such a behavior could then be interpreted as a
1532 man-in-the-middle attack.
1534 5.6 IPsec protection of RSVP signaling messages
1536 It is assumed throughout that RSVP signaling messages can also be
1537 protected by IPsec [3] in a hop-by-hop fashion between two adjacent
1538 RSVP nodes. RSVP, however, uses special processing of signaling
1539 messages, which complicates IPsec protection. As explained in this
1540 section, IPsec should only be used for protection of RSVP signaling
1541 messages in a point-to-point communication environment (i.e., a RSVP
1542 message can only reach one RSVP router and not possibly more than
1543 one). This restriction is caused by the combination of signaling
1544 message delivery and discovery into a single message. Furthermore,
1545 end-to-end addressing complicates IPsec handling considerably. This
1546 section describes at least some of these complications.
1548 RSVP messages are transmitted as raw IP packets with protocol number
1549 46. It might be possible to encapsulate them in UDP as described in
1550 Appendix C of [6]. Some RSVP messages (Path, PathTear, and ResvConf)
1551 must have the Router Alert IP Option set in the IP header. These
1552 messages are addressed to the (unicast or multicast) destination
1553 address and not to the next RSVP node along the path. Hence an IPsec
1554 traffic selector can only use these fields for IPsec SA selection.
1555 If there is only a single path (and possibly all traffic along it is
1556 protected) then there is no problem for IPsec protection of signaling
1557 messages. This type of protection is not common and might only be
1558 used to secure network access between an end host and its first-hop
1559 router. Because the described RSVP messages are addressed to the
1560 destination address instead of the next RSVP node, it is not possible
1561 to use IPsec ESP [21] or AH [20] in transport mode--only IPsec in
1562 tunnel mode is possible.
1564 5.7 Authorization
1566 [37] describes two trust models (NJ Turnpike and NJ Parkway) and two
1567 authorization models (per-session and per-channel financial
1568 settlement). The NJ Turnpike model gives a justification for
1569 hop-by-hop security protection. RSVP focuses on the NJ Turnpike
1570 model although the different trust models are not described in
1571 detail. RSVP supports the NJ Parkway model and per-channel financial
1572 settlement only to a certain extent. Authentication of the user (or
1573 end host) can be provided with the user identity representation
1574 mechanism but authentication might in many cases be insufficient for
1575 authorization. The communication procedures defined for policy
1576 objects [42] can be improved to support the more efficient
1577 per-channel financial settlement model by avoiding policy handling
1578 between inter-domain networks at a signaling message granularity.
1579 Additional information about expected behavior of policy handling in
1580 RSVP can also be obtained from [43].
1582 [38] and [39] provide additional information on authorization. No
1583 good and agreed mechanism for dealing with authorization of QoS
1584 reservations in roaming environments is provided. Price distribution
1585 mechanisms are only described in papers and never made their way
1586 through standardization. RSVP focuses on receiver-initiated
1587 reservations with authorization for the QoS reservation by the data
1588 receiver which introduces a fair number of complexity for mobility
1589 handling as described, for example, in [39].
1591 6. Conclusions
1593 RSVP was the first QoS signaling protocol that provided some security
1594 protection. Whether RSVP provides enough security protection heavily
1595 depends on the environment where it is deployed. RSVP as specified
1596 today should be seen as a building block that has to be adapted to a
1597 given architecture.
1599 This document aims to provide more insights into the security of
1600 RSVP. It cannot not be interpreted as a pass or fail evaluation of
1601 the security provided by RSVP.
1603 Certainly this document is not a complete description of all security
1604 issues related to RSVP. Some issues that require further
1605 consideration are RSVP extensions (for example [13]), multicast
1606 issues, and other security properties like traffic analysis.
1607 Additionally, the interaction with mobility protocols (micro- and
1608 macro-mobility) from a security point of view demands further
1609 investigation.
1611 What can be learned from practical protocol experience and from the
1612 increased awareness regarding security is that some of the available
1613 credential types have received more acceptance than others. Kerberos
1614 is a system that is integrated into many IETF protocols today.
1615 Public key based authentication techniques are however still
1616 considered to be too heavy-weight (computationally and from a
1617 bandwidth perspective) to be used for per-flow signaling. The
1618 increased focus on denial of service attacks put additional demands
1619 on the design of public key based authentication.
1621 The following list briefly summarizes a few security or architectural
1622 issues that deserve improvement:
1624 o Discovery and signaling message delivery should be separated.
1625 o For some applications and scenarios it cannot be assumed that
1626 neighboring RSVP-aware nodes know each other. Hence some in-path
1627 discovery mechanism should be provided.
1628 o Addressing for signaling messages should be done in a hop-by-hop
1629 fashion.
1630 o Standard security protocols (IPsec, TLS or CMS) should be used
1631 whenever possible. Authentication and key exchange should be
1632 separated from signaling message protection. In general, it is
1633 necessary to provide key management to establish security
1634 associations dynamically for signaling message protection.
1635 Relying on manually configured keys between neighboring RSVP nodes
1636 is insufficient. A separate, less frequently executed key
1637 management and security association establishment protocol is a
1638 good place to perform entity authentication, security service
1639 negotiation and selection, and agreement on mechanisms,
1640 transforms, and options.
1641 o The use of public key cryptography in authorization tokens,
1642 identity representations, selective object protection, etc. is
1643 likely to cause fragmentation, the need to protect against denial
1644 of service attacks, and other problems.
1645 o Public key authentication and user identity confidentiality
1646 provided with RSVP require some improvement.
1647 o Public key based user authentication only provides entity
1648 authentication. An additional security association is required to
1649 protect signaling messages.
1650 o Data origin authentication should not be provided by non-RSVP
1651 nodes (such as the PDP). Such a procedure could be accomplished
1652 by entity authentication during the authentication and key
1653 exchange phase.
1654 o Authorization and charging should be better integrated into the
1655 base protocol.
1656 o Selective message protection should be provided. A protected
1657 message should be recognizable from a flag in the header.
1658 o Confidentiality protection is missing and should therefore be
1659 added to the protocol. The general principle is that protocol
1660 designers can seldom foresee all of the environments in which
1661 protocols will be run, so they should allow users to select from a
1662 full range of security services, as the needs of different user
1663 communities vary.
1664 o Parameter and mechanism negotiation should be provided.
1666 7. Security Considerations
1668 This document discusses security properties of RSVP and, as such, it
1669 is concerned entirely with security.
1671 8. IANA considerations
1673 This document does not address any IANA considerations.
1675 9. Acknowledgments
1677 We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu,
1678 Guenther Schaefer, Marc De Vuyst, Bob Grillo and Jukka Manner for
1679 their valuable comments. Additionally, we would like to thank Robert
1680 and Jorge for their time to discuss various issues with me.
1682 Finally we would Allison Mankin and John Loughney for their comments.
1684 10. References
1686 10.1 Normative References
1688 [1] Baker, F., Lindell, B. and M. Talwar, "Identity Representation
1689 for RSVP", January 2000.
1691 [2] Herzog, S., "RSVP Extensions for Policy Control", January 2000.
1693 [3] Kent, S., Atkinson, R. and M. Talwar, "Security Architecture
1694 for the Internet Protocol", November 1998.
1696 [4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
1697 for Message Authentication", February 1997.
1699 [5] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992.
1701 [6] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
1702 "Resource ReSerVation Protocol (RSVP) - Version 1 Functional
1703 Specification", September 1997.
1705 [7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
1706 Herzog, S. and R. Hess, "Identity Representation for RSVP",
1707 October 2001.
1709 [8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
1710 Service (V5)", September 1993.
1712 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
1713 "Diameter Base Protocol", RFC 3588, September 2003.
1715 [10] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A.
1716 Sastry, "The COPS(Common Open Policy Service) Protocol",
1717 January 2000.
1719 [11] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A.
1720 Sastry, "COPS usage for RSVP", January 2000.
1722 [12] Raeburn, K., "Encryption and Checksum Specifications for
1723 Kerberos 5", draft-ietf-krb-wg-crypto-07 (work in progress),
1724 February 2004.
1726 [13] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
1727 Flows", September 1997.
1729 [14] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
1730 Operation Over IP Tunnels", January 2000.
1732 [15] Tung, B. and L. Zhu, "Public Key Cryptography for Initial
1733 Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-24
1734 (work in progress), February 2005.
1736 [16] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
1737 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
1739 [17] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of
1740 Keys (KINK)", draft-ietf-kink-kink-06 (work in progress), July
1741 2004.
1743 10.2 Informative References
1745 [18] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control",
1746 Internet-Draft(Expired) draft-ietf-rap-new-rsvp-ext-00.txt,
1747 June 2001.
1749 [19] "Secure Hash Standard,NIST, FIPS PUB 180-1", April 1995.
1751 [20] Kent, S. and R. Atkinson, "IP Authentication Header", November
1752 1998.
1754 [21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
1755 (ESP)", November 1998.
1757 [22] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
1758 Public Key Infrastructure Certificate and CRL Profile", January
1759 1999.
1761 [23] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
1762 Message Format", November 1998.
1764 [24] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
1765 Realm Information with DNS", Internet-Draft(Expired)
1766 draft-ietf-krb-wg-krb-dns-locate-03.txt, July 2002.
1768 [25] Dobbertin, H., Bosselaers, A. and B. Preneel, "RIPEMD-160: A
1769 strengthened version of RIPEMD in Fast Software Encryption,
1770 LNCS Vol 1039, pp. 71-82", 1996.
1772 [26] Dobbertin, H., "The Status of Md5 After a Recent Attack, RSA
1773 Laboratories CryptoBytes, Volume 2, Number 2", 1996.
1775 [27] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
1776 Protocol (EAP)", March 1998.
1778 [28] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
1779 Authentication Dial In User Service (RADIUS)", June 2000.
1781 [29] ""Microsoft Authorization Data Specification v. 1.0 for
1782 Microsoft Windows 2000 Operating Systems", April 2000.
1784 [30] Cable Television Laboratories, Inc.,, "PacketCable Security
1785 Specification,PKT-SP-SEC-I01-991201", website
1786 http://www.PacketCable.com/ , June 2003.
1788 [31] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams,
1789 "X.509 Internet Public Key Infrastructure Online Certificate
1790 Status Protocol - OCSP", June 1999.
1792 [32] Malpani, A., Hoffman, P., Housley, R. and T. Freeman, "Simple
1793 Certificate Validation Protocol (SCVP)", Internet-Draft(Work in
1794 progress) draft-ietf-pkix-scvp-11.txt, December 2002.
1796 [33] Housley, R., "Cryptographic Message Syntax", June 1999.
1798 [34] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1799 1.5", March 1998.
1801 [35] "Specifications and standard documents", website
1802 http://www.PacketCable.com/ , March 2002.
1804 [36] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History,
1805 Protocols and Implementation in "USENIX Computing Systems
1806 Volume 9 no. 1, Winter", 1996.
1808 [37] Tschofenig, H., Buechli, M., Van den Bosch, S. and H.
1809 Schulzrinne, "NSIS Authentication, Authorization and Accounting
1810 Issues", Internet-Draft(Work in progress)
1811 draft-tschofenig-nsis-aaa-issues-01.txt, March 2003.
1813 [38] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne, H.
1814 and T. Chen, "QoS NSLP Authorization Issues",
1815 Internet-Draft(Work in progress)
1816 draft-tschofenig-nsis-qos-authz-issues-00.txt, June 2003.
1818 [39] Thomas, M., "Analysis of Mobile IP and RSVP Interactions",
1819 Internet-Draft(Work in progress)
1820 draft-thomas-nsis-rsvp-analysis-00.txt, October 2002.
1822 [40] Gai, S., Dutt, D., Elfassy, N. and Y. Bernet, "RSVP Proxy",
1823 Internet-Draft(Expired) draft-ietf-rsvp-proxy-03.txt, March
1824 2002.
1826 [41] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K.
1827 Raatikainen, "Localized RSVP", Internet-Draft(Expired)
1828 draft-manner-lrsvp-00.txt, May 2002.
1830 [42] Herzog, S., "Accounting and Access Control in RSVP,", PhD
1831 Dissertation,", Internet-Draft(Expired)
1832 draft-ietf-rsvp-lpm-arch-00.txt, November 1995.
1834 [43] Herzog, S., "Accounting and Access Control for Multicast
1835 Distributions: Models and Mechanisms", June 1996.
1837 [44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
1838 Attacks ,Open Software Foundation DCE Request for Comments",
1839 December 1992.
1841 [45] Wu, T., "A Real-World Analysis of Kerberos Password Security",
1842 February 1999.
1844 [46] Wu, T., Wu, F. and F. Gong, "Securing QoS: Threats to RSVP
1845 Messages and Their Countermeasures in "IEEE IWQoS, pp. 62-64",
1846 1999.
1848 [47] Talwar, V., Nahrstedt, K. and F. Gong, "Securing RSVP For
1849 Multimedia Applications in "Proceedings of ACM Multimedia
1850 (Multimedia Security Workshop)"", November 2000.
1852 [48] Talwar, V., Nahrstedt, K. and S. Nath, "RSVP-SQoS : A Secure
1853 RSVP Protocol in "International Conference on Multimedia and
1854 Exposition", Tokyo , Japan", August 2001.
1856 [49] Jablon, D., "Strong password-only authenticated key exchange
1857 Computer Communication Review, 26(5), pp. 5-26",
1858 Internet-Draft(Expired) draft-ietf-rap-new-rsvp-ext-00.txt,
1859 October 1996.
1861 [50] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
1862 November 1998.
1864 Authors' Addresses
1866 Hannes Tschofenig
1867 Siemens
1868 Otto-Hahn-Ring 6
1869 Munich, Bavaria 81739
1870 Germany
1872 EMail: Hannes.Tschofenig@siemens.com
1873 Richard Graveman
1874 RFG Security
1875 15 Park Avenue
1876 Morristown, NJ 07960
1877 USA
1879 EMail: rfg@acm.org
1881 Appendix A. Dictionary Attacks and Kerberos
1883 Kerberos might be used with RSVP as described in this document.
1884 Because dictionary attacks are often mentioned in relationship with
1885 Kerberos, a few issues are addressed here.
1887 The initial Kerberos AS_REQ request (without pre-authentication,
1888 without various extensions, and without PKINIT) is unprotected. The
1889 response message AS_REP is encrypted with the client's long-term key.
1890 An adversary can take advantage of this fact by requesting AS_REP
1891 messages to mount an off-line dictionary attack. Pre-authentication
1892 ([44]) can be used to reduce this problem. However,
1893 pre-authentication does not entirely prevent dictionary attacks by an
1894 adversary who can still eavesdrop on Kerberos messages along the path
1895 between a mobile node and a KDC. With mandatory pre-authentication
1896 for the initial request, an adversary cannot request a Ticket
1897 Granting Ticket for an arbitrary user. On-line password guessing
1898 attacks are still possible by choosing a password (e.g., from a
1899 dictionary) and then transmitting an initial request including a
1900 pre-authentication data field. An unsuccessful authentication by the
1901 KDC results in an error message and the gives the adversary a hint to
1902 restart the protocol and try a new password.
1904 There are, however, some proposals that prevent dictionary attacks.
1905 The use of Public Key Cryptography for initial authentication [15]
1906 (PKINIT) is one such solution. Other proposals use
1907 strong-password-based authenticated key agreement protocols to
1908 protect the user's password during the initial Kerberos exchange.
1909 [45] discusses the security of Kerberos and also discusses mechanisms
1910 to prevent dictionary attacks.
1912 Appendix B. Example of User-to-PDP Authentication
1914 The following Section describes an example of user-to-PDP
1915 authentication. Note that the description below is not fully covered
1916 by the RSVP specification and hence it should only be seen as an
1917 example.
1919 Windows 2000, which integrates Kerberos into RSVP, uses a
1920 configuration with the user authentication to the PDP as described in
1921 [29]. The steps for authenticating the user to the PDP in an
1922 intra-realm scenario are the following:
1924 o Windows 2000 requires the user to contact the KDC and to request a
1925 Kerberos service ticket for the PDP account AcsService in the
1926 local realm .
1927 o This ticket is then embedded into the AUTH_DATA element and
1928 included in either the PATH or the RESV message. In case of
1929 Microsoft's implementation, the user identity encoded as a
1930 distinguished name is encrypted with the session key provided with
1931 the Kerberos ticket. The Kerberos ticket is sent without the
1932 Kerberos authdata element that contains authorization information,
1933 as explained in [29].
1934 o The RSVP message is then intercepted by the PEP, which forwards it
1935 to the PDP. [29] does not state which protocol is used to forward
1936 the RSVP message to the PDP.
1937 o The PDP that finally receives the message decrypts the received
1938 service ticket. The ticket contains the session key used by the
1939 user's host to
1940 * Encrypt the principal name inside the policy locator field of
1941 the AUTH_DATA object and to
1942 * Create the integrity-protected Keyed Message Digest field in
1943 the INTEGRITY object of the POLICY_DATA element. The
1944 protection described here is between the user's host and the
1945 PDP. The RSVP INTEGRITY object on the other hand is used to
1946 protect the path between the user's host and the first-hop
1947 router, because the two message parts terminate at different
1948 nodes and different security associations must be used. The
1949 interface between the message-intercepting, first-hop router
1950 and the PDP must be protected as well.
1951 * The PDP does not maintain a user database, and [29] describes
1952 how the PDP may query the Active Directory (a LDAP based
1953 directory service) for user policy information.
1955 Appendix C. Literature on RSVP Security
1957 Few documents address the security of RSVP signaling. This section
1958 briefly describes some important documents.
1960 Improvements to RSVP are proposed in [46] to deal with insider
1961 attacks. Insider attacks are caused by malicious RSVP routers that
1962 modify RSVP signaling messages in such a way that they cause harm to
1963 the nodes participating in the signaling message exchange.
1965 As a solution, non-mutable RSVP objects are digitally signed by the
1966 sender. This digital signature is added to the RSVP PATH message.
1967 Additionally, the receiver attaches an object to the RSVP RESV
1968 message containing a "signed" history. This value allows
1969 intermediate RSVP routers (by examining the previously signed value)
1970 to detect a malicious RSVP node.
1972 A few issues are, however, left open in the document. Replay attacks
1973 are not covered, and it is therefore assumed that timestamp-based
1974 replay protection is used. To detect a malicious node, it is
1975 necessary that all routers along the path are able to verify the
1976 digital signature. This may require a global public key
1977 infrastructure and also client-side certificates. Furthermore the
1978 bandwidth and computational requirements to compute, transmit, and
1979 verify digital signatures for each signaling message might place a
1980 burden on a real-world deployment.
1982 Authorization is not considered in the document, which might have an
1983 influence on the implications of signaling message modification.
1984 Hence, the chain-of-trust relationship (or this step in a different
1985 direction) should be considered in relationship with authorization.
1987 In [47], the above-described idea of detecting malicious RSVP nodes
1988 is improved by addressing performance aspects. The proposed solution
1989 is somewhere between hop-by-hop security and the approach in [46],
1990 insofar as it separates the end-to-end path into individual networks.
1991 Furthermore, some additional RSVP messages (e.g., feedback messages)
1992 are introduced to implement a mechanism called "delayed integrity
1993 checking." In [48], the approach presented in [47] is enhanced.
1995 Intellectual Property Statement
1997 The IETF takes no position regarding the validity or scope of any
1998 Intellectual Property Rights or other rights that might be claimed to
1999 pertain to the implementation or use of the technology described in
2000 this document or the extent to which any license under such rights
2001 might or might not be available; nor does it represent that it has
2002 made any independent effort to identify any such rights. Information
2003 on the procedures with respect to rights in RFC documents can be
2004 found in BCP 78 and BCP 79.
2006 Copies of IPR disclosures made to the IETF Secretariat and any
2007 assurances of licenses to be made available, or the result of an
2008 attempt made to obtain a general license or permission for the use of
2009 such proprietary rights by implementers or users of this
2010 specification can be obtained from the IETF on-line IPR repository at
2011 http://www.ietf.org/ipr.
2013 The IETF invites any interested party to bring to its attention any
2014 copyrights, patents or patent applications, or other proprietary
2015 rights that may cover technology that may be required to implement
2016 this standard. Please address the information to the IETF at
2017 ietf-ipr@ietf.org.
2019 Disclaimer of Validity
2021 This document and the information contained herein are provided on an
2022 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2023 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2024 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2025 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2026 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2027 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2029 Copyright Statement
2031 Copyright (C) The Internet Society (2005). This document is subject
2032 to the rights, licenses and restrictions contained in BCP 78, and
2033 except as set forth therein, the authors retain all their rights.
2035 Acknowledgment
2037 Funding for the RFC Editor function is currently provided by the
2038 Internet Society.