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