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