idnits 2.17.00 (12 Aug 2021) /tmp/idnits56183/draft-tschofenig-rsvp-sec-properties-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-tschofenig-rsvp-sec-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-tschofenig-rsvp-sec-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-tschofenig-rsvp-sec-', but the file name used is 'draft-tschofenig-rsvp-sec-properties-00' == There are 73 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3 Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7 IANA considerations' ) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1509 has weird spacing: '... ticket from ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'RFC2747' on line 1822 looks like a reference -- Missing reference section? 'RFC2750' on line 1833 looks like a reference -- Missing reference section? 'HH01' on line 1720 looks like a reference -- Missing reference section? 'RFC2104' on line 1773 looks like a reference -- Missing reference section? 'RFC1321' on line 1767 looks like a reference -- Missing reference section? 'SHA' on line 1846 looks like a reference -- Missing reference section? 'RFC2205' on line 1777 looks like a reference -- Missing reference section? 'RFC2367' on line 1787 looks like a reference -- Missing reference section? 'RFC3182' on line 1840 looks like a reference -- Missing reference section? 'RFC1510' on line 1770 looks like a reference -- Missing reference section? 'RFC2495' on line 1810 looks like a reference -- Missing reference section? 'RFC2440' on line 1807 looks like a reference -- Missing reference section? 'RFC2401' on line 1792 looks like a reference -- Missing reference section? 'RFC2409' on line 1801 looks like a reference -- Missing reference section? 'HA01' on line 1715 looks like a reference -- Missing reference section? 'RFC2402' on line 1795 looks like a reference -- Missing reference section? 'RFC2406' on line 1798 looks like a reference -- Missing reference section? 'DBP96' on line 1690 looks like a reference -- Missing reference section? 'Dob96' on line 1702 looks like a reference -- Missing reference section? 'RFC2865' on line 1836 looks like a reference -- Missing reference section? 'RFC2748' on line 1825 looks like a reference -- Missing reference section? 'RFC2749' on line 1829 looks like a reference -- Missing reference section? 'MADS01' on line 1733 looks like a reference -- Missing reference section? 'PKTSEC' on line 1756 looks like a reference -- Missing reference section? 'RFC2560' on line 1814 looks like a reference -- Missing reference section? 'MHHF01' on line 1741 looks like a reference -- Missing reference section? 'RFC2630' on line 1819 looks like a reference -- Missing reference section? 'RFC2315' on line 1784 looks like a reference -- Missing reference section? 'PGP' on line 1753 looks like a reference -- Missing reference section? 'DG96' on line 1694 looks like a reference -- Missing reference section? 'Rae01' on line 1760 looks like a reference -- Missing reference section? 'RFC2410' on line 1804 looks like a reference -- Missing reference section? 'Pat92' on line 1749 looks like a reference -- Missing reference section? 'Jas96' on line 1728 looks like a reference -- Missing reference section? 'BM92' on line 1679 looks like a reference -- Missing reference section? 'DH95' on line 1698 looks like a reference -- Missing reference section? 'Wu99' on line 1860 looks like a reference -- Missing reference section? 'Wu98' on line 1855 looks like a reference -- Missing reference section? 'Jab96' on line 1724 looks like a reference -- Missing reference section? 'RFC2207' on line 1781 looks like a reference -- Missing reference section? 'RF2367' on line 1764 looks like a reference Summary: 6 errors (**), 1 flaw (~~), 6 warnings (==), 42 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hannes Tschofenig 3 Internet Draft Siemens AG 4 Document: draft-tschofenig-rsvp-sec- 5 properties-00.txt 6 Expires: November, 2002 8 June, 2002 10 RSVP Security Properties 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 As the work of the NSIS working group has begun there are also 36 concerns about security and its implication for the design of a 37 signaling protocol. In order to understand the security properties 38 and available options of RSVP a number of documents have to be read. 39 This document tries to summarize the security properties of RSVP and 40 to view them from a different point of view. This work in NSIS is 41 part of the overall process of analyzing other protocols and to 42 learn from their design considerations. This document should also 43 provide a starting point for further discussions. 45 Table of Contents 47 1 Introduction...................................................2 48 2 Terminology....................................................3 49 3 Overview.......................................................5 50 3.1 The RSVP INTEGRITY Object....................................5 51 3.2 Security Associations........................................6 52 3.3 RSVP Key Management Assumptions..............................7 53 3.4 Identity Representation......................................7 54 3.5 RSVP Integrity Handshake....................................11 55 4 Detailed Security Property Discussion.........................12 56 4.1 Discussed Network Topology..................................12 57 4.2 Host/Router.................................................13 58 4.3 User to PEP/PDP.............................................17 59 4.4 Communication between RSVP aware routers....................25 60 4.5 Miscellaneous Issues........................................28 61 4.5.1 Dictionary Attacks and Kerberos............................28 62 4.5.2 Example of User-to-PDP Authentication......................30 63 4.5.3 Open Issues................................................30 64 5 Conclusions...................................................31 65 6 Security Considerations.......................................32 66 7 IANA considerations...........................................32 67 8 Acknowledgments...............................................32 68 9 References....................................................32 69 10 Author's Contact Information..................................36 70 11 Full Copyright Statement......................................36 72 1 Introduction 74 As the work of the NSIS working group has begun there are also 75 concerns about security and its implication for the design of a 76 signaling protocol. In order to understand the security properties 77 and available options of RSVP a number of documents have to be read. 78 This document tries to summarize the security properties of RSVP and 79 to view them from a different point of view. This work in NSIS is 80 part of the overall process of analyzing other protocols and to 82 Tschofenig Informational - Expires August 2002 2 83 learn from their design considerations. This document should also 84 provide a starting point for further discussions. 86 The content of this document is organized as follows: 88 Section 3 provides an overview of the security mechanisms provided 89 by RSVP including the INTEGRITY object, a description of the 90 identity representation within the POLICY_DATA object (i.e. user 91 authentication) and the RSVP Integrity Handshake mechanism. 93 Section 4 provides a more detailed discussion of the used mechanism 94 and tries to describe the mechanisms provided in detail. 96 Finally the last Section briefly addresses issues like the 97 discussion of the vulnerability of Kerberos against dictionary 98 attacks and open issues in the context of RSVP and issues for 99 further investigation. 101 2 Terminology 103 To begin with the description of the security properties of RSVP it 104 is natural to describe some basic building-blocks. 106 - Chain-of-Trust 108 The security mechanisms supported by RSVP [RFC2747] heavily relies 109 on optional hop-by-hop protection using the built-in INTEGRITY 110 object. Hop-by-hop security with the INTEGRITY object inside the 111 RSVP message thereby refers to the protection between RSVP 112 supporting network elements. Additionally there is the notion of 113 policy aware network elements that additionally understand the 114 POLICY_DATA element within the RSVP message. Since this element also 115 includes an INTEGRITY object there is an additional hop-by-hop 116 security mechanism that provides security between policy aware 117 nodes. Policy ignorant nodes are not affected by the inclusion of 118 this object in the POLICY_DATA element since they do not try to 119 interpret it. 121 To protect signaling messages that are possibly modified by each 122 RSVP router along the path it must be assumed that each incoming 123 request is authenticated, integrity and replay protected. This 124 provides protection against unauthorized nodes injecting bogus 125 messages. Furthermore each RSVP-router is assumed to behave in the 126 expected manner. Outgoing messages transmitted to the next hop 127 network element experience protection according RSVP security 128 processing. 130 Using the above described mechanisms a chain-of-trust is created 131 whereby a signaling message transmitted by router A via router B and 132 received by router C is supposed to be secure if router A and B and 133 router B and C share a security association and all routers behave 134 expectedly. Hence router C trusts router A although router C does 136 Tschofenig Informational - Expires August 2002 3 137 not have a direct security association with router A. We can 138 therefore conclude that the protection achieved with this hop-by-hop 139 security for the chain-of-trust is as good as the weakest link in 140 the chain. 142 If one router is malicious (for example because an adversary has 143 control over this router) then it can arbitrarily modify messages 144 and cause unexpected behavior and mount a number of attacks not only 145 restricted to QoS signaling. Additionally it must be mentioned that 146 some protocols demand more protection than others (this depends 147 between which nodes these protocols are executed). For example edge 148 devices, where end-users are attached, may more likely be attacked 149 in comparison to the more secure core network of a service provider. 150 In some cases a network service provider may choose not to use the 151 RSVP provided security mechanisms inside the core network because a 152 different security protection is deployed. 154 Section 6 of [RFC2750] mentions the term chain-of-trust in the 155 context of RSVP integrity protection. In Section 6 of [HH01] the 156 same term is used in the context of user authentication with the 157 INTEGRITY object inside the POLICY_DATA element. Unfortunately the 158 term is not explained in detail and the assumption is not clearly 159 specified. 161 - Host and User Authentication 163 The presence of the RSVP protection and a separate user identity 164 representation leads to the fact that both user- and the host- 165 identities are used for RSVP protection. Therefore user and host 166 based security is investigated separately because of the different 167 authentication mechanisms provided. To avoid confusion about the 168 different concepts Section 3.4 will describe the concept of user 169 authentication in more detail. 171 - Key Management 173 For most of the security associations required for the protection of 174 RSVP signaling messages it is assumed that they are already 175 available and hence key management was done in advance. There is 176 however an exception with the support for Kerberos. Using Kerberos 177 an entity is able to distribute a session key used for RSVP 178 signaling protection. 180 - RSVP INTEGRITY and POLICY_DATA INTEGRITY Object 182 RSVP uses the INTEGRITY object in two places of the message. The 183 first usage is in the RSVP message itself and covers the entire RSVP 184 message as defined in [RFC2747] whereas the latter is included in 185 the POLICY_DATA object and defined in [RFC2750]. In order to 186 differentiate the two objects regarding their scope of protection 187 the two terms RSVP INTEGRITY and POLICY_DATA INTEGRITY object are 188 used. The data structure of the two objects however is the same. 190 Tschofenig Informational - Expires August 2002 4 191 3 Overview 193 3.1 The RSVP INTEGRITY Object 195 The RSVP INTEGRITY object is the major component of the RSVP 196 security protection. This object is used to provide integrity and 197 replay protect the content of the signaling message between two RSVP 198 participating router. Furthermore the RSVP INTEGRITY object provides 199 data origin authentication. The attributes of the object are briefly 200 described: 202 - Flags field 204 The Handshake Flag is the only defined flag and is used to 205 synchronize sequence numbers if the communication gets out-of-sync 206 (i.e. for a restarting host to recover the most recent sequence 207 number). Setting this flag to one indicates that the sender is 208 willing to respond to an Integrity Challenge message. This flag can 209 therefore be seen as a capability negotiation transmitted within 210 each INTEGRITY object. 212 - Key Identifier 214 The Key Identifier selects the key used for verification of the 215 Keyed Message Digest field and hence must be unique for the sender. 216 Its length is fixed with 48-bit. The generation of this Key 217 Identifier field is mostly a decision of the local host. [RFC2747] 218 describes this field as a combination of an address, the sending 219 interface and a key number. We assume that the Key Identifier is 220 simply a (keyed) hash value computed over a number of fields with 221 the requirement to be unique if more than one security association 222 is used in parallel between two hosts (i.e. as it is the case with 223 security association that have overlapping lifetimes). A receiving 224 system uniquely identifies a security association based on the Key 225 Identifier and the sender's IP address. The sender's IP address may 226 be obtained from the RSVP_HOP object or from the source IP address 227 of the packet if the RSVP_HOP object is not present. The sender uses 228 the outgoing interface to determine which security association to 229 use. The term outgoing interface might be confusing. The sender 230 selects the security association based on the receiver's IP address 231 (of the next RSVP capable router). To determine which node is the 232 next capable RSVP router is not further specified and is likely to 233 be statically configured. 235 - Sequence Number 237 The sequence number used by the INTEGRITY object is 64-bits in 238 length and the starting value can be selected arbitrarily. The 239 length of the sequence number field was chosen to avoid exhaustion 240 during the lifetime of a security association as stated in Section 3 241 of [RFC2747]. In order for the receiver to distinguish between a new 243 Tschofenig Informational - Expires August 2002 5 244 and a replayed sequence number each value must be monotonically 245 increasing modulo 2^64. We assume that the first sequence number 246 seen (i.e. the starting sequence number) is stored somewhere. The 247 modulo-operation is required because the starting sequence number 248 may be an arbitrary number. The receiver therefore only accepts 249 packets with a sequence number larger (modulo 2^64) than the 250 previous packet. As explained in [RFC2747] this process is started 251 by handshaking and agreeing on an initial sequence number. If no 252 such handshaking is available then the initial sequence number must 253 be part of the establishment of the security association. 255 The generation and storage of sequence numbers is an important step 256 in preventing replay attacks and is largely determined by the 257 capabilities of the system in presence of system crashes, failures 258 and restarts. Section 3 of [RFC2747] explains some of the most 259 important considerations. 261 - Keyed Message Digest 263 The Keyed Message Digest is an RSVP built-in security mechanism used 264 to provide integrity protection of the signaling messages. Prior to 265 computing the value for the Keyed Message Digest field the Keyed 266 Message Digest field itself must be set to zero and a keyed hash 267 computed over the entire RSVP packet. The Keyed Message Digest field 268 is variable in length but must be a multiple of four octets. If 269 HMAC-MD5 is used then the output value is 16 bytes long. The keyed 270 hash function HMAC-MD5 [RFC2104] is required for a RSVP 271 implementation as noted in Section 1 of [RFC2747]. Hash algorithms 272 other than MD5 [RFC1321] like SHA [SHA] may also be supported. 274 The key used for computing this Keyed Message Digest may be obtained 275 from the pre-shared secret which is either manually distributed or 276 the result of a key management protocol. No key management protocol, 277 however, is specified to create the desired security associations. 279 3.2 Security Associations 281 Different attributes are stored for security associations of sending 282 and receiving systems (i.e. unidirectional security associations). 283 The sending system needs to maintain the following attributes in 284 such a security association [RFC2747]: 286 - Authentication algorithm and algorithm mode 287 - Key 288 - Key Lifetime 289 - Sending Interface 290 - Latest sequence number (sent with this key identifier) 292 The receiving system has to store the following fields: 294 - Authentication algorithm and algorithm mode 295 - Key 297 Tschofenig Informational - Expires August 2002 6 298 - Key Lifetime 299 - Source address of the sending system 300 - List of last n sequence numbers (received with this key 301 identifier) 303 Note that the security associations need to have additional fields 304 to indicate their state. It is necessary to have an overlapping 305 lifetime of security associations to avoid interrupting an ongoing 306 communication because of expired security associations. During such 307 a period of overlapping lifetime it is necessary to authenticate 308 either one or both active keys. As mentioned in [RFC2747] a sender 309 and a receiver might have multiple active keys simultaneously. 310 If more than one algorithm is supported then the algorithm used must 311 be specified for a security association. 313 3.3 RSVP Key Management Assumptions 315 [RFC2205] assumes that security associations are already available. 316 Manual key distribution must be provided by an implementation as 317 noted in Section 5.2 of [RFC2747]. Manual key distribution however 318 has different requirements to a key storage û a simple plaintext 319 ASCII file may be sufficient in some cases. If multiple security 320 associations with different lifetimes should be supported at the 321 same time then a key engine, for example PF_KEY [RFC2367], would be 322 more appropriate. Further security requirements listed in Section 323 5.2 of [RFC2747] are the following: 325 - The manual deletion of security associations must be supported. 326 - The key storage should persist a system restart. 327 - Each key must be assigned a specific lifetime and a specific Key 328 Identifier. 330 3.4 Identity Representation 332 In addition to host-based authentication with the INTEGRITY object 333 inside the RSVP message user-based authentication is available as 334 introduced with [RFC2750]. Section 2 of [RFC3182] stated that 335 ôProviding policy based admission control mechanism based on user 336 identities or application is one of the prime requirements.ö To 337 identify the user or the application, a policy element called 338 AUTH_DATA, which is contained in the POLICY_DATA object, is created 339 by the RSVP daemon at the userÆs host and transmitted inside the 340 RSVP message. The structure of the POLICY_DATA element is described 341 in [RFC2750]. Network nodes like the PDP then use the information 342 contained in the AUTH_DATA element to authenticate the user and to 343 allow policy-based admission control to be executed. As mentioned in 344 [RFC3182] the policy element is processed and the policy decision 345 point replaces the old element with a new one for forwarding to the 346 next hop router. 348 A detailed description of the POLICY_DATA element can be found in 349 [RFC2750]. The attributes contained in the authentication data 351 Tschofenig Informational - Expires August 2002 7 352 policy element AUTH_DATA, which is defined in [RFC3182], are briefly 353 explained in this Section. Figure 1 shows the abstract structure of 354 the RSVP message with its security relevant objects and the scope of 355 protection. The RSVP INTEGRITY object (outer object) covers the 356 entire RSVP message whereas the POLICY_DATA INTEGRITY object only 357 covers objects within the POLICY_DATA element. 359 +--------------------------------------------------------+ 360 | RSVP Message | 361 +--------------------------------------------------------+ 362 | INTEGRITY +-------------------------------------------+| 363 | Object |POLICY_DATA Object || 364 | +-------------------------------------------+| 365 | | INTEGRITY +------------------------------+|| 366 | | Object | AUTH_DATA Object ||| 367 | | +------------------------------+|| 368 | | | Various Authentication ||| 369 | | | Attributes ||| 370 | | +------------------------------+|| 371 | +-------------------------------------------+| 372 +--------------------------------------------------------+ 373 Figure 1: Security relevant Objects and Elements within the RSVP 374 message 376 The AUTH_DATA object contains information for identifying users and 377 applications together with credentials for those identities. The 378 main purpose of those identities seems to be the usage for policy 379 based admission control and not for authentication and key 380 management. As noted in Section 6.1 of [RFC3182] an RSVP may contain 381 more than one POLICY_DATA object and each of them may contain more 382 than one AUTH_DATA object. As indicated in the Figure above and in 383 [RFC3182] one AUTH_DATA object contains more than one authentication 384 attribute. A typical configuration for a Kerberos-based user 385 authentication includes at least the Policy Locator and an attribute 386 containing the Kerberos session ticket. 388 A successful user authentication is the basis for doing policy-based 389 admission control. Additionally other information such as time-of- 390 day, application type, location information, group membership etc. 391 may be relevant for a policy. 393 The following attributes are defined for the usage in the AUTH_DATA 394 object: 396 a) Policy Locator 398 The policy locator string that is a X.500 distinguished name (DN) 399 used to locate the user and/or application specific policy 400 information. The following types of X.500 DNs are listed: 402 - ASCII_DN 403 - UNICODE_DN 405 Tschofenig Informational - Expires August 2002 8 406 - ASCII_DN_ENCRYPT 407 - UNICODE_DN_ENCRYPT 409 The first two types are the ASCII and the Unicode representation of 410 the user or application DN identity. The two ôencryptedö 411 distinguished name types are either encrypted with the Kerberos 412 session key or with the private key of the userÆs digital 413 certificate (i.e. digitally signed). The term encrypted together 414 with a digital signature is easy to misconceive. If user identity 415 confidentiality shall be provided then the policy locator has to be 416 encrypted with the public key of the recipient. How to obtain this 417 public key is not described in the document. Such an issue may be 418 specified in a concrete architecture where RSVP is used. 420 b) Credentials 422 Two cryptographic credentials are currently defined for a user: 423 Authentication with Kerberos V5 [RFC1510], and authentication with 424 the help of digital signatures based on X.509 [RFC2495] and PGP 425 [RFC2440]. The following list contains all defined credential types 426 currently available and defined in [RFC3182]: 428 +--------------+--------------------------------+ 429 | Credential | Description | 430 | Type | | 431 +===============================================| 432 | ASCII_ID | User or application identity | 433 | | encoded as an ASCII string | 434 +--------------+--------------------------------+ 435 | UNICODE_ID | User or application identity | 436 | | encoded as an Unicode string | 437 +--------------+--------------------------------+ 438 | KERBEROS_TKT | Kerberos V5 session ticket | 439 +--------------+--------------------------------+ 440 | X509_V3_CERT | X.509 V3 certificate | 441 +--------------+--------------------------------+ 442 | PGP_CERT | PGP certificate | 443 +--------------+--------------------------------+ 445 Table 1: Credentials Supported in RSVP 447 The first two credentials only contain a plaintext string and 448 therefore they do not provide cryptographic user authentication. 449 These plaintext strings may be used to identify applications, which 450 are included for policy-based admission control. Note that these 451 plain-text identifiers may, however, be protected if either the RSVP 452 INTEGRITY and/or the INTEGRITY object of the POLICY_DATA element is 453 present. Note that the two INTEGRITY objects can terminate at 454 different entities depending on the network structure. The digital 455 signature may also provide protection of application identifiers. A 456 protected application identity (and the entire content of the 458 Tschofenig Informational - Expires August 2002 9 459 POLICY_DATA element) cannot be modified as long as no policy 460 ignorant nodes are used in between. 462 A Kerberos session ticket, as previously mentioned, is the ticket of 463 a Kerberos AP_REQ message [RFC1510] without the Authenticator. 464 Normally, the AP_REQ message is used by a client to authenticate to 465 a server. The INTEGRITY object (e.g. of the POLICY_DATA element) 466 provides the functionality of the Kerberos Authenticator, namely 467 replay protection and shows that the user was able to retrieve the 468 session key following the Kerberos protocol. This is, however, only 469 the case if the Kerberos session was used for the keyed message 470 digest field of the INTEGRITY object. Section 7 of [RFC2747] 471 discusses some issues for establishment of keys for the INTEGRITY 472 object. The establishment of the security association for the RSVP 473 INTEGRITY object with the inclusion of the Kerberos Ticket within 474 the AUTH_DATA element may be complicated by the fact that the ticket 475 can be decrypted by node B whereas the RSVP INTEGRITY object 476 terminates at a different host C. The Kerberos session ticket 477 contains, among many other fields, the session key. The Policy 478 Locator may also be encrypted with the same session key. The 479 protocol steps that need to be executed to obtain such a Kerberos 480 service ticket are not described in [RFC3182] and may involve 481 several roundtrips depending on many Kerberos related factors. The 482 Kerberos ticket does not need to be included in every RSVP message 483 as an optimisation as described in Section 7.1 of [RFC2747]. Thus 484 the receiver must store the received service ticket. If the lifetime 485 of the ticket is expired then a new service ticket must be sent. If 486 the receiver lost his state information (because of a crash or 487 restart) then he may transmit an Integrity Challenge message to 488 force the sender to re-transmit a new service ticket. 490 If either the X.509 V3 or the PGP certificate is included in the 491 policy element then a digital signature must be added. The digital 492 signature computed over the entire AUTH_DATA object provides 493 authentication and integrity protection. The SubType of the digital 494 signature authentication attribute is set to zero before computing 495 the digital signature. Whether or not a guarantee of freshness with 496 the replay protection (either timestamps or sequence numbers) is 497 provided by the digital signature is an open issue as discussed in 498 Section 4.3. 500 c) Digital Signature 502 The digital signature computed over the data of the AUTH_DATA object 503 must be the last attribute. The algorithm used to compute the 504 digital signature depends on the authentication mode listed in the 505 credential. This is only partially true since for example PGP again 506 allows different algorithms to be used for computing a digital 507 signature. The algorithm used for computing the digital signature is 508 not included in the certificate itself. The algorithm identifier 509 included in the certificate only serves the purpose to allow the 511 Tschofenig Informational - Expires August 2002 10 512 verification of the signature computed by the certificate authority 513 (except for the case of self-signed certificates). 515 d) Policy Error Object 517 The Policy Error Object is used in the case of a failure of the 518 policy based admission control or other credential verification. 519 Currently available error messages allow to notify if the 520 credentials are expired (EXPIRED_CREDENTIALS), if the authorization 521 process disallowed the resource request (INSUFFICIENT_PRIVILEGES) 522 and if the given set of credentials is not supported 523 (UNSUPPORTED_CREDENTIAL_TYPE). The last error message allows the 524 user's host to discover the type of credentials supported although 525 by very inefficient means. Furthermore it is unlikely that a user 526 supports different types of credentials. The purpose of the error 527 message IDENTITY_CHANGED is unclear. The protection of the error 528 message is not discussed in [RFC3182]. 530 3.5 RSVP Integrity Handshake 532 The Integrity Handshake is a protocol that was designed to allow a 533 crashed or restarted host to obtain the latest valid challenge value 534 stored at the receiving host. A host stores the latest sequence 535 number of a fresh and correctly authenticated packet. An adversary 536 can replay eavesdropped packets if the crashed host has lost its 537 sequence numbers. A signaling message from the real sender with a 538 new sequence number would therefore allow the crashed host to update 539 the sequence number field and prevent further replays. Hence if 540 there is a steady flow of RSVP protected messages between the two 541 hosts an attacker may find it difficult to inject old messages since 542 new authenticated packets with high sequence numbers arrive and get 543 stored immediately. 545 The following description explains the details of the RSVP Integrity 546 Handshake that is started by Node A after recovering from a 547 synchronization failure: 549 Integrity Challenge 550 (1) Message (including 551 +----------+ a Cookie) +----------+ 552 | |-------------------------->| | 553 | Node A | | Node B | 554 | |<--------------------------| | 555 +----------+ Integrity Response +----------+ 556 (2) Message (including 557 the Cookie and the 558 INTEGRITY object) 560 Figure 2: RSVP Integrity Handshake 562 The details of the messages are described below: 564 Tschofenig Informational - Expires August 2002 11 565 CHALLENGE= (Key Identifier, Challenge Cookie) 566 Integrity Challenge Message:=(Common Header, CHALLENGE) 567 Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE) 569 The ôChallenge Cookieö is suggested to be a MD5 hash of a local 570 secret and a timestamp [RFC2747]. 572 The Integrity Challenge message is not protected with an INTEGRITY 573 object as show in the protocol flow above. As explained in Section 574 10 of [RFC2747] this was done to avoid problems in situations where 575 both communication parties do not have a valid starting sequence 576 number. 578 Whether or not to use the RSVP Integrity Challenge/Response 579 mechanism is a site-local decision since it may not be needed in all 580 network environments. It is however recommended to use the RSVP 581 Integrity Handshake protocol. 583 4 Detailed Security Property Discussion 585 The purpose of this section is to describe the security protection 586 of the RSVP provided mechanisms individually for authentication, 587 authorization, integrity and replay protection, user identity 588 confidentiality, confidentiality of the signaling messages. 590 4.1 Discussed Network Topology 592 The main purpose of this paragraph is to show the basic interface of 593 a simple RSVP network architecture. The architecture below assumes 594 that there is only a very single domain and that two routers are 595 RSVP and policy aware. These assumptions are relaxed in the 596 individual paragraphs as necessary. Layer 2 devices between the 597 clients and their corresponding first hop routers are not shown. 598 Other network elements like a Kerberos Key Distribution Center and 599 for example an LDAP server where the PDP retrieves his policies are 600 also omitted. The security of various interfaces to the individual 601 servers (KDC, PDP, etc.) depends very much on the security policy of 602 a specific network service provider. 604 +--------+ 605 |Policy | 606 |Decision| 607 +----+Point +---+ 608 | +--------+ | 609 | | 610 | | 611 | | 612 +------+ +-+----+ +---+--+ +------+ 613 |Client| |Router| |Router| |Client| 614 | A +-------+ 1 +--------+ 2 +----------+ B | 616 Tschofenig Informational - Expires August 2002 12 617 +------+ +------+ +------+ +------+ 618 Figure 3: Simple RSVP Architecture 620 4.2 Host/Router 622 When talking about authentication in RSVP it is very important to 623 make a distinction between user and host authentication of the 624 signaling messages. By using the RSVP INTEGRITY object the host is 625 authenticated while credentials inside the AUTH_DATA object can be 626 used to authenticate the user. In this Section the focus is on host 627 authentication whereas the next Section covers user authentication. 629 a) Authentication 631 We use the term host authentication above since the selection of the 632 security association is bound to the hostÆs IP address as mentioned 633 in Section 3.1 and 3.2. Depending on the key management protocol used 634 to create this security association and the identity used it is also 635 possible to bind a user identity to this security association. Since 636 the key management protocol is not specified it is difficult to 637 evaluate this part and hence we speak about data origin 638 authentication based on the hostÆs identity for RSVP INTEGRITY 639 objects. The fact that the host identity is used for selecting the 640 security association has already been described in Section 3.1. 642 Data origin authentication is provided with the keyed hash value 643 computed over the entire RSVP message excluding the keyed message 644 digest field itself. The security association used between the 645 userÆs host and the first-hop router is, as previously mentioned, 646 not established by RSVP and must therefore be available before the 647 signaling is started. Although not mentioned in [RFC2747] it is also 648 possible to use IPSec [RFC2401] to protect the RSVP signaling 649 traffic from the client to the first-hop router. If we use IPSec to 650 protect the interface between the userÆs host and the first hop 651 router then the optional RSVP INTEGRITY object may not be required. 652 It may also be possible (which requires a further investigation) 653 whether an existing IPSec security association may also be (re-)used 654 for RSVP. IPSec allows the key exchange protocol IKE [RFC2409] to be 655 used to dynamically negotiate IPSec security associations. Note that 656 KINK [FH+01] and other protocols are available that are also able to 657 establish an IPSec security association. This text mainly refers to 658 IKE since it is the most frequently used protocol for this purpose. 659 A detailed description of IPSec and IKE is outside the scope of this 660 document. Since IKE is computationally expensive it might create a 661 computational burden to re-establish a new IPSec SA based of the 662 movement of a mobile user host. Work at the SEAMOBY group tries to 663 tackle this problem by using IPSec Context Transfer protocols. Hence 664 in this case we would avoid triggering a separate key exchange 665 protocol run for RSVP to protect messages at each layer if they 666 terminate at the same node. 668 Tschofenig Informational - Expires August 2002 13 669 It is an open issue whether it is enough to provide IPSec protection 670 of messages between the userÆs host and the first-hop router 671 although different protocols (i.e. protocols executed at different 672 protocol layers) (possibly) terminate at different endpoints. 674 - Kerberos for the RSVP INTEGRITY object 676 As described in Section 7 of [RFC2747] Kerberos may be used to 677 create the key for the RSVP INTEGRITY object. How to learn the 678 principal name (and realm information) of the other node is outside 679 the scope of [RFC2747]. Section 4.2.1 of [RFC2747] states that the 680 required identities can be obtained statically or dynamically via a 681 directory service or DHCP. [HA01] describes a way to distribute 682 principal and realm information via DNS which can be used for this 683 purpose (assuming that the FQDN or the IP address of the other node 684 is known for which this information is desired). It is only required 685 to encapsulate the Kerberos ticket inside the policy element. It is 686 furthermore mentioned that Kerberos tickets with expired lifetime 687 must not be used and the initiator is responsible for requesting and 688 exchanging a new service ticket before expiration. 690 RSVP multicast processing in combination with Kerberos requires 691 additional thoughts: 693 Section 7 of [RFC2747] states that in the multicast case all 694 receivers must share a single key with the Kerberos Authentication 695 Server i.e. a single principal used for all receivers). From a 696 personal discussion with Rodney Hess it seems that there is 697 currently no other solution available in the context of Kerberos. 699 An additional protocol needs to be executed after each user is 700 authenticated via Kerberos to establish a session key and to allow 701 multicast specific functionality like entering a group, leaving a 702 group to be executed securely. This would additionally allow 703 accounting and billing to be used efficiently and on a per-user 704 basis. This session key is then used to protect RSVP signaling 705 messages. These issues definitely need further investigation and are 706 not fully described in this version of the document. 708 In case that one entity crashed the established security association 709 is lost and therefore the other node must retransmit the service 710 ticket. The crashed entity can use an Integrity Challenge message to 711 request a new Kerberos ticket to be retransmitted by the other node. 712 If a node receives such a request then a reply message must be 713 returned. 715 b) Integrity Protection 717 Integrity protection between the userÆs host and the first hop 718 router is based on the RSVP INTEGRITY object. Since the RSVP 719 Integrity object is an optional element of the RSVP message IPSec 720 protection of the signaling message to the router may also provide 722 Tschofenig Informational - Expires August 2002 14 723 integrity protection either with IPSec AH [RFC2402] or IPSec ESP 724 [RFC2406] as mentioned already in the previous paragraph. 726 Furthermore it is stated that other keyed hash functions apart from 727 HMAC-MD5 may be used within the RSVP INTEGRITY object and it is 728 obvious that both communicating entities must have security 729 associations indicating the algorithm used. This may be however 730 difficult since there is no negotiation protocol defined to agree on 731 a specific algorithm. Hence it is very likely that HMAC-MD5 is the 732 only usable algorithm for the RSVP INTEGRITY object if RSVP is used 733 in a mobile environment and only in local environments it may be 734 useful to switch to a different keyed hash algorithm. The other 735 possible alternative is that every implementation must support the 736 most important keyed hash algorithms for example MD5, SHA-1, RIPEMD- 737 160 etc. HMAC-MD5 was mainly chosen because of the performance 738 characteristics. The weaknesses of MD5 [DBP96] are known and 739 described in [Dob96]. Other algorithms like SHA-1 [SHA] and RIPEMD- 740 160 [DBP96] instead are known to provide better security properties. 742 c) Replay Protection 744 The main mechanism used for replay protection in RSVP are sequence 745 numbers whereby the sequence number is included in the RSVP 746 INTEGRITY object. The properties of this sequence number mechanisms 747 are described in Section 3.1. The fact that the receiver stores a 748 list of sequence numbers is an indicator for a window mechanism. 749 This somehow conflicts with the requirement that the receiver only 750 has to store the highest number given in Section 3 of [RFC2747]. We 751 assume that this is a typo. Section 4.1 of [RFC2747] gives a few 752 comments about the out-of-order delivery and the ability of an 753 implementation to specify the replay window. 755 If IPSec is used to protect RSVP messages then the optional IPSec 756 replay protection mechanism may be used which is also based on 757 sequence numbers with a window mechanism. This window mechanism may 758 (theoretically) also cause problems whereby an adversary reorders 759 messages. This is however very difficult to exploit since the 760 signaling messages are exchanged at a relatively low rate compared 761 to regular data traffic that may also be protected with IPSec. 763 - Integrity Handshake 765 The mechanism of the Integrity Handshake is explained in Section 766 3.5. The Cookie value is suggested to be hash of a local secret and 767 a timestamp. The Cookie value is not verified by the receiver. The 768 mechanism used by the Integrity Handshake is a simple 769 Challenge/Response message which assumes that the key shared between 770 the two hosts survives the crash. If the security association is 771 however dynamically created then this assumption may not be true. 773 In Section 10 of [RFC2747] the authors note that an adversary can 774 create faked Integrity Handshake message including challenge 776 Tschofenig Informational - Expires August 2002 15 777 cookies. Subsequently he would store the received response. Later he 778 tries to replay these responses while a responder recovers from a 779 crash or restart. If this replayed Integrity Response value is valid 780 and has a lower sequence number than actually used then this value 781 is stored at the recovering host. In order for this attack to be 782 successful the adversary must either have collected a large number 783 of challenge/response value pairs or the adversary ôdiscoveredö the 784 cookie generation mechanism (for example by knowing the local 785 secret). The collection of Challenge/Response pairs is even more 786 difficult since they depend on the Cookie value, on sequence number 787 included in the response message and on the shared key which is used 788 by the INTEGRITY object. 790 d) Confidentiality 792 Confidentiality is not considered to be a security requirement for 793 RSVP. Hence it is not directly supported by RSVP. However, IPSec can 794 provide confidentiality by encrypting the transmitted signaling 795 traffic with IPSec ESP. 797 e) Authorization 799 The task of authorization consists of two subcategories: Network 800 access authorization and RSVP request authorization. Access 801 authorization is provided when a node is authenticated to the 802 network e.g. via AAA protocols (for example using RADIUS [RFC2865] 803 or DIAMETER [CA+02]) and authorization information is downloaded to 804 one or more network elements for example to the access router/first 805 hop router to modify filter rules to enable the IP traffic 806 forwarding. The access router is therefore acting as a firewall with 807 dynamically created filter rules based on a successful host or user 808 authentication. Issues related to network access authorization are 809 outside the scope of RSVP. 811 The second authorization refers to RSVP itself. Depending on the 812 network configuration 813 - the router either forwards the received RSVP request to the policy 814 decision point e.g. by using COPS (see [RFC2748] and [RFC2749]) and 815 to request admission control procedure to be executed or 816 - the router supports the functionality of a PDP and therefore there 817 is no need to forward the request or 818 - the router may already be configured with the appropriate policy 819 information to decide locally whether to grant this request or not. 821 Based on the result of the admission control the request may be 822 granted or rejected. Without a policy element being embedded inside 823 the RSVP message no policy-based admission control can be done. 825 The interaction between the two access authorization procedures (and 826 the filter-installation at the various network devices) will likely 827 be investigated in more detail in the MIDCOM working group. 829 Tschofenig Informational - Expires August 2002 16 830 f) Performance 832 The computation of the keyed message digest for a RSVP INTEGRITY 833 object does not represent a performance problem. The same is true 834 for IPSec AH (or IPSec ESP). The protection of signaling messages is 835 usually not a problem since these messages are transmitted at a low 836 rate. Even a high number of messages does not cause performance 837 problems for a RSVP routers because of the characteristics of the 838 keyed message digest routine. 840 The key management which is computationally more demanding is more 841 important for scalability. Since RSVP does not specify a particular 842 key exchange protocol to be used it is difficult to estimate the 843 effort to create the required security associations. Furthermore the 844 number of key exchanges to be triggered depends on security policy 845 issues like lifetime of a security association, required security 846 properties of the key exchange protocol, authentication mode used by 847 the key exchange protocol etc. In a stationary environment with a 848 single administrative domain the manual security association 849 distribution may be acceptable and provides the best performance 850 characteristics. In a mobile environment asymmetric authentication 851 methods are likely to be used with a key exchange protocol and some 852 sort of certificate verification needs to be supported. 854 4.3 User to PEP/PDP 856 As noted in the previous section both user and host based 857 authentication is supported by RSVP. Using RSVP, a user may 858 authenticate to the first hop router or to the PDP as specified in 859 [RFC2747] depending on the infrastructure provided by the network 860 domain or on the architecture used (e.g. the integration of RSVP and 861 Kerberos V5 into the Windows 2000 Operating System [MADS01]). 862 Another architecture where RSVP is tightly integrated is the one 863 specified by the PacketCable organization. The interested reader is 864 referred to [PKTSEC] for a discussion of the security architecture. 866 a) Authentication 868 When a user sends a RSVP PATH or RESV message then this message may 869 include some information to authenticate the user. [RFC3182] 870 describes how user and application information is embedded into the 871 RSVP message (AUTH_DATA object) and how to protect it. A router 872 receiving such a message can use this information to authenticate the 873 client and forward the user/application information to the policy 874 decision point (PDP). Optionally the PDP itself can authenticate the 875 user, which is described in the next section. In order to be able to 876 authenticate the user, to verify the integrity and to check for 877 replays the entire POLICY_DATA element has to be forwarded from the 878 router to the PDP e.g. by including the element into a COPS message. 879 It is assumed that the INTEGRITY object within the POLICY_DATA 881 Tschofenig Informational - Expires August 2002 17 882 element is sent to the PDP along with all other attributes although 883 not clearly specified in [RFC3182]. 885 Certificate Verification 887 Using the policy element as described in [RFC3182] it is not 888 possible to provide a certificate revocation list or other 889 information to proof the validity of the certificate inside the 890 policy element. A specific mechanism for certificate verification is 891 not discussed in [RFC3182] and hence a number of them can be used 892 for this purpose. For certificate verification the network element 893 (a router or the policy decision point), which has to authenticate 894 the user, could frequently download certificate revocation lists or 895 should use a protocol like the Online Certificate Status Protocol 896 (OCSP) [RFC2560] and the Simple Certificate Validation Protocol 897 (SCVP) [MHHF01] to determine the current status of a digital 898 certificate. 900 User Authentication to the PDP 902 This alternative authentication procedure uses the PDP to 903 authenticate the user instead of the first hop router. In Section 904 4.2.1 in [RFC3182] the choice is given for the user to either obtain 905 a session ticket for the next hop router or for the PDP. As noted in 906 the same Section the identity of the PDP or the next hop router is 907 statically configured or dynamically retrieved. Subsequently user 908 authentication to the PDP is considered. 910 Kerberos-based Authentication to the PDP 912 If Kerberos is used to authenticate the user then first a session 913 ticket for the PDP needs to be requested. If the user roams between 914 different routers in the same administrative domain then he does not 915 need to request a new service ticket since the PDP is likely to be 916 used by most or all first-hop routers within the same administrative 917 domain. This is different if a session ticket for a router has to be 918 obtained and authentication to a router is required. The router 919 therefore plays a passive role of forwarding the request only to the 920 PDP and executing the policy decision returned by the PDP. 922 Section 4.5.3 describes one example of user-to-PDP authentication. 924 User authentication with the policy element only provides unilateral 925 authentication where the client authenticates to the router or to 926 the PDP. If a RSVP message is sent to the userÆs host and public 927 keyed based authentication is used then the message does not contain 928 a certificate and digital signature. Hence no mutual authentication 929 can be assumed. In case of Kerberos mutual authentication may be 930 accomplished if the PDP or the router transmits a policy element 931 with an INTEGRITY object computed with the session key retrieved 932 from the Kerberos ticket or if the Kerberos ticket included in the 933 policy element is also used for the RSVP INTEGRITY object as 935 Tschofenig Informational - Expires August 2002 18 936 described in Section 4.2. This procedure only works if a previous 937 message was transmitted from the end-host to the network and such 938 key is already established. [RFC3182] does not discuss this issue 939 and therefore there is no particular requirement dealing with 940 transmitting network specific credentials back to the end-user's 941 host. 943 b) Integrity Protection 945 The integrity protection of the RSVP message and the POLICY_DATA 946 element are protected separately as shown in Figure 1. In case of a 947 policy ignorant node along the path the RSVP INTEGRITY object and 948 the INTEGRITY object inside the policy element terminate at 949 different nodes. Basically the same is true for the credentials of 950 the user if they are verified at the policy decision point instead 951 of the first hop router. 953 - Kerberos 955 If Kerberos is used to authenticate the user to the first hop router 956 then the session key included in the Kerberos ticket may be used to 957 compute the INTEGRITY object of the policy element. It is the keyed 958 message digest that provides the authentication. The existence of 959 the Kerberos service ticket inside the AUTH_DATA object does not 960 provide authentication and a guarantee of freshness for the 961 receiving host. Authentication and guarantee of freshness is 962 provided by the keyed hash value of the INTEGRITY object inside the 963 POLICY_DATA element. The user thereby shows that he actively 964 participated in the Kerberos protocol and that he was able to obtain 965 the session key to compute the keyed message digest. The 966 Authenticator used in the Kerberos V5 protocol provides similar 967 functionality but replay protection is based on timestamps (or based 968 on sequence number if the optional seq-number field inside the 969 Authenticator is used for KRB_PRIV/KRB_SAFE messages as described in 970 Section 5.3.2 of [RFC1510]) . 972 - Digital Signature 974 If public key based authentication is provided then user 975 authentication is accomplished with the digital signature. As 976 explained in Section 3.3.3 of [RFC3182] the DIGITAL_SIGNATURE 977 attribute must be the last attribute in the AUTH_DATA object and the 978 digital signature covers the entire AUTH_DATA object. Which hash 979 algorithm and public key algorithm is used for the digital signature 980 computation is described in [RFC2440] in case that PGP is used. In 981 case of X.509 credentials the situation is more complex since 982 different mechanisms like CMS [RFC2630] or PKCS#7 [RFC2315] may be 983 used for the digitally signing the message element. X.509 only 984 provides the standard for the certificate layout which seems to 985 provide insufficient information for this purpose. Therefore X.509 986 certificates are supported for example by CMS and PKCS#7. [RFC3182], 987 however, does not make any statements about the usage of CMS and 989 Tschofenig Informational - Expires August 2002 19 990 PKCS#7. Currently there is no support for CMS or PKCS#7 described in 991 [RFC3182], which provides more than only public key based 992 authentication (e.g. CRL distribution, key transport, key agreement, 993 etc.). Furthermore the usage of PGP in RSVP is vague since there are 994 different versions of PGP (including a OpenPGP [RFC2440]) and there 995 has been no indication which version should be used. When thinking 996 about CMS support for RSVP the main question that has to be answered 997 is whether a public key based authentication (and key agreement 998 mechanism) should be supported for a QoS signaling protocol. 999 Especially the risks of denial of service attacks, large processing, 1000 memory and bandwidth utilization should be considered. 1002 If the INTEGRITY object is not included in the POLICY_DATA element or 1003 not sent to the PDP then we have to make the following observation: 1005 a) For the digital signature case only the replay protection provided 1006 by the digital signature algorithm can be used. It is however not 1007 clear whether this usage was anticipated or not. Hence we might 1008 assume that the replay protection is based on the availability of 1009 RSVP INTEGRITY object used with a security association that is 1010 established by other means. 1012 b) If a Kerberos session ticket is included but without using the 1013 Kerberos session key then the analogon of the Kerberos Authenticator 1014 is missing. Obviously there is no guarantee that the user actually 1015 followed the Kerberos protocol and was able to decrypt the received 1016 TGS_REP (or in rare cases the AS_REP if a session ticket is requested 1017 with the initial AS_REQ). 1019 c) Replay Protection 1021 Figure 4 below shows the interfaces relevant for replay protection 1022 of signaling messages in a more complicated architecture. The client 1023 therefore uses the policy data element with PEP2 since PEP1 is not 1024 policy aware. The interfaces between the client and the PEP1 and 1025 between the PEP1 and PEP2 are protected with the RSVP INTEGRITY 1026 object. The link between the PEP2 and the PDP is protected for 1027 example by using the COPS built-in INTEGRITY object. The dotted line 1028 between the Client and the PDP indicates the protection provided by 1029 the AUTH_DATA element which has no RSVP INTEGRITY object included. 1031 AUTH_DATA +----+ 1032 +- - - - - - - - - - - - - - - - - - - - - - - - - -+PDP +-+ 1033 +----+ | 1034 | | 1035 | 1036 | COPS | 1037 INTEGRITY| 1038 | | 1039 | 1040 | | 1041 +--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ | 1043 Tschofenig Informational - Expires August 2002 20 1044 |Client+-------------------+PEP1+----------------------+PEP2+-+ 1045 +--+---+ +----+ +-+--+ 1046 | | 1047 +-----------------------------------------------------+ 1048 POLICY_DATA INTEGRITY 1050 Figure 4: Replay Protection 1052 Host authentication with the RSVP INTEGRITY object and user 1053 authentication with the INTEGRITY object inside the POLICY_DATA 1054 element both use the same replay mechanism. The length of the 1055 Sequence Number field, sequence number rollover and the Integrity 1056 Handshake is already explained in Section 3.1. 1058 Section 9 in [RFC3182] states ôRSVP INTEGRITY object is used to 1059 protect the policy object containing user identity information from 1060 security (replay) attacks.ö. Hence the public key based 1061 authentication does not support the RSVP based replay protection 1062 since the digital signature does not cover the POLICY_DATA INTEGRITY 1063 object with its Sequence Number field. The digital signature covers 1064 the entire AUTH_DATA object. 1066 The use of public key systems within the AUTH_DATA object 1067 complicates replay protection. Digital signature computation with 1068 PGP is described in [PGP] and in [RFC2440]. The data structure 1069 preceding the signed message digest includes information about the 1070 message digest algorithm used and a 32-bit timestamp when the 1071 signature was created ("Signature creation time"). The timestamp is 1072 included in the computation of the message digest. The IETF 1073 standardized OpenPGP version [RFC2440] contains more information and 1074 describes the different hash algorithms (MD2, MD5, SHA-1, RIPEMD- 1075 160) provided. [RFC3182] does not make any statements whether the 1076 "Signature creation time" field is used for replay protection. Using 1077 timestamps for replay protection requires different synchronization 1078 mechanisms in case of clock-screws. Traditionally "loosely" 1079 synchronized clocks are assumed in those cases but also requires 1080 specifying a replay-window. 1082 If the "Signature creation time" is not used for replay protection 1083 then a malicious policy ignorant node can use this weakness to 1084 replace the user's credentials without destroying the digital 1085 signature. Additionally the RSVP initiating host, where multiple 1086 users may have access, must be trustworthy even if a smartcard is 1087 used since otherwise, replay attacks with a recorded AUTH_DATA 1088 object are possible. Note that this however violates the hop-by-hop 1089 security assumption. It is therefore assumed that replay protection 1090 of the user credentials is not considered as an important security 1091 requirement since the hop-by-hop processing of the RSVP message 1092 protects the message against modification by an adversary between 1093 two communicating nodes. 1094 There are two additional issues related to a Kerberos based user 1095 authentication in the context of replay protection. The lifetime of 1097 Tschofenig Informational - Expires August 2002 21 1098 the Kerberos ticket is based on the fields starttime and endtime of 1099 the EncTicketPart structure of the ticket as described in Section 1100 5.3.1 of [RFC1510]. Since the ticket is created by the KDC located 1101 at the network of the verifying entity it is not difficult to have 1102 the clocks roughly synchronized for the purpose of lifetime 1103 verification. Additional information about clock-synchronization and 1104 Kerberos can be found at [DG96]. 1106 If we assume that the Kerberos session key is used for RSVP then 1107 there may be a need for rekeying. If we assume that a policy at the 1108 user's host indicates when to rekey then the next RSVP message 1109 includes a new Kerberos session ticket that is then used by the 1110 verifying entity. If the lifetime of the Kerberos ticket or other 1111 policies do not affect rekeying then an RSVP security association 1112 may never require rekeying at all because of the large sequence 1113 number space. 1115 d) (User Identity) Confidentiality 1117 This Section discusses the privacy protection of the identity 1118 information transmitted inside the policy element. Especially the 1119 user identity confidentiality is of interest because there is no 1120 built-in RSVP mechanism for encryption of the POLICY_DATA or the 1121 AUTH_DATA elements. The encryption of one of the attributes inside 1122 the AUTH_DATA element - of the POLICY_LOCATOR attribute is discussed 1123 in the next section. 1125 There has often been the discussion whether the effort for 1126 protecting user identity is worth the additional complexity. With 1127 the increasing privacy awareness there must be at least a discussion 1128 on the mechanisms provided by the given protocol. The main question 1129 in this context is about the threat model i.e. against which entity 1130 the user identity should be protected. Since RSVP does not make any 1131 assumptions about the underlying key management protocol for most 1132 parts it is difficult to make a judgment. However for the identity 1133 representation part of the protocol it is possible to make some 1134 observations. We assume that the most important threat for a user is 1135 to reveal his identity to an adversary located between the userÆs 1136 host and the first-hop router. Identities should furthermore not be 1137 transmitted outside the domain of the visited network provider i.e. 1138 the user identity information inside the policy data element should 1139 be removed or modified by the PDP to prevent revealing information 1140 to other (non-authorized) entities along the signaling path. We 1141 cannot however provide user identity confidentiality against the 1142 network provider to which the user is attached. Different mechanisms 1143 must be deployed to disallow the network provider to create a 1144 profile of the user. These mechanisms are outside the scope of this 1145 document since there is a strong involvement with the initial 1146 authentication and key agreement protocol executed between the user 1147 and the visited network. 1149 Tschofenig Informational - Expires August 2002 22 1150 If the link between the userÆs host and the first hop router is 1151 protected with IPSec ESP then confidentiality of the entire 1152 signaling messages is provided. Note however that the IPSec 1153 protection may terminate at the different node than the RSVP policy 1154 aware signaling does. The focus of this Section is, however, the 1155 functionality provided by RSVP. 1157 The ASCII or Unicode distinguished name of user or application 1158 inside the POLICY_LOCATOR attribute of the AUTH_DATA element may be 1159 encrypted as specified in Section 3.3.1 of [RFC3182]. The user (or 1160 application) identity is then encrypted with either the Kerberos 1161 session key or with the private key in case of public key based 1162 authentication. Since the private key is used we usually speak of a 1163 digital signature which can be verified by everyone possessing the 1164 public key. Since the certificate with the public key is included in 1165 the message itself this is no obstacle. Furthermore the included 1166 certificate provides enough identity information for an eavesdropper 1167 together with the additional (unencrypted) information provided in 1168 the RSVP message. Hence the possibility of encrypting the policy 1169 locator in case of public key based authentication is less obvious. 1170 To encrypt the identities using asymmetric cryptography the userÆs 1171 host must be able to somehow retrieve the public key of the entity 1172 verifying the policy element (i.e. the first policy aware router or 1173 the PDP). Currently no such mechanism is defined in [RFC3182]. 1175 There is no option to encrypt the user or application identity 1176 without Kerberos or public key mechanisms are used since the 1177 selection of an appropriate security association is not possible. 1179 The algorithm used to encrypt the POLICY_LOCATOR with the Kerberos 1180 session key is assumed to be the same as the one used for encrypting 1181 the service ticket. The information about the used algorithm is 1182 available in the etype field of the EncryptedData ASN.1 encoded 1183 message part. Section 6.3 of [RFC1510] lists the supported 1184 algorithms. [Rae01] defines new encryption algorithms (Rijndael, 1185 Serpent, and Twofish) that were published in the context of the AES 1186 competition. 1188 The task of evaluating the confidentiality provided for the user 1189 requires to look at protocols executed outside of RSVP (for example 1190 to look at the Kerberos protocol). The ticket included in the 1191 CREDENTIAL attribute may provide user identity protection by not 1192 including the optional cname attribute inside the unencrypted part 1193 of the Ticket. Since the Authenticator is not transmitted with the 1194 RSVP message the cname and the crealm of the unencrypted part of the 1195 Authenticator are not revealed. In order for the user to request the 1196 Kerberos session ticket, for inclusion in the CREDENTIAL attribute, 1197 the Kerberos protocol exchange must be executed. Then the 1198 Authenticator sent with the TGS_REQ reveals the identity of the 1199 user. The AS_REQ must also include the user identity to allow the 1200 Kerberos Authentication Server to respond with an AS_REP message 1202 Tschofenig Informational - Expires August 2002 23 1203 that is encrypted with the user's secret key. Using Kerberos, it is 1204 therefore only possible not to reveal content of the encrypted 1205 policy locator, which is only useful if this value differs from the 1206 user identity used with Kerberos. Hence using Kerberos it is not 1207 "entirely" possible to provide user identity confidentiality. 1209 It is important to note that information stored in the policy 1210 element may be changed by a policy aware router or by the policy 1211 decision point. Which parts are changed depends upon whether 1212 multicast or unicast is used, how the policy server reacts, where 1213 the user is authenticated and whether he needs to be re- 1214 authenticated in other network nodes etc. Hence user and application 1215 specific information can leak after the messages leave the first hop 1216 within the network where the user's host is attached. As mentioned 1217 at the beginning of this Section this information leakage is assumed 1218 to be intentional. 1220 e) Authorization 1222 Additional to the description of the authorization steps of the 1223 Host/Router interface, user based authorization is added with the 1224 policy element providing user credentials. The inclusion of user and 1225 application specific information enables policy-based admission 1226 control with special user policies that are likely to be stored at a 1227 dedicated server. Hence a Policy Decision Point can query for 1228 example a LDAP server for a service level agreement stating the 1229 amount of resources a certain user is allowed to request. Additional 1230 to the user identity information group membership and other non- 1231 security related information may contribute to the evaluation of the 1232 final policy decision. If the user is not registered to the 1233 currently attached domain then there is the question of how much 1234 information the home domain of the user is willing to exchange. This 1235 also impacts the users privacy policy. In general the user may not 1236 want to distribute much of his policy information. Furthermore the 1237 missing standardized authorization data format may create 1238 interoperability problems when exchanging policy information. Hence 1239 we can assume that the policy decision point may use information 1240 from an initial authentication and key agreement protocol which may 1241 already required cross-realm communication with the user's home 1242 domain to only assume that the home domain knows the user and that 1243 the user is entitled to roam and to be able to forward accounting 1244 messages to this domain. This represents the traditional subscriber 1245 based accounting scenario. Non-traditional or alternative means of 1246 accounting might be deployed in the near future that do not require 1247 the any type of inter-domain communication. Obviously there is a 1248 strong interrelationship between the authorization and the process 1249 of accounting. Note that the term accounting in this context is not 1250 only related to process of metering. Metering is only the process of 1251 measuring and collecting resource usage information. Instead the 1252 term unites metering, pricing, charging and billing. 1254 f) Performance 1256 Tschofenig Informational - Expires August 2002 24 1257 If Kerberos is used for user authentication then a Kerberos ticket 1258 must be included in the CREDENTIAL Section of the AUTH_DATA element. 1259 The Kerberos ticket has a size larger than 500 bytes but only needs 1260 to be sent once since a performance optimization allows the session 1261 key to be cached as noted in Section 7.1 of [RFC2747]. It is assumed 1262 that subsequent RSVP messages only include the POLICY_DATA INTEGRITY 1263 object with a keyed message digest that uses the Kerberos session 1264 key. This however assumes that the security association required for 1265 the POLICY_DATA INTEGRITY object is created after (or modified) to 1266 allow the selection of the correct key. Otherwise it difficult to 1267 say which identifier is used to index the security association. 1269 When Kerberos is used as an authentication system then, from a 1270 performance perspective, then the message exchange to obtain the 1271 session key needs to be considered although the exchange only needs 1272 to be done once in a long time frame depending on the lifetime of 1273 the session ticket. This is particularly true in a mobile 1274 environment with a fast roaming user's host. 1276 Public key based authentication usually provides the best 1277 scalability characteristics for key distribution but the protocols 1278 are performance demanding. A major disadvantage of the public key 1279 based user authentication in RSVP is the non-existing possibility to 1280 derive a session key. Hence every RSVP PATH or RESV message includes 1281 the certificate and a digital signature, which is a huge performance 1282 and bandwidth penalty. For a mobile environment with low performance 1283 devices, high latency and low bandwidth links this seems to be less 1284 encouraging. Note that a public key infrastructure is required to 1285 allow the PDP (or the first-hop router) to verify the digital 1286 signature and the certificate. To check for revoked certificates, 1287 certificate revocation lists or protocols like the Online 1288 Certificate Status Protocol [RFC2560] and the Simple Certificate 1289 Validation Protocol [MHHF01]. Then the integrity of the AUTH_DATA 1290 object via the digital signature is verified. 1292 4.4 Communication between RSVP aware routers 1294 a) Authentication 1296 RSVP signaling messages are data origin authenticated and protected 1297 against modification and replay using the RSVP INTEGRITY object. 1298 IPSec may also provide RSVP signaling message protection. The RSVP 1299 message flow between routers is protected based on the chain of trust 1300 and hence each router only needs to have a security association with 1301 its neighboring routers. This assumption was made because of 1302 performance advantages and because of special security 1303 characteristics of the core network where no user hosts are directly 1304 attached. In the core network the network structure does not change 1305 frequently and the manual distribution of shared secrets for the RSVP 1306 INTEGRITY object may be acceptable. The shared secrets may be either 1308 Tschofenig Informational - Expires August 2002 25 1309 manually configured or distributed by using network management 1310 protocols like SNMP. 1312 If IPSec is used in a hop-by-hop fashion then the required security 1313 associations may be manually created or dynamically distributed with 1314 IKE by either using symmetric or asymmetric authentication modes. A 1315 description of the existing IKE authentication modes and IKE security 1316 properties is outside the scope of this document. The reader is 1317 referred to the relevant documents at the IPSec working group. 1319 Independent of the key distribution mechanism host authentication 1320 with RSVP built-in mechanisms is accomplished with the keyed message 1321 digest in the RSVP INTEGRITY object computed using the previously 1322 exchanged symmetric key. In case of IPSec host authentication is 1323 accomplished with the keyed message digest included in the 1324 Authentication Data field of the IPSec Authentication Header 1325 included in every IP packet. 1327 b) Integrity Protection 1329 Integrity protection is either accomplished with the RSVP INTEGRITY 1330 object with the variable length Keyed Message Digest field or with 1331 the IPSec Authentication Header. A description of the IPSec AH is 1332 found in [RFC2402] and IPSec ESP [RFC2406] with null encryption is 1333 found in [RFC2410]. The main difference between IPSec and RSVP 1334 protection is the layer at which the security is applied. 1336 c) Replay Protection 1338 Replay protection with the RSVP INTEGRITY object is extensively 1339 described in previous Sections. IPSec provides an optional window- 1340 based replay protection, which may cause problems if a strict 1341 message ordering of RSVP messages is required. This problem was 1342 already discussed in a previous Section and a possible solution is 1343 to include the RSVP INTEGRITY object without a key, which reduces 1344 the RSVP integrity protection to a simple MD5 hash. This 1345 modification must however be integrated into an existing 1346 implementation and it is not clear whether the RSVP standard allows 1347 this modification. If the RSVP implementation is able to access the 1348 IPSec Security Association Database and retrieve the required 1349 security association then no such modification to RSVP is required 1350 and IKE is only used to distribute the security associations. This 1351 however requires the RSVP implementation to trigger the IKE 1352 exchange. 1354 To enable crashed hosts to learn the latest sequence number used the 1355 Integrity Handshake mechanism is used in RSVP as explained in a 1356 Section above. IPSec does not provide such a mechanism since a 1357 crashed host looses its negotiated security associations and 1358 therefore has to re-negotiate them using IKE. Note that manually 1359 configured IPSec security associations do not provide replay 1360 protection because a sequence number rollover would require the 1362 Tschofenig Informational - Expires August 2002 26 1363 establishment of a new SA. This is obviously not possible when using 1364 manually configured IPSec SAs. Using IKE with pre-shared secrets is 1365 therefore a simple solution. 1367 d) Confidentiality 1369 Confidentiality is not provided by RSVP but using IPSec ESP in a hop- 1370 by-hop mode can provide it. The usage of IPSec ESP for RSVP is not 1371 recommended because of the additional overhead for little additional 1372 security benefit if we think of the underlying assumed trust model of 1373 chain of trust. Hence there must be a good reason why to require 1374 confidentiality in a hop-by-hop fashion in the core network of the 1375 same administrative domain. If the RSVP network spawns different 1376 provider networks then it is possible to encapsulate RSVP messages 1377 between RSVP networks over a non-RSVP cloud similar to a VPN. Such a 1378 configuration is mainly determined by the network structure of a 1379 provider. 1381 e) Authorization 1383 Depending on the RSVP network QoS resource authorization at 1384 different routers may need to contact the PDP again. Since the PDP 1385 is allowed to modify the policy element, a token may be added to the 1386 policy element to increase the efficiency of the re-authorization 1387 procedure. This token is used to refer to an already computed policy 1388 decision. The communications interface from the PEP to the PDP must 1389 be properly secured. 1391 f) Performance 1393 The performance characteristics the protection of the RSVP signaling 1394 messages is largely determined by the key exchange protocol since 1395 the RSVP INTEGRITY object or IPSec AH are only used to compute a 1396 keyed message digest of the transmitted messages. Furthermore only 1397 RSVP signaling messages are protected and the protection of the 1398 application data stream is outside the scope of RSVP. IPSec ESP 1399 provides a performance penalty but may only be rarely used. A 1400 network administrator may however use IPSec ESP in transport mode 1401 with NULL encryption to provide the same functionality as IPSec AH 1402 but with the chance of better hardware support. 1404 The security associations within the core network i.e. between 1405 individual routers (in comparison to the security association 1406 between the userÆs host and the first-hop router or with the 1407 attached network in general) can be established more easily because 1408 of the strong trust assumptions. Furthermore it is possible to use 1409 security associations with an increased lifetime to avoid too 1410 frequent rekeying. Hence there is less impact for the performance 1411 compared to the user to network interface. The security association 1412 storage requirements are also less problematic. 1414 Tschofenig Informational - Expires August 2002 27 1415 4.5 Miscellaneous Issues 1417 4.5.1 Dictionary Attacks and Kerberos 1419 This Section addresses issues related to Kerberos and its 1420 vulnerability against dictionary attacks since there often seems to 1421 be a misunderstanding. The reason for including this discussion in 1422 this document is that Kerberos seems to be one of the most widely 1423 supported authentication and key distribution systems available. 1425 The initial Kerberos AS_REQ request (without pre-authentication, 1426 various extensions and without PKINIT) is unprotected. The response 1427 message AS_REP is encrypted with the client's long-term key. An 1428 adversary can take advantage of this fact by requesting AS_REP 1429 messages to mount an off-line dictionary attack. Using pre- 1430 authentication ([Pat92]) can be used to reduce this problem. 1431 However pre-authentication does not entirely prevent dictionary 1432 attacks by an adversary since he can still eavesdrop Kerberos 1433 messages if being located at the path between the mobile node and 1434 the KDC. With mandatory pre-authentication for the initial request 1435 an adversary cannot request a Ticket Granting Ticket for an 1436 arbitrary user. On-line password guessing attacks are still possible 1437 by choosing a password (e.g. from a dictionary) and then 1438 transmitting an initial request including pre-authentication data 1439 field. An unsuccessful authentication by the KDC results in an error 1440 message and the gives the adversary a hint to try a new password and 1441 restart the protocol again. 1443 There are however some proposals that prevent dictionary attacks 1444 from happening. The use of Public Key Cryptography for initial 1445 authentication [TN+01] (PKINIT) is one such solution. Other 1446 proposals use strong-password based authenticated key agreement 1447 protocols like the Encrypted Key Exchange protocol (EKE) to avoid 1448 leaking of user password information. B. Jaspan investigated the use 1449 of EKE for Kerberos V5 called ôDual-workfactor Encrypted Key 1450 Exchangeö [Jas96] which is described below. 1452 With the PA-ENC-DH pre-authentication Jaspan included the Diffie- 1453 Hellman ôpublic keyö of the client encrypted with the user password 1454 in the initial AS_REQ to the Authentication Server. Additionally the 1455 modulus m is included since the client can choose this value 1456 dynamically. 1458 It is interesting to note that pre-authentication was orginally 1459 introduced to allow the user to authenticate to the AS with the 1460 inital AS_REQ message . The use of the Encrypted Key Exchange 1461 protocol [BM92] as a pre-authentication mechanism does not allow the 1462 Authentication Server to authenticate the client since this would 1463 require the client to include verifiable data (e.g. a keyed message 1464 digest for data origin authentication) but this destroys the 1465 properties of EKE. EKE was designed to create a strong-password 1466 based authentication protocol that is resistant against dictionary 1468 Tschofenig Informational - Expires August 2002 28 1469 attacks. Hence after the second message the Authentication Server 1470 is authenticated to the client by showing that he was able to 1471 compute the shared key k(a,as) used to encrypt the first part of 1472 message (2). The client is not authenticated to the Authentication 1473 Server. 1475 It is obvious that both the client and the Authentication Server 1476 must be able to provide good random numbers for the creation of the 1477 Diffie-Hellman key pair. Jaspan additionally noted that the 1478 timestamp in the response from the Authentication Server (AS_REP 1479 message) can be used to eliminate the dependency on time 1480 synchronization of the Kerberos protocol. The client can use this 1481 value to adjust his clock after successful authentication of the 1482 Authentication Server. 1484 The vulnerability against denial of service attacks is a 1485 disadvantage common to many strong-password based authenticated key 1486 agreement protocols. Nothing prevents an adversary from flooding the 1487 Authentication Server with bogus AS_REQ messages using the pre- 1488 authentication method PA-ENC-DH. This forces the Authentication 1489 Server to create a Diffie-Hellman public/private key pair, to 1490 decrypt the received response and to compute the session key k(a,as) 1491 and to return a message to the source IP address of the previously 1492 received message. Even if the Authentication Server does not re- 1493 create a new public/private key pair with every session he still has 1494 to compute the session key which requires multiprecision operations 1495 and this is time consuming. 1497 Jaspan furthermore noted that the missing client authentication can 1498 be used by an undetectable on-line password guessing attack as 1499 described in [DH95]. An adversary sends an AS_REQ for a user B 1500 encrypted with a password k(bÆ). The Authentication Server decrypts 1501 the value of the pre-authentication field with the real user 1502 password k(b) and encrypts his response to the adversary. If the 1503 adversary correctly guessed the password of user B then the receive 1504 response verifies correctly. Jaspan proposed to modify the KDC to 1505 allow only a certain number of requests per day but this can be used 1506 by an attacker to mount a denial of service attack against such 1507 users to lock their accounts by sending a number of incorrect 1508 requests to the KDC. The KDC would then reject Ticket Granting 1509 Ticket or even a service ticket from legitimate users. 1511 Tom Wu mentioned in [Wu99] the use of a variant of SRP [Wu98] and 1512 the use of SPEKE [Jab96] to be used in the pre-authentication 1513 process as possible candidates to prevent dictionary attacks. 1514 Unfortunately Wu does not explain the proposals in detail. 1516 Currently only PKINIT is available for preventing off-line 1517 dictionary attacks. Other proposals described above like SPEKE, SRP 1518 etc. are not included in the current Kerberos version. IPR issues 1519 may be one of the reasons. 1521 Tschofenig Informational - Expires August 2002 29 1522 4.5.2 Example of User-to-PDP Authentication 1524 The following Section describes an example of user-to-PDP 1525 authentication. Note that the description below is not fully covered 1526 by the RSVP specification and hence it should only be seen as an 1527 example. 1529 Windows 2000, which integrates Kerberos into RSVP, uses a 1530 configuration with the user authentication to the PDP as described 1531 in [MADS01]. The steps for authenticating the user to the PDP in an 1532 intra-realm scenario are the following: 1534 - Windows 2000 requires the user to contact the KDC and to request a 1535 Kerberos service ticket for the PDP account AcsService in the local 1536 realm. 1538 - This ticket is then embedded in the AUTH_DATA element and included 1539 in either the PATH or the RESV message. In case of MicrosoftÆs 1540 implementation the user identity encoded as a distinguished name is 1541 encrypted with the session key provided with the Kerberos ticket. 1542 The Kerberos ticket is sent without the Kerberos authdata element 1543 that contains authorization information as explained in [MADS01]. 1545 - The RSVP message is then intercepted by the PEP who forwards it to 1546 the PDP. [MADS01] does not state which protocol is used to forward 1547 the RSVP message to the PDP. 1549 - The PDP who finally receives the message decrypts the received 1550 service ticket. The ticket contains the session key which was used 1551 by the user's host to 1552 a) Encrypt the principal name inside the policy locator field of the 1553 AUTH_DATA object and to 1554 b) Create the integrity protected Keyed Message Digest field in the 1555 INTEGRITY object of the POLICY_DATA element. The protection 1556 described here is between the user's host and the PDP. The RSVP 1557 INTEGRITY object on the other hand is used to protect the path 1558 between the users host and the first-hop router since the two 1559 message parts terminate at a different node and a different security 1560 association must be used. The interface between the message 1561 intercepting first-hop router and the PDP must be protected as well. 1562 c) The PDP does not maintain a user database and [MADS01] describes 1563 that the PDP may query the Active Directory (a LDAP based directory 1564 service) for user policy information. 1566 4.5.3 Open Issues 1568 The following issues have often been mentioned in the context of 1569 RSVP. However a design decision with regard to end-to-end security 1570 and a framework for accounting and charging cannot be found in the 1571 main RSVP documents. 1573 a) End-to-End Security Issues and RSVP 1575 Tschofenig Informational - Expires August 2002 30 1576 End-to-end security for RSVP has not been discussed throughout the 1577 document. In this context end-to-end security refers to credentials 1578 transmitted between the two end-hosts using RSVP. It is obvious that 1579 care must be taken to ensure that routers along the path are able to 1580 process and modify the signaling messages according to the 1581 processing procedure. Some objects however could be used for end-to- 1582 end protection. The main question however is what the benefit of 1583 such an end-to-end security is. First there is the question how to 1584 establish the required security association which turned out to be 1585 quite difficult between two arbitrary hosts. Furthermore it depends 1586 on an architecture where RSVP is deployed whether it is useful to 1587 provide end-to-end security. If RSVP is only used to signal QoS 1588 information into the network and other protocols have to be executed 1589 beforehand to negotiate the parameters and to decide which entity 1590 actually has to pay for the reservation then no end-to-end security 1591 is likely to be required. End-to-end security if introduced into 1592 RSVP would then cause problem with extensions like RSVP proxy 1593 [GD+02], Localized RSVP [MS+02] and others which terminate RSVP 1594 signaling somewhere along the path without reaching the destination 1595 end-host. Such a behavior could then be interpreted as a man-in-the- 1596 middle attack. 1598 b) Accounting/Charging Framework 1600 Many documents have been published in the context of accounting and 1601 charging for RSVP/IntServ, pricing, business models etc. The reasons 1602 for large number of proposals and the ôrareö number of used 1603 mechanisms are manifold. The lack of a defined framework makes it 1604 difficult to argument whether the processing of credentials within 1605 the policy element and a possible forwarding to other network 1606 domains is required. Forwarding user credentials would allow other 1607 networks to authenticate the identity acting as a signaling source. 1608 If credentials are however removed then no such behavior can be 1609 achieved and each neighboring domain only exchanges accounting data 1610 to the next domain without taking the length of the real number of 1611 visited domains into consideration. Scalability problems in the core 1612 network speak against solutions that verify the user credentials by 1613 every network along the path or solutions that create an analogon to 1614 a long-distance call. A long-distance call in terms of RSVP can be 1615 simulated by adding a monetary value for the requested resource at 1616 each network along the path. Issues related to accounting will 1617 receive further attention in the NSIS framework discussion. 1619 5 Conclusions 1621 It is often argued that RSVP cannot be used in particular 1622 environments. Whether this is true or not cannot be answered by the 1623 author but what can be observed is the following: RSVP should be 1624 seen as a building block that has to be adapted to provide the 1625 desired services for a given architecture. The point to stress is 1626 "architecture". Hence it is difficult to state whether RSVP provides 1628 Tschofenig Informational - Expires August 2002 31 1629 the adequate security for a given architecture without a particular 1630 framework. The author represents the opinion that the RSVP designers 1631 and architects did a good job in providing the necessary blocks 1632 (including security relevant parts) that allows RSVP to be easily 1633 adapted to most architectures. By including some RSVP extensions 1634 additional flexibility and features are provided. 1636 This document aims to provide more insights into the security of 1637 RSVP explained with different words from a different view. It must 1638 not be interpreted as a pass or fail evaluation of the security 1639 provided by RSVP. 1641 Certainly this document is not complete to describe all issues 1642 related to RSVP but it serves as a starting point. Some issues that 1643 require further considerations are RSVP extensions (for example 1644 [RFC2207]), multicast issues and other security properties like 1645 traffic analysis etc. Additionally the interaction with mobility 1646 protocols (micro- and macro-mobility) from a security point of view 1647 demands further investigation. As stated in the previous Section the 1648 interaction with accounting/charging issues are worth a closer look. 1650 What can be learned from a practical protocol experience and from 1651 the increased awareness regarding security is that some of the 1652 available credential types have received more acceptance. Kerberos 1653 is such a system which is integrated in many IETF protocols today. 1654 Public key based authentication techniques are however still 1655 considered to be too heavy-weight (computationally and from a 1656 bandwidth perspective) to be used for a per-flow signaling. The 1657 increased focus on denial of service attacks additionally demands a 1658 closer look on public key based authentication. 1660 6 Security Considerations 1662 This document discusses security properties of RSVP and as such, it 1663 is concerned entirely with security. 1665 7 IANA considerations 1667 This document does not address any IANA considerations. 1669 8 Acknowledgments 1671 I would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu and 1672 Guenther Schaefer for their valuable comments. Additionally I would 1673 like to thank Robert and Jorge for their time to discuss various 1674 issues with me. Furthermore I would like to thank Marc De Vuyst for 1675 his comments to the draft. 1677 9 References 1679 [BM92] Bellovin, B., Merrit, M.: ôEncrypted Key Exchange: 1680 Password-based protocols secure against dictionary 1682 Tschofenig Informational - Expires August 2002 32 1683 attacksö, in ôProceedings of the IEEE Symposium on 1684 Research in Security and Privacyö, May, 1992. 1686 [CA+02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G., Loughney, 1687 J.: "DIAMETER Base Protocol", , (work in progress), March, 2002. 1690 [DBP96] Dobbertin, H., Bosselaers, A., Preneel, B.: "RIPEMD-160: 1691 A strengthened version of RIPEMD", in ôFast Software 1692 Encryption, LNCS Vol 1039, pp. 71-82ö, 1996. 1694 [DG96] Davis, D., Geer, D.: ôKerberos With Clocks Adrift: 1695 History, Protocols and Implementationö, in ôUSENIX 1696 Computing Systems Volume 9 no. 1, Winterö, 1996. 1698 [DH95] Ding, Y., Horster, P.: ôUndetectable On-line Password 1699 Guessing Attacksö, Operating Systems Review, 29(No. 4), 1700 pp. 77-86, 1995. 1702 [Dob96] Dobbertin, H.: "The Status of Md5 After a Recent 1703 Attack," RSA Laboratories' CryptoBytes, Volume 2, Number 1704 2, 1996. 1706 [FH+01] Thomas, M., Froh, M., Hur, M., McGrew, D., Vilhuber, J., 1707 Medvinsky, S.: "Kerberized Internet Negotiation of Keys 1708 (KINK)", , (work in 1709 progress), October, 2001. 1711 [GD+02] Gai, S., Dutt, D., Elfassy, N., Bernet, Y.: "RSVP 1712 Proxy", , (work in 1713 progress), March, 2002. 1715 [HA01] Hornstein, K., Altman, J.: "Distributing Kerberos KDC 1716 and Realm Information with DNS", , (work in progress), August, 1718 2001. 1720 [HH01] Hess, R., Herzog, S.: "RSVP Extensions for Policy 1721 Control", , 1722 (expired), June, 2001. 1724 [Jab96] Jablon, D.: ôStrong password-only authenticated key 1725 exchangeô, Computer Communication Review, 26(5), pp. 5- 1726 26, October, 1996. 1728 [Jas96] Jaspan, B.: ôDual-workfactor Encrypted Key Exchange: 1729 Efficiently Preventing Password Chaining and Dictionary 1730 Attacksö, in ôProceedings of the Sixth Annual USENIX 1731 Security Conferenceö, pp. 43-50, July, 1996. 1733 [MADS01] ôMicrosoft Authorization Data Specification v. 1.0 for 1734 Microsoft Windows 2000 Operating Systemsö, April, 2000, 1736 Tschofenig Informational - Expires August 2002 33 1737 available at: 1738 http://www.microsoft.com/technet/security/kerberos/defau 1739 lt.asp, February, 2001. 1741 [MHHF01] Malpani, A., Hoffman, P., Housley, R., Freeman, T.: 1742 ôSimple Certificate Validation Protocol (SCVP)ö, , (work in progress), July, 2001. 1745 [MS+02] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., 1746 Raatikainen, K.: "Localized RSVP", , (work in progress), May, 2002. 1749 [Pat92] Pato, J., "Using Pre-Authentication to Avoid Password 1750 Guessing Attacks", Open Software Foundation DCE Request 1751 for Comments 26, December, 1992. 1753 [PGP] "Specifications and standard documents", 1754 http://www.pgpi.org/doc/specs/, March, 2002. 1756 [PKTSEC] PacketCable Security Specification, PKT-SP-SEC-I01- 1757 991201, Cable Television Laboratories, Inc., December 1, 1758 1999, http://www.PacketCable.com/. 1760 [Rae01] Raeburn, K.: "Rijndael, Serpent, and Twofish 1761 Cryptosystems for Kerberos 5", , (work in progress), July, 2001. 1764 [RF2367] McDonald, D., Metz, C., Phan, B.: ôPF_KEY Key Management 1765 API, Version 2ö, RFC 2367, July, 1998. 1767 [RFC1321] Rivest, R.: "The MD5 Message-Digest Algorithm", RFC 1768 1321, April, 1992. 1770 [RFC1510] Kohl, J., Neuman, C.: "The Kerberos Network 1771 Authentication Service (V5)", RFC 1510, September 1993. 1773 [RFC2104] Krawczyk, H., Bellare, M., Canetti, R.: ôHMAC: Keyed- 1774 Hashing for Message Authenticationö, RFC 2104, February, 1775 1997. 1777 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, 1778 S.: äResource ReSerVation Protocol (RSVP) û Version 1 1779 Functional Specificationô, RFC 2205, September 1997. 1781 [RFC2207] Berger, L., OÆMalley, T.: äRSVP Extensions for IPSEC 1782 Data Flowsô, RFC 2207, September 1997. 1784 [RFC2315] Kaliski, B.: " PKCS #7: Cryptographic Message Syntax 1785 Version 1.5", RFC 2315, March, 1998. 1787 [RFC2367] McDonald, D., Metz, C., Phan, B.: "PF_KEY Key Management 1788 API, Version 2", RFC 2367, July, 1998. 1790 Tschofenig Informational - Expires August 2002 34 1792 [RFC2401] Kent, S., Atkinson, R.: "Security Architecture for the 1793 Internet Protocol", RFC 2401, November, 1998. 1795 [RFC2402] Kent, S., Atkinson, R.: "IP Authentication Header", RFC 1796 2402, November, 1998. 1798 [RFC2406] Kent, S., Atkinson, R.: "IP Encapsulating Security 1799 Payload (ESP)", RFC 2406, November, 1998. 1801 [RFC2409] Harkins, D., Carrel, D.: ôThe Internet Key Exchange 1802 (IKE)ö, RFC 2409, November, 1998. 1804 [RFC2410] Glenn, R., Kent, S.: "The NULL Encryption Algorithm and 1805 Its Use With IPsec", RFC 2410, November, 1998. 1807 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., Thayer, R.: 1808 "OpenPGP Message Format", RFC 2440, November, 1998. 1810 [RFC2495] Housley, R., Ford, W., Polk, W., Solo, D.: "Internet 1811 X.509 Public Key Infrastructure Certificate and CRL 1812 Profile", RFC 2459, January, 1999. 1814 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, 1815 C.: ôX.509 Internet Public Key Infrastructure Online 1816 Certificate Status Protocol û OCSPö, RFC 2560, June, 1817 1999. 1819 [RFC2630] Housley, R.: ôCryptographic Message Syntaxö, RFC 2630, 1820 June, 1999. 1822 [RFC2747] Baker, F., Lindell, B., Talwar, M.: ôRSVP Cryptographic 1823 Authenticationö, RC 2747, January, 2000. 1825 [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., 1826 Sastry, A.: ôThe COPS(Common Open Policy Service) 1827 Protocolö, RFC 2748, January, 2000. 1829 [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., 1830 Sastry, A.: ôCOPS usage for RSVPö, RFC 2749, January, 1831 2000. 1833 [RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC 1834 2750, January, 2000. 1836 [RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.: 1837 "Remote Authentication Dial In User Service (RADIUS)", 1838 RFC 2865, June, 2000. 1840 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 1841 T., Herzog, S., Hess, R.: ôIdentity Representation for 1842 RSVPö, RFC 3182, October, 2001. 1844 Tschofenig Informational - Expires August 2002 35 1846 [SHA] NIST, FIPS PUB 180-1, "Secure Hash Standard", April, 1847 1995. 1849 [TN+01] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, 1850 S., Wray, J., Trostle, J.: ôPublic Key Cryptography for 1851 Initial Authentication in Kerberosö, < draft-ietf-cat- 1852 kerberos-pk-init-13.txt>, (work in progress), March, 1853 2001. 1855 [Wu98] Wu, T.: ôThe Secure Remote Password Protocolô, in 1856 ôProceedings of the Internet Society Network and 1857 Distributed System Security Symposiumö, pp. 97-111, 1858 March, 1998. 1860 [Wu99] Wu, T.: ôA Real-World Analysis of Kerberos Password 1861 Securityö, in ôProceedings of the 1999 Network and 1862 Distributed System Securityö, February, 1999. 1864 10 Author's Contact Information 1866 Hannes Tschofenig 1867 Siemens AG 1868 Otto-Hahn-Ring 6 1869 81739 Munchen 1870 Germany 1871 Email: Hannes.Tschofenig@mchp.siemens.de 1873 11 Full Copyright Statement 1875 Copyright (C) The Internet Society (2000). All Rights Reserved. 1877 This document and translations of it may be copied and furnished to 1878 others, and derivative works that comment on or otherwise explain it 1879 or assist in its implementation may be prepared, copied, published 1880 and distributed, in whole or in part, without restriction of any 1881 kind, provided that the above copyright notice and this paragraph 1882 are 1883 included on all such copies and derivative works. However, this 1884 document itself may not be modified in any way, such as by removing 1885 the copyright notice or references to the Internet Society or other 1886 Internet organizations, except as needed for the purpose of 1887 developing Internet standards in which case the procedures for 1888 copyrights defined in the Internet Standards process must be 1889 followed, or as required to translate it into languages other than 1890 English. 1892 The limited permissions granted above are perpetual and will not be 1893 revoked by the Internet Society or its successors or assigns. 1895 This document and the information contained herein is provided on an 1896 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1898 Tschofenig Informational - Expires August 2002 36 1899 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1900 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1901 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1902 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1904 Acknowledgement 1906 Funding for the RFC Editor function is currently provided by the 1907 Internet Society. 1909 Tschofenig Informational - Expires August 2002 37