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