idnits 2.17.1 draft-ietf-nsis-rsvp-sec-properties-01.txt: -(350): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(421): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(651): 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 -(729): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1412): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 40) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8 IANA considerations' ) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1968 has weird spacing: '... ticket from ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2747' on line 2164 looks like a reference -- Missing reference section? 'RFC2750' on line 2174 looks like a reference -- Missing reference section? 'HH01' on line 2064 looks like a reference -- Missing reference section? 'RFC2104' on line 2117 looks like a reference -- Missing reference section? 'RFC1321' on line 2111 looks like a reference -- Missing reference section? 'SHA' on line 2185 looks like a reference -- Missing reference section? 'RFC2205' on line 2120 looks like a reference -- Missing reference section? 'RFC2367' on line 2130 looks like a reference -- Missing reference section? 'RFC3182' on line 2181 looks like a reference -- Missing reference section? 'RFC1510' on line 2114 looks like a reference -- Missing reference section? 'RFC2495' on line 2151 looks like a reference -- Missing reference section? 'RFC2440' on line 2148 looks like a reference -- Missing reference section? 'RFC2401' on line 2133 looks like a reference -- Missing reference section? 'RFC2409' on line 2142 looks like a reference -- Missing reference section? 'HA01' on line 2060 looks like a reference -- Missing reference section? 'RFC2402' on line 2136 looks like a reference -- Missing reference section? 'RFC2406' on line 2139 looks like a reference -- Missing reference section? 'DBP96' on line 2036 looks like a reference -- Missing reference section? 'Dob96' on line 2048 looks like a reference -- Missing reference section? 'RFC2865' on line 2177 looks like a reference -- Missing reference section? 'RFC2748' on line 2167 looks like a reference -- Missing reference section? 'RFC2749' on line 2171 looks like a reference -- Missing reference section? 'MADS01' on line 2077 looks like a reference -- Missing reference section? 'PKTSEC' on line 2098 looks like a reference -- Missing reference section? 'RFC2560' on line 2155 looks like a reference -- Missing reference section? 'MHHF01' on line 2082 looks like a reference -- Missing reference section? 'RFC2630' on line 2159 looks like a reference -- Missing reference section? 'RFC2315' on line 2127 looks like a reference -- Missing reference section? 'PGP' on line 2094 looks like a reference -- Missing reference section? 'DG96' on line 2040 looks like a reference -- Missing reference section? 'Rae01' on line 2102 looks like a reference -- Missing reference section? 'RFC2410' on line 2145 looks like a reference -- Missing reference section? 'RFC2746' on line 1675 looks like a reference -- Missing reference section? 'Her95' on line 2206 looks like a reference -- Missing reference section? 'RFC2207' on line 2124 looks like a reference -- Missing reference section? 'Pat92' on line 2090 looks like a reference -- Missing reference section? 'Jas96' on line 2072 looks like a reference -- Missing reference section? 'BM92' on line 2027 looks like a reference -- Missing reference section? 'DH95' on line 2044 looks like a reference -- Missing reference section? 'Wu99' on line 2197 looks like a reference -- Missing reference section? 'Wu98' on line 2193 looks like a reference -- Missing reference section? 'Jab96' on line 2068 looks like a reference -- Missing reference section? 'RF2367' on line 2106 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 45 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hannes Tschofenig 3 Internet Draft Siemens 4 Document: 5 draft-ietf-nsis-rsvp-sec-properties-01.txt 6 Expires: September, 2003 8 March, 2003 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 Abstract 35 As the work of the NSIS working group has begun there are also 36 concerns about security and its implication for the design of a 37 signaling protocol. In order to understand the security properties 38 and available options of RSVP a number of documents have to be read. 39 This document tries to summarize the security properties of RSVP and 40 to view them from a different point of view. This work in NSIS is 41 part of the overall process of analyzing other signaling protocols 42 and to learn from their design considerations. This document should 43 also provide a starting point for security discussions. 45 Table of Contents 47 1 Introduction...................................................3 48 2 Terminology....................................................3 49 3 Overview.......................................................5 50 3.1 The RSVP INTEGRITY Object....................................5 51 3.2 Security Associations........................................6 52 3.3 RSVP Key Management Assumptions..............................7 53 3.4 Identity Representation......................................7 54 3.5 RSVP Integrity Handshake....................................11 55 4 Detailed Security Property Discussion.........................12 56 4.1 Discussed Network Topology..................................12 57 4.2 Host/Router.................................................13 58 4.3 User to PEP/PDP.............................................17 59 4.4 Communication between RSVP aware routers....................25 60 5 Miscellaneous Issues..........................................28 61 5.1 First Hop Issue.............................................28 62 5.2 Next-Hop Problem............................................28 63 5.3 Last-Hop Issue..............................................30 64 5.4 RSVP and IPsec..............................................31 65 5.5 End-to-End Security Issues and RSVP.........................33 66 5.6 IPsec protection of RSVP signaling messages.................33 67 5.7 Accounting/Charging Framework...............................34 68 6 Conclusions...................................................34 69 7 Security Considerations.......................................36 70 8 IANA considerations...........................................36 71 9 Open Issues...................................................36 72 10 Acknowledgments...............................................36 73 Appendix A. Dictionary Attacks and Kerberos......................36 74 Appendix B. Example of User-to-PDP Authentication................38 75 11 References....................................................39 76 12 Author's Contact Information..................................42 77 13 Full Copyright Statement......................................43 79 Tschofenig Informational - Expires September 2003 2 80 1 Introduction 82 As the work of the NSIS working group has begun there are also 83 concerns about security and its implication for the design of a 84 signaling protocol. In order to understand the security properties 85 and available options of RSVP a number of documents have to be read. 86 This document tries to summarize the security properties of RSVP and 87 to view them from a different point of view. This work in NSIS is 88 part of the overall process of analyzing other signaling protocols 89 and to learn from their design considerations. This document should 90 also provide a starting point for further discussions. 92 The content of this document is organized as follows: 94 Section 3 provides an overview of the security mechanisms provided by 95 RSVP including the INTEGRITY object, a description of the identity 96 representation within the POLICY_DATA object (i.e. user 97 authentication) and the RSVP Integrity Handshake mechanism. 99 Section 4 provides a more detailed discussion of the used mechanism 100 and tries to describe the mechanisms provided in detail. 102 Finally a number of miscellaneous issues are described which address 103 first-hop, next-hop and last-hop issues. Furthermore the problem of 104 IPsec security protection of data traffic and RSVP signaling message 105 is discussed. 107 2 Terminology 109 To begin with the description of the security properties of RSVP it 110 is natural to explain some terms used throughout the document. 112 - Chain-of-Trust 114 The security mechanisms supported by RSVP [RFC2747] heavily relies on 115 optional hop-by-hop protection using the built-in INTEGRITY object. 116 Hop-by-hop security with the INTEGRITY object inside the RSVP message 117 thereby refers to the protection between RSVP supporting network 118 elements. Additionally there is the notion of policy aware network 119 elements that additionally understand the POLICY_DATA element within 120 the RSVP message. Since this element also includes an INTEGRITY 121 object there is an additional hop-by-hop security mechanism that 122 provides security between policy aware nodes. Policy ignorant nodes 123 are not affected by the inclusion of this object in the POLICY_DATA 124 element since they do not try to interpret it. 126 To protect signaling messages that are possibly modified by each RSVP 127 router along the path it must be assumed that each incoming request 128 is authenticated, integrity and replay protected. This provides 129 protection against unauthorized nodes injecting bogus messages. 130 Furthermore each RSVP-router is assumed to behave in the expected 132 Tschofenig Informational - Expires September 2003 3 133 manner. Outgoing messages transmitted to the next hop network element 134 experience protection according RSVP security processing. 136 Using the above described mechanisms a chain-of-trust is created 137 whereby a signaling message transmitted by router A via router B and 138 received by router C is supposed to be secure if router A and B and 139 router B and C share a security association and all routers behave 140 expectedly. Hence router C trusts router A although router C does not 141 have a direct security association with router A. We can therefore 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 186 Tschofenig Informational - Expires September 2003 4 187 message as defined in [RFC2747] whereas the latter is included in the 188 POLICY_DATA object and defined in [RFC2750]. In order to 189 differentiate the two objects regarding their scope of protection the 190 two terms RSVP INTEGRITY and POLICY_DATA INTEGRITY object are used. 191 The data structure of the two objects however is the same. 193 - Hop vs. Peer 195 In the past there was considerable discussion about the terminology 196 of a nodes that are addressed by RSVP. In particular two favorites 197 have used: hop and peer. This document uses the term hop which is 198 different to an IP hop. Two neighboring RSVP nodes communicating with 199 each other are not necessarily neighboring IP nodes (i.e. one IP hop 200 away). 202 3 Overview 204 3.1 The RSVP INTEGRITY Object 206 The RSVP INTEGRITY object is the major component of the RSVP security 207 protection. This object is used to provide integrity and replay 208 protect the content of the signaling message between two RSVP 209 participating router. Furthermore the RSVP INTEGRITY object provides 210 data origin authentication. The attributes of the object are briefly 211 described: 213 - Flags field 215 The Handshake Flag is the only defined flag and is used to 216 synchronize sequence numbers if the communication gets out-of-sync 217 (i.e. for a restarting host to recover the most recent sequence 218 number). Setting this flag to one indicates that the sender is 219 willing to respond to an Integrity Challenge message. This flag can 220 therefore be seen as a capability negotiation transmitted within each 221 INTEGRITY object. 223 - Key Identifier 225 The Key Identifier selects the key used for verification of the Keyed 226 Message Digest field and hence must be unique for the sender. Its 227 length is fixed with 48-bit. The generation of this Key Identifier 228 field is mostly a decision of the local host. [RFC2747] describes 229 this field as a combination of an address, the sending interface and 230 a key number. We assume that the Key Identifier is simply a (keyed) 231 hash value computed over a number of fields with the requirement to 232 be unique if more than one security association is used in parallel 233 between two hosts (i.e. as it is the case with security association 234 that have overlapping lifetimes). A receiving system uniquely 235 identifies a security association based on the Key Identifier and the 236 sender's IP address. The sender's IP address may be obtained from the 237 RSVP_HOP object or from the source IP address of the packet if the 238 RSVP_HOP object is not present. The sender uses the outgoing 240 Tschofenig Informational - Expires September 2003 5 241 interface to determine which security association to use. The term 242 outgoing interface might be confusing. The sender selects the 243 security association based on the receiver's IP address (of the next 244 RSVP capable router). To determine which node is the next capable 245 RSVP router is not further specified and is likely to be statically 246 configured. 248 - Sequence Number 250 The sequence number used by the INTEGRITY object is 64-bits in length 251 and the starting value can be selected arbitrarily. The length of the 252 sequence number field was chosen to avoid exhaustion during the 253 lifetime of a security association as stated in Section 3 of 254 [RFC2747]. In order for the receiver to distinguish between a new and 255 a replayed sequence number each value must be monotonically 256 increasing modulo 2^64. We assume that the first sequence number seen 257 (i.e. the starting sequence number) is stored somewhere. The modulo- 258 operation is required because the starting sequence number may be an 259 arbitrary number. The receiver therefore only accepts packets with a 260 sequence number larger (modulo 2^64) than the previous packet. As 261 explained in [RFC2747] this process is started by handshaking and 262 agreeing on an initial sequence number. If no such handshaking is 263 available then the initial sequence number must be part of the 264 establishment of the security association. 266 The generation and storage of sequence numbers is an important step 267 in preventing replay attacks and is largely determined by the 268 capabilities of the system in presence of system crashes, failures 269 and restarts. Section 3 of [RFC2747] explains some of the most 270 important considerations. 272 - Keyed Message Digest 274 The Keyed Message Digest is an RSVP built-in security mechanism used 275 to provide integrity protection of the signaling messages. Prior to 276 computing the value for the Keyed Message Digest field the Keyed 277 Message Digest field itself must be set to zero and a keyed hash 278 computed over the entire RSVP packet. The Keyed Message Digest field 279 is variable in length but must be a multiple of four octets. If HMAC- 280 MD5 is used then the output value is 16 bytes long. The keyed hash 281 function HMAC-MD5 [RFC2104] is required for a RSVP implementation as 282 noted in Section 1 of [RFC2747]. Hash algorithms other than MD5 283 [RFC1321] like SHA [SHA] may also be supported. 285 The key used for computing this Keyed Message Digest may be obtained 286 from the pre-shared secret which is either manually distributed or 287 the result of a key management protocol. No key management protocol, 288 however, is specified to create the desired security associations. 290 3.2 Security Associations 292 Tschofenig Informational - Expires September 2003 6 293 Different attributes are stored for security associations of sending 294 and receiving systems (i.e. unidirectional security associations). 295 The sending system needs to maintain the following attributes in such 296 a security association [RFC2747]: 298 - Authentication algorithm and algorithm mode 299 - Key 300 - Key Lifetime 301 - Sending Interface 302 - Latest sequence number (sent with this key identifier) 304 The receiving system has to store the following fields: 306 - Authentication algorithm and algorithm mode 307 - Key 308 - Key Lifetime 309 - Source address of the sending system 310 - List of last n sequence numbers (received with this key identifier) 312 Note that the security associations need to have additional fields to 313 indicate their state. It is necessary to have an overlapping lifetime 314 of security associations to avoid interrupting an ongoing 315 communication because of expired security associations. During such a 316 period of overlapping lifetime it is necessary to authenticate either 317 one or both active keys. As mentioned in [RFC2747] a sender and a 318 receiver might have multiple active keys simultaneously. 319 If more than one algorithm is supported then the algorithm used must 320 be specified for a security association. 322 3.3 RSVP Key Management Assumptions 324 [RFC2205] assumes that security associations are already available. 325 Manual key distribution must be provided by an implementation as 326 noted in Section 5.2 of [RFC2747]. Manual key distribution however 327 has different requirements to a key storage � a simple plaintext 328 ASCII file may be sufficient in some cases. If multiple security 329 associations with different lifetimes should be supported at the same 330 time then a key engine, for example PF_KEY [RFC2367], would be more 331 appropriate. Further security requirements listed in Section 5.2 of 332 [RFC2747] are the following: 334 - The manual deletion of security associations must be supported. 335 - The key storage should persist a system restart. 336 - Each key must be assigned a specific lifetime and a specific Key 337 Identifier. 339 3.4 Identity Representation 341 In addition to host-based authentication with the INTEGRITY object 342 inside the RSVP message user-based authentication is available as 343 introduced with [RFC2750]. Section 2 of [RFC3182] stated that 344 "Providing policy based admission control mechanism based on user 346 Tschofenig Informational - Expires September 2003 7 347 identities or application is one of the prime requirements." To 348 identify the user or the application, a policy element called 349 AUTH_DATA, which is contained in the POLICY_DATA object, is created 350 by the RSVP daemon at the user�s host and transmitted inside the RSVP 351 message. The structure of the POLICY_DATA element is described in 352 [RFC2750]. Network nodes like the PDP then use the information 353 contained in the AUTH_DATA element to authenticate the user and to 354 allow policy-based admission control to be executed. As mentioned in 355 [RFC3182] the policy element is processed and the policy decision 356 point replaces the old element with a new one for forwarding to the 357 next hop router. 359 A detailed description of the POLICY_DATA element can be found in 360 [RFC2750]. The attributes contained in the authentication data policy 361 element AUTH_DATA, which is defined in [RFC3182], are briefly 362 explained in this Section. Figure 1 shows the abstract structure of 363 the RSVP message with its security relevant objects and the scope of 364 protection. The RSVP INTEGRITY object (outer object) covers the 365 entire RSVP message whereas the POLICY_DATA INTEGRITY object only 366 covers objects within the POLICY_DATA element. 368 +--------------------------------------------------------+ 369 | RSVP Message | 370 +--------------------------------------------------------+ 371 | INTEGRITY +-------------------------------------------+| 372 | Object |POLICY_DATA Object || 373 | +-------------------------------------------+| 374 | | INTEGRITY +------------------------------+|| 375 | | Object | AUTH_DATA Object ||| 376 | | +------------------------------+|| 377 | | | Various Authentication ||| 378 | | | Attributes ||| 379 | | +------------------------------+|| 380 | +-------------------------------------------+| 381 +--------------------------------------------------------+ 382 Figure 1: Security relevant Objects and Elements within the RSVP 383 message 385 The AUTH_DATA object contains information for identifying users and 386 applications together with credentials for those identities. The main 387 purpose of those identities seems to be the usage for policy based 388 admission control and not for authentication and key management. As 389 noted in Section 6.1 of [RFC3182] an RSVP may contain more than one 390 POLICY_DATA object and each of them may contain more than one 391 AUTH_DATA object. As indicated in the Figure above and in [RFC3182] 392 one AUTH_DATA object contains more than one authentication attribute. 393 A typical configuration for a Kerberos-based user authentication 394 includes at least the Policy Locator and an attribute containing the 395 Kerberos session ticket. 397 A successful user authentication is the basis for doing policy-based 398 admission control. Additionally other information such as time-of- 400 Tschofenig Informational - Expires September 2003 8 401 day, application type, location information, group membership etc. 402 may be relevant for a policy. 404 The following attributes are defined for the usage in the AUTH_DATA 405 object: 407 a) Policy Locator 409 The policy locator string that is a X.500 distinguished name (DN) 410 used to locate the user and/or application specific policy 411 information. The following types of X.500 DNs are listed: 413 - ASCII_DN 414 - UNICODE_DN 415 - ASCII_DN_ENCRYPT 416 - UNICODE_DN_ENCRYPT 418 The first two types are the ASCII and the Unicode representation of 419 the user or application DN identity. The two "encrypted" 420 distinguished name types are either encrypted with the Kerberos 421 session key or with the private key of the user�s digital certificate 422 (i.e. digitally signed). The term encrypted together with a digital 423 signature is easy to misconceive. If user identity confidentiality 424 shall be provided then the policy locator has to be encrypted with 425 the public key of the recipient. How to obtain this public key is not 426 described in the document. Such an issue may be specified in a 427 concrete architecture where RSVP is used. 429 b) Credentials 431 Two cryptographic credentials are currently defined for a user: 432 Authentication with Kerberos V5 [RFC1510], and authentication with 433 the help of digital signatures based on X.509 [RFC2495] and PGP 434 [RFC2440]. The following list contains all defined credential types 435 currently available and defined in [RFC3182]: 437 +--------------+--------------------------------+ 438 | Credential | Description | 439 | Type | | 440 +===============================================| 441 | ASCII_ID | User or application identity | 442 | | encoded as an ASCII string | 443 +--------------+--------------------------------+ 444 | UNICODE_ID | User or application identity | 445 | | encoded as an Unicode string | 446 +--------------+--------------------------------+ 447 | KERBEROS_TKT | Kerberos V5 session ticket | 448 +--------------+--------------------------------+ 449 | X509_V3_CERT | X.509 V3 certificate | 450 +--------------+--------------------------------+ 451 | PGP_CERT | PGP certificate | 452 +--------------+--------------------------------+ 454 Tschofenig Informational - Expires September 2003 9 455 Table 1: Credentials Supported in RSVP 457 The first two credentials only contain a plaintext string and 458 therefore they do not provide cryptographic user authentication. 459 These plaintext strings may be used to identify applications, which 460 are included for policy-based admission control. Note that these 461 plain-text identifiers may, however, be protected if either the RSVP 462 INTEGRITY and/or the INTEGRITY object of the POLICY_DATA element is 463 present. Note that the two INTEGRITY objects can terminate at 464 different entities depending on the network structure. The digital 465 signature may also provide protection of application identifiers. A 466 protected application identity (and the entire content of the 467 POLICY_DATA element) cannot be modified as long as no policy ignorant 468 nodes are used in between. 470 A Kerberos session ticket, as previously mentioned, is the ticket of 471 a Kerberos AP_REQ message [RFC1510] without the Authenticator. 472 Normally, the AP_REQ message is used by a client to authenticate to a 473 server. The INTEGRITY object (e.g. of the POLICY_DATA element) 474 provides the functionality of the Kerberos Authenticator, namely 475 replay protection and shows that the user was able to retrieve the 476 session key following the Kerberos protocol. This is, however, only 477 the case if the Kerberos session was used for the keyed message 478 digest field of the INTEGRITY object. Section 7 of [RFC2747] 479 discusses some issues for establishment of keys for the INTEGRITY 480 object. The establishment of the security association for the RSVP 481 INTEGRITY object with the inclusion of the Kerberos Ticket within the 482 AUTH_DATA element may be complicated by the fact that the ticket can 483 be decrypted by node B whereas the RSVP INTEGRITY object terminates 484 at a different host C. The Kerberos session ticket contains, among 485 many other fields, the session key. The Policy Locator may also be 486 encrypted with the same session key. The protocol steps that need to 487 be executed to obtain such a Kerberos service ticket are not 488 described in [RFC3182] and may involve several roundtrips depending 489 on many Kerberos related factors. The Kerberos ticket does not need 490 to be included in every RSVP message as an optimisation as described 491 in Section 7.1 of [RFC2747]. Thus the receiver must store the 492 received service ticket. If the lifetime of the ticket is expired 493 then a new service ticket must be sent. If the receiver lost his 494 state information (because of a crash or restart) then he may 495 transmit an Integrity Challenge message to force the sender to re- 496 transmit a new service ticket. 498 If either the X.509 V3 or the PGP certificate is included in the 499 policy element then a digital signature must be added. The digital 500 signature computed over the entire AUTH_DATA object provides 501 authentication and integrity protection. The SubType of the digital 502 signature authentication attribute is set to zero before computing 503 the digital signature. Whether or not a guarantee of freshness with 504 the replay protection (either timestamps or sequence numbers) is 506 Tschofenig Informational - Expires September 2003 10 507 provided by the digital signature is an open issue as discussed in 508 Section 4.3. 510 c) Digital Signature 512 The digital signature computed over the data of the AUTH_DATA object 513 must be the last attribute. The algorithm used to compute the digital 514 signature depends on the authentication mode listed in the 515 credential. This is only partially true since for example PGP again 516 allows different algorithms to be used for computing a digital 517 signature. The algorithm used for computing the digital signature is 518 not included in the certificate itself. The algorithm identifier 519 included in the certificate only serves the purpose to allow the 520 verification of the signature computed by the certificate authority 521 (except for the case of self-signed certificates). 523 d) Policy Error Object 525 The Policy Error Object is used in the case of a failure of the 526 policy based admission control or other credential verification. 527 Currently available error messages allow to notify if the credentials 528 are expired (EXPIRED_CREDENTIALS), if the authorization process 529 disallowed the resource request (INSUFFICIENT_PRIVILEGES) and if the 530 given set of credentials is not supported 531 (UNSUPPORTED_CREDENTIAL_TYPE). The last error message allows the 532 user's host to discover the type of credentials supported although by 533 very inefficient means. Furthermore it is unlikely that a user 534 supports different types of credentials. The purpose of the error 535 message IDENTITY_CHANGED is unclear. The protection of the error 536 message is not discussed in [RFC3182]. 538 3.5 RSVP Integrity Handshake 540 The Integrity Handshake is a protocol that was designed to allow a 541 crashed or restarted host to obtain the latest valid challenge value 542 stored at the receiving host. A host stores the latest sequence 543 number of a fresh and correctly authenticated packet. An adversary 544 can replay eavesdropped packets if the crashed host has lost its 545 sequence numbers. A signaling message from the real sender with a new 546 sequence number would therefore allow the crashed host to update the 547 sequence number field and prevent further replays. Hence if there is 548 a steady flow of RSVP protected messages between the two hosts an 549 attacker may find it difficult to inject old messages since new 550 authenticated packets with high sequence numbers arrive and get 551 stored immediately. 553 The following description explains the details of the RSVP Integrity 554 Handshake that is started by Node A after recovering from a 555 synchronization failure: 557 Integrity Challenge 558 (1) Message (including 560 Tschofenig Informational - Expires September 2003 11 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 The "Challenge Cookie" is suggested to be a MD5 hash of a local 579 secret and a timestamp [RFC2747]. 581 The Integrity Challenge message is not protected with an INTEGRITY 582 object as show in the protocol flow above. As explained in Section 10 583 of [RFC2747] this was done to avoid problems in situations where both 584 communication parties do not have a valid starting sequence number. 586 Whether or not to use the RSVP Integrity Challenge/Response mechanism 587 is a site-local decision since it may not be needed in all network 588 environments. It is however recommended to use the RSVP Integrity 589 Handshake protocol. 591 4 Detailed Security Property Discussion 593 The purpose of this section is to describe the security protection of 594 the RSVP provided mechanisms individually for authentication, 595 authorization, integrity and replay protection, user identity 596 confidentiality, confidentiality of the signaling messages. 598 4.1 Discussed Network Topology 600 The main purpose of this paragraph is to show the basic interface of 601 a simple RSVP network architecture. The architecture below assumes 602 that there is only a very single domain and that two routers are RSVP 603 and policy aware. These assumptions are relaxed in the individual 604 paragraphs as necessary. Layer 2 devices between the clients and 605 their corresponding first hop routers are not shown. Other network 606 elements like a Kerberos Key Distribution Center and for example an 607 LDAP server where the PDP retrieves his policies are also omitted. 608 The security of various interfaces to the individual servers (KDC, 609 PDP, etc.) depends very much on the security policy of a specific 610 network service provider. 612 Tschofenig Informational - Expires September 2003 12 613 +--------+ 614 |Policy | 615 |Decision| 616 +----+Point +---+ 617 | +--------+ | 618 | | 619 | | 620 | | 621 +------+ +-+----+ +---+--+ +------+ 622 |Client| |Router| |Router| |Client| 623 | A +-------+ 1 +--------+ 2 +----------+ B | 624 +------+ +------+ +------+ +------+ 625 Figure 3: Simple RSVP Architecture 627 4.2 Host/Router 629 When talking about authentication in RSVP it is very important to 630 make a distinction between user and host authentication of the 631 signaling messages. By using the RSVP INTEGRITY object the host is 632 authenticated while credentials inside the AUTH_DATA object can be 633 used to authenticate the user. In this Section the focus is on host 634 authentication whereas the next Section covers user authentication. 636 a) Authentication 638 We use the term host authentication above since the selection of the 639 security association is bound to the host�s IP address as mentioned 640 in Section 3.1 and 3.2. Depending on the key management protocol used 641 to create this security association and the identity used it is also 642 possible to bind a user identity to this security association. Since 643 the key management protocol is not specified it is difficult to 644 evaluate this part and hence we speak about data origin 645 authentication based on the host�s identity for RSVP INTEGRITY 646 objects. The fact that the host identity is used for selecting the 647 security association has already been described in Section 3.1. 649 Data origin authentication is provided with the keyed hash value 650 computed over the entire RSVP message excluding the keyed message 651 digest field itself. The security association used between the user�s 652 host and the first-hop router is, as previously mentioned, not 653 established by RSVP and must therefore be available before the 654 signaling is started. 656 Although not mentioned in [RFC2747] it is also possible to use IPsec 657 [RFC2401] to protect the RSVP signaling traffic from the client to 658 the first-hop router. Note that IPsec usage for RSVP signaling 659 protocol requires preconditions which are described in Section 5.6. 660 If we use IPsec to protect the interface between the user�s host and 661 the first hop router then the optional RSVP INTEGRITY object may not 662 be required. It may also be possible (which requires a further 663 investigation) whether an existing IPsec security association may 664 also be (re-)used for RSVP. IPsec allows the key exchange protocol 666 Tschofenig Informational - Expires September 2003 13 667 IKE [RFC2409] to be used to dynamically negotiate IPsec security 668 associations. Note that KINK [FH+01] and other protocols are 669 available that are also able to establish an IPsec security 670 association. This text mainly refers to IKE since it is the most 671 frequently used protocol for this purpose. A detailed description of 672 IPsec and IKE is outside the scope of this document. Since IKE is 673 computationally expensive it might create a computational burden to 674 re-establish a new IPsec SA based of the movement of a mobile user 675 host. Work at the SEAMOBY group tries to tackle this problem by using 676 IPsec Context Transfer protocols. Hence in this case we would avoid 677 triggering a separate key exchange protocol run for RSVP to protect 678 messages at each layer if they 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 As described in Section 7 of [RFC2747] Kerberos may be used to create 688 the key for the RSVP INTEGRITY object. How to learn the principal 689 name (and realm information) of the other node is outside the scope 690 of [RFC2747]. Section 4.2.1 of [RFC2747] states that the required 691 identities can be obtained statically or dynamically via a directory 692 service or DHCP. [HA01] describes a way to distribute principal and 693 realm information via DNS which can be used for this purpose 694 (assuming that the FQDN or the IP address of the other node is known 695 for which this information is desired). It is only required to 696 encapsulate the Kerberos ticket inside the policy element. It is 697 furthermore mentioned that Kerberos tickets with expired lifetime 698 must not be used and the initiator is responsible for requesting and 699 exchanging a new service ticket before expiration. 701 RSVP multicast processing in combination with Kerberos requires 702 additional thoughts: 704 Section 7 of [RFC2747] states that in the multicast case all 705 receivers must share a single key with the Kerberos Authentication 706 Server i.e. a single principal used for all receivers). From a 707 personal discussion with Rodney Hess it seems that there is currently 708 no other solution available in the context of Kerberos. 710 An additional protocol needs to be executed after each user is 711 authenticated via Kerberos to establish a session key and to allow 712 multicast specific functionality like entering a group, leaving a 713 group to be executed securely. This would additionally allow 714 accounting and billing to be used efficiently and on a per-user 715 basis. This session key is then used to protect RSVP signaling 716 messages. These issues definitely need further investigation and are 717 not fully described in this version of the document. 719 Tschofenig Informational - Expires September 2003 14 720 In case that one entity crashed the established security association 721 is lost and therefore the other node must retransmit the service 722 ticket. The crashed entity can use an Integrity Challenge message to 723 request a new Kerberos ticket to be retransmitted by the other node. 724 If a node receives such a request then a reply message must be 725 returned. 727 b) Integrity Protection 729 Integrity protection between the user�s host and the first hop router 730 is based on the RSVP INTEGRITY object. Since the RSVP Integrity 731 object is an optional element of the RSVP message IPsec protection of 732 the signaling message to the router may also provide integrity 733 protection either with IPsec AH [RFC2402] or IPsec ESP [RFC2406] as 734 mentioned already in the previous paragraph. 736 Furthermore it is stated that other keyed hash functions apart from 737 HMAC-MD5 may be used within the RSVP INTEGRITY object and it is 738 obvious that both communicating entities must have security 739 associations indicating the algorithm used. This may be however 740 difficult since there is no negotiation protocol defined to agree on 741 a specific algorithm. Hence it is very likely that HMAC-MD5 is the 742 only usable algorithm for the RSVP INTEGRITY object if RSVP is used 743 in a mobile environment and only in local environments it may be 744 useful to switch to a different keyed hash algorithm. The other 745 possible alternative is that every implementation must support the 746 most important keyed hash algorithms for example MD5, SHA-1, RIPEMD- 747 160 etc. HMAC-MD5 was mainly chosen because of the performance 748 characteristics. The weaknesses of MD5 [DBP96] are known and 749 described in [Dob96]. Other algorithms like SHA-1 [SHA] and RIPEMD- 750 160 [DBP96] instead are known to provide better security properties. 752 c) Replay Protection 754 The main mechanism used for replay protection in RSVP are sequence 755 numbers whereby the sequence number is included in the RSVP INTEGRITY 756 object. The properties of this sequence number mechanisms are 757 described in Section 3.1. The fact that the receiver stores a list of 758 sequence numbers is an indicator for a window mechanism. This somehow 759 conflicts with the requirement that the receiver only has to store 760 the highest number given in Section 3 of [RFC2747]. We assume that 761 this is a typo. Section 4.1 of [RFC2747] gives a few comments about 762 the out-of-order delivery and the ability of an implementation to 763 specify the replay window. 765 If IPsec is used to protect RSVP messages then the optional IPsec 766 replay protection mechanism may be used which is also based on 767 sequence numbers with a window mechanism. This window mechanism may 768 (theoretically) also cause problems whereby an adversary reorders 769 messages. This is however very difficult to exploit since the 770 signaling messages are exchanged at a relatively low rate compared to 771 regular data traffic that may also be protected with IPsec. 773 Tschofenig Informational - Expires September 2003 15 774 - Integrity Handshake 776 The mechanism of the Integrity Handshake is explained in Section 3.5. 777 The Cookie value is suggested to be hash of a local secret and a 778 timestamp. The Cookie value is not verified by the receiver. The 779 mechanism used by the Integrity Handshake is a simple 780 Challenge/Response message which assumes that the key shared between 781 the two hosts survives the crash. If the security association is 782 however dynamically created then this assumption may not be true. 784 In Section 10 of [RFC2747] the authors note that an adversary can 785 create faked Integrity Handshake message including challenge cookies. 786 Subsequently he would store the received response. Later he tries to 787 replay these responses while a responder recovers from a crash or 788 restart. If this replayed Integrity Response value is valid and has a 789 lower sequence number than actually used then this value is stored at 790 the recovering host. In order for this attack to be successful the 791 adversary must either have collected a large number of 792 challenge/response value pairs or the adversary "discovered" the 793 cookie generation mechanism (for example by knowing the local 794 secret). The collection of Challenge/Response pairs is even more 795 difficult since they depend on the Cookie value, on sequence number 796 included in the response message and on the shared key which is used 797 by the INTEGRITY object. 799 d) Confidentiality 801 Confidentiality is not considered to be a security requirement for 802 RSVP. Hence it is not directly supported by RSVP. However, IPsec can 803 provide confidentiality by encrypting the transmitted signaling 804 traffic with IPsec ESP. 806 e) Authorization 808 The task of authorization consists of two subcategories: Network 809 access authorization and RSVP request authorization. Access 810 authorization is provided when a node is authenticated to the network 811 e.g. via AAA protocols (for example using RADIUS [RFC2865] or 812 DIAMETER [CA+02]) and authorization information is downloaded to one 813 or more network elements for example to the access router/first hop 814 router to modify filter rules to enable the IP traffic forwarding. 815 The access router is therefore acting as a firewall with dynamically 816 created filter rules based on a successful host or user 817 authentication. Issues related to network access authorization are 818 outside the scope of RSVP. 820 The second authorization refers to RSVP itself. Depending on the 821 network configuration 822 - the router either forwards the received RSVP request to the policy 823 decision point e.g. by using COPS (see [RFC2748] and [RFC2749]) and 824 to request admission control procedure to be executed or 826 Tschofenig Informational - Expires September 2003 16 827 - the router supports the functionality of a PDP and therefore there 828 is no need to forward the request or 829 - the router may already be configured with the appropriate policy 830 information to decide locally whether to grant this request or not. 832 Based on the result of the admission control the request may be 833 granted or rejected. Without a policy element being embedded inside 834 the RSVP message no policy-based admission control can be done. 836 The interaction between the two access authorization procedures (and 837 the filter-installation at the various network devices) will likely 838 be investigated in more detail in the MIDCOM working group. 840 f) Performance 842 The computation of the keyed message digest for a RSVP INTEGRITY 843 object does not represent a performance problem. The same is true for 844 IPsec AH (or IPsec ESP). The protection of signaling messages is 845 usually not a problem since these messages are transmitted at a low 846 rate. Even a high number of messages does not cause performance 847 problems for a RSVP routers because of the efficiency of the keyed 848 message digest routine. 850 The key management which is computationally more demanding is more 851 important for scalability. Since RSVP does not specify a particular 852 key exchange protocol to be used it is difficult to estimate the 853 effort to create the required security associations. Furthermore the 854 number of key exchanges to be triggered depends on security policy 855 issues like lifetime of a security association, required security 856 properties of the key exchange protocol, authentication mode used by 857 the key exchange protocol etc. In a stationary environment with a 858 single administrative domain the manual security association 859 distribution may be acceptable and provides the best performance 860 characteristics. In a mobile environment asymmetric authentication 861 methods are likely to be used with a key exchange protocol and some 862 sort of certificate verification needs to be supported. 864 4.3 User to PEP/PDP 866 As noted in the previous section both user and host based 867 authentication is supported by RSVP. Using RSVP, a user may 868 authenticate to the first hop router or to the PDP as specified in 869 [RFC2747] depending on the infrastructure provided by the network 870 domain or on the architecture used (e.g. the integration of RSVP and 871 Kerberos V5 into the Windows 2000 Operating System [MADS01]). Another 872 architecture where RSVP is tightly integrated is the one specified by 873 the PacketCable organization. The interested reader is referred to 874 [PKTSEC] for a discussion of the security architecture. 876 a) Authentication 878 Tschofenig Informational - Expires September 2003 17 879 When a user sends a RSVP PATH or RESV message then this message may 880 include some information to authenticate the user. [RFC3182] 881 describes how user and application information is embedded into the 882 RSVP message (AUTH_DATA object) and how to protect it. A router 883 receiving such a message can use this information to authenticate the 884 client and forward the user/application information to the policy 885 decision point (PDP). Optionally the PDP itself can authenticate the 886 user, which is described in the next section. In order to be able to 887 authenticate the user, to verify the integrity and to check for 888 replays the entire POLICY_DATA element has to be forwarded from the 889 router to the PDP e.g. by including the element into a COPS message. 890 It is assumed that the INTEGRITY object within the POLICY_DATA 891 element is sent to the PDP along with all other attributes although 892 not clearly specified in [RFC3182]. 894 Certificate Verification 896 Using the policy element as described in [RFC3182] it is not possible 897 to provide a certificate revocation list or other information to 898 proof the validity of the certificate inside the policy element. A 899 specific mechanism for certificate verification is not discussed in 900 [RFC3182] and hence a number of them can be used for this purpose. 901 For certificate verification the network element (a router or the 902 policy decision point), which has to authenticate the user, could 903 frequently download certificate revocation lists or should use a 904 protocol like the Online Certificate Status Protocol (OCSP) [RFC2560] 905 and the Simple Certificate Validation Protocol (SCVP) [MHHF01] to 906 determine the current status of a digital certificate. 908 User Authentication to the PDP 910 This alternative authentication procedure uses the PDP to 911 authenticate the user instead of the first hop router. In Section 912 4.2.1 in [RFC3182] the choice is given for the user to either obtain 913 a session ticket for the next hop router or for the PDP. As noted in 914 the same Section the identity of the PDP or the next hop router is 915 statically configured or dynamically retrieved. Subsequently user 916 authentication to the PDP is considered. 918 Kerberos-based Authentication to the PDP 920 If Kerberos is used to authenticate the user then first a session 921 ticket for the PDP needs to be requested. If the user roams between 922 different routers in the same administrative domain then he does not 923 need to request a new service ticket since the PDP is likely to be 924 used by most or all first-hop routers within the same administrative 925 domain. This is different if a session ticket for a router has to be 926 obtained and authentication to a router is required. The router 927 therefore plays a passive role of forwarding the request only to the 928 PDP and executing the policy decision returned by the PDP. 930 Appendix B describes one example of user-to-PDP authentication. 932 Tschofenig Informational - Expires September 2003 18 933 User authentication with the policy element only provides unilateral 934 authentication where the client authenticates to the router or to the 935 PDP. If a RSVP message is sent to the user�s host and public keyed 936 based authentication is used then the message does not contain a 937 certificate and digital signature. Hence no mutual authentication can 938 be assumed. In case of Kerberos mutual authentication may be 939 accomplished if the PDP or the router transmits a policy element with 940 an INTEGRITY object computed with the session key retrieved from the 941 Kerberos ticket or if the Kerberos ticket included in the policy 942 element is also used for the RSVP INTEGRITY object as described in 943 Section 4.2. This procedure only works if a previous message was 944 transmitted from the end host to the network and such key is already 945 established. [RFC3182] does not discuss this issue and therefore 946 there is no particular requirement dealing with transmitting network 947 specific credentials back to the end-user's host. 949 b) Integrity Protection 951 The integrity protection of the RSVP message and the POLICY_DATA 952 element are protected separately as shown in Figure 1. In case of a 953 policy ignorant node along the path the RSVP INTEGRITY object and the 954 INTEGRITY object inside the policy element terminate at different 955 nodes. Basically the same is true for the credentials of the user if 956 they are verified at the policy decision point instead of the first 957 hop router. 959 - Kerberos 961 If Kerberos is used to authenticate the user to the first hop router 962 then the session key included in the Kerberos ticket may be used to 963 compute the INTEGRITY object of the policy element. It is the keyed 964 message digest that provides the authentication. The existence of the 965 Kerberos service ticket inside the AUTH_DATA object does not provide 966 authentication and a guarantee of freshness for the receiving host. 967 Authentication and guarantee of freshness is provided by the keyed 968 hash value of the INTEGRITY object inside the POLICY_DATA element. 969 The user thereby shows that he actively participated in the Kerberos 970 protocol and that he was able to obtain the session key to compute 971 the keyed message digest. The Authenticator used in the Kerberos V5 972 protocol provides similar functionality but replay protection is 973 based on timestamps (or based on sequence number if the optional seq- 974 number field inside the Authenticator is used for KRB_PRIV/KRB_SAFE 975 messages as described in Section 5.3.2 of [RFC1510]). 977 - Digital Signature 979 If public key based authentication is provided then user 980 authentication is accomplished with the digital signature. As 981 explained in Section 3.3.3 of [RFC3182] the DIGITAL_SIGNATURE 982 attribute must be the last attribute in the AUTH_DATA object and the 983 digital signature covers the entire AUTH_DATA object. Which hash 985 Tschofenig Informational - Expires September 2003 19 986 algorithm and public key algorithm is used for the digital signature 987 computation is described in [RFC2440] in case that PGP is used. In 988 case of X.509 credentials the situation is more complex since 989 different mechanisms like CMS [RFC2630] or PKCS#7 [RFC2315] may be 990 used for the digitally signing the message element. X.509 only 991 provides the standard for the certificate layout which seems to 992 provide insufficient information for this purpose. Therefore X.509 993 certificates are supported for example by CMS and PKCS#7. [RFC3182], 994 however, does not make any statements about the usage of CMS and 995 PKCS#7. Currently there is no support for CMS or PKCS#7 described in 996 [RFC3182], which provides more than only public key based 997 authentication (e.g. CRL distribution, key transport, key agreement, 998 etc.). Furthermore the usage of PGP in RSVP is vague since there are 999 different versions of PGP (including a OpenPGP [RFC2440]) and there 1000 has been no indication which version should be used. When thinking 1001 about CMS support for RSVP the main question that has to be answered 1002 is whether a public key based authentication (and key agreement 1003 mechanism) should be supported for a QoS signaling protocol. 1004 Especially the risks of denial of service attacks, large processing, 1005 memory and bandwidth utilization should be considered. 1007 If the INTEGRITY object is not included in the POLICY_DATA element or 1008 not sent to the PDP then we have to make the following observation: 1010 a) For the digital signature case only the replay protection provided 1011 by the digital signature algorithm can be used. It is however not 1012 clear whether this usage was anticipated or not. Hence we might 1013 assume that the replay protection is based on the availability of 1014 RSVP INTEGRITY object used with a security association that is 1015 established by other means. 1017 b) If a Kerberos session ticket is included but without using the 1018 Kerberos session key then the analogon of the Kerberos Authenticator 1019 is missing. Obviously there is no guarantee that the user actually 1020 followed the Kerberos protocol and was able to decrypt the received 1021 TGS_REP (or in rare cases the AS_REP if a session ticket is requested 1022 with the initial AS_REQ). 1024 c) Replay Protection 1026 Figure 4 below shows the interfaces relevant for replay protection of 1027 signaling messages in a more complicated architecture. The client 1028 therefore uses the policy data element with PEP2 since PEP1 is not 1029 policy aware. The interfaces between the client and the PEP1 and 1030 between the PEP1 and PEP2 are protected with the RSVP INTEGRITY 1031 object. The link between the PEP2 and the PDP is protected for 1032 example by using the COPS built-in INTEGRITY object. The dotted line 1033 between the Client and the PDP indicates the protection provided by 1034 the AUTH_DATA element which has no RSVP INTEGRITY object included. 1036 AUTH_DATA +----+ 1037 +- - - - - - - - - - - - - - - - - - - - - - - - - -+PDP +-+ 1039 Tschofenig Informational - Expires September 2003 20 1040 +----+ | 1041 | | 1042 | 1043 | COPS | 1044 INTEGRITY| 1045 | | 1046 | 1047 | | 1048 +--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ | 1049 |Client+-------------------+PEP1+----------------------+PEP2+-+ 1050 +--+---+ +----+ +-+--+ 1051 | | 1052 +-----------------------------------------------------+ 1053 POLICY_DATA INTEGRITY 1055 Figure 4: Replay Protection 1057 Host authentication with the RSVP INTEGRITY object and user 1058 authentication with the INTEGRITY object inside the POLICY_DATA 1059 element both use the same replay mechanism. The length of the 1060 Sequence Number field, sequence number rollover and the Integrity 1061 Handshake is already explained in Section 3.1. 1063 Section 9 in [RFC3182] states "RSVP INTEGRITY object is used to 1064 protect the policy object containing user identity information from 1065 security (replay) attacks.". Hence the public key based 1066 authentication does not support the RSVP based replay protection 1067 since the digital signature does not cover the POLICY_DATA INTEGRITY 1068 object with its Sequence Number field. The digital signature covers 1069 the entire AUTH_DATA object. 1071 The use of public key systems within the AUTH_DATA object complicates 1072 replay protection. Digital signature computation with PGP is 1073 described in [PGP] and in [RFC2440]. The data structure preceding the 1074 signed message digest includes information about the message digest 1075 algorithm used and a 32-bit timestamp when the signature was created 1076 ("Signature creation time"). The timestamp is included in the 1077 computation of the message digest. The IETF standardized OpenPGP 1078 version [RFC2440] contains more information and describes the 1079 different hash algorithms (MD2, MD5, SHA-1, RIPEMD-160) provided. 1080 [RFC3182] does not make any statements whether the "Signature 1081 creation time" field is used for replay protection. Using timestamps 1082 for replay protection requires different synchronization mechanisms 1083 in case of clock-screws. Traditionally "loosely" synchronized clocks 1084 are assumed in those cases but also requires specifying a replay- 1085 window. 1087 If the "Signature creation time" is not used for replay protection 1088 then a malicious policy ignorant node can use this weakness to 1089 replace the user's credentials without destroying the digital 1090 signature. Additionally the RSVP initiating host, where multiple 1091 users may have access, must be trustworthy even if a smartcard is 1093 Tschofenig Informational - Expires September 2003 21 1094 used since otherwise, replay attacks with a recorded AUTH_DATA object 1095 are possible. Note that this however violates the hop-by-hop security 1096 assumption. It is therefore assumed that replay protection of the 1097 user credentials is not considered as an important security 1098 requirement since the hop-by-hop processing of the RSVP message 1099 protects the message against modification by an adversary between two 1100 communicating nodes. 1102 There are two additional issues related to a Kerberos based user 1103 authentication in the context of replay protection. The lifetime of 1104 the Kerberos ticket is based on the fields starttime and endtime of 1105 the EncTicketPart structure of the ticket as described in Section 1106 5.3.1 of [RFC1510]. Since the ticket is created by the KDC located at 1107 the network of the verifying entity it is not difficult to have the 1108 clocks roughly synchronized for the purpose of lifetime verification. 1109 Additional information about clock-synchronization and Kerberos can 1110 be found at [DG96]. 1112 If we assume that the Kerberos session key is used for RSVP then 1113 there may be a need for rekeying. If we assume that a policy at the 1114 user's host indicates when to rekey then the next RSVP message 1115 includes a new Kerberos session ticket that is then used by the 1116 verifying entity. If the lifetime of the Kerberos ticket or other 1117 policies do not affect rekeying then an RSVP security association may 1118 never require rekeying at all because of the large sequence number 1119 space. 1121 d) (User Identity) Confidentiality 1123 This Section discusses the privacy protection of the identity 1124 information transmitted inside the policy element. Especially the 1125 user identity confidentiality is of interest because there is no 1126 built-in RSVP mechanism for encryption of the POLICY_DATA or the 1127 AUTH_DATA elements. The encryption of one of the attributes inside 1128 the AUTH_DATA element - of the POLICY_LOCATOR attribute is discussed 1129 in the next section. 1131 There has often been the discussion whether the effort for protecting 1132 user identity is worth the additional complexity. With the increasing 1133 privacy awareness there must be at least a discussion on the 1134 mechanisms provided by the given protocol. The main question in this 1135 context is about the threat model i.e. against which entity the user 1136 identity should be protected. Since RSVP does not make any 1137 assumptions about the underlying key management protocol for most 1138 parts it is difficult to make a judgment. However for the identity 1139 representation part of the protocol it is possible to make some 1140 observations. We assume that the most important threat for a user is 1141 to reveal his identity to an adversary located between the user�s 1142 host and the first-hop router. Identities should furthermore not be 1143 transmitted outside the domain of the visited network provider i.e. 1144 the user identity information inside the policy data element should 1145 be removed or modified by the PDP to prevent revealing information to 1147 Tschofenig Informational - Expires September 2003 22 1148 other (non-authorized) entities along the signaling path. We cannot 1149 however provide user identity confidentiality against the network 1150 provider to which the user is attached. Different mechanisms must be 1151 deployed to disallow the network provider to create a profile of the 1152 user. These mechanisms are outside the scope of this document since 1153 there is a strong involvement with the initial authentication and key 1154 agreement protocol executed between the user and the visited network. 1156 If the link between the user�s host and the first hop router is 1157 protected with IPsec ESP then confidentiality of the entire signaling 1158 messages is provided. Note however that the IPsec protection may 1159 terminate at the different node than the RSVP policy aware signaling 1160 does. The focus of this Section is, however, the functionality 1161 provided by RSVP. 1163 The ASCII or Unicode distinguished name of user or application inside 1164 the POLICY_LOCATOR attribute of the AUTH_DATA element may be 1165 encrypted as specified in Section 3.3.1 of [RFC3182]. The user (or 1166 application) identity is then encrypted with either the Kerberos 1167 session key or with the private key in case of public key based 1168 authentication. Since the private key is used we usually speak of a 1169 digital signature which can be verified by everyone possessing the 1170 public key. Since the certificate with the public key is included in 1171 the message itself this is no obstacle. Furthermore the included 1172 certificate provides enough identity information for an eavesdropper 1173 together with the additional (unencrypted) information provided in 1174 the RSVP message. Hence the possibility of encrypting the policy 1175 locator in case of public key based authentication is less obvious. 1176 To encrypt the identities using asymmetric cryptography the user�s 1177 host must be able to somehow retrieve the public key of the entity 1178 verifying the policy element (i.e. the first policy aware router or 1179 the PDP). Currently no such mechanism is defined in [RFC3182]. 1181 There is no option to encrypt the user or application identity 1182 without Kerberos or public key mechanisms are used since the 1183 selection of an appropriate security association is not possible. 1185 The algorithm used to encrypt the POLICY_LOCATOR with the Kerberos 1186 session key is assumed to be the same as the one used for encrypting 1187 the service ticket. The information about the used algorithm is 1188 available in the etype field of the EncryptedData ASN.1 encoded 1189 message part. Section 6.3 of [RFC1510] lists the supported 1190 algorithms. [Rae01] defines new encryption algorithms (Rijndael, 1191 Serpent, and Twofish) that were published in the context of the AES 1192 competition. 1194 The task of evaluating the confidentiality provided for the user 1195 requires to look at protocols executed outside of RSVP (for example 1196 to look at the Kerberos protocol). The ticket included in the 1197 CREDENTIAL attribute may provide user identity protection by not 1198 including the optional cname attribute inside the unencrypted part of 1199 the Ticket. Since the Authenticator is not transmitted with the RSVP 1201 Tschofenig Informational - Expires September 2003 23 1202 message the cname and the crealm of the unencrypted part of the 1203 Authenticator are not revealed. In order for the user to request the 1204 Kerberos session ticket, for inclusion in the CREDENTIAL attribute, 1205 the Kerberos protocol exchange must be executed. Then the 1206 Authenticator sent with the TGS_REQ reveals the identity of the user. 1207 The AS_REQ must also include the user identity to allow the Kerberos 1208 Authentication Server to respond with an AS_REP message that is 1209 encrypted with the user's secret key. Using Kerberos, it is therefore 1210 only possible not to reveal content of the encrypted policy locator, 1211 which is only useful if this value differs from the user identity 1212 used with Kerberos. Hence using Kerberos it is not "entirely" 1213 possible to provide user identity confidentiality. 1215 It is important to note that information stored in the policy element 1216 may be changed by a policy aware router or by the policy decision 1217 point. Which parts are changed depends upon whether multicast or 1218 unicast is used, how the policy server reacts, where the user is 1219 authenticated and whether he needs to be re-authenticated in other 1220 network nodes etc. Hence user and application specific information 1221 can leak after the messages leave the first hop within the network 1222 where the user's host is attached. As mentioned at the beginning of 1223 this Section this information leakage is assumed to be intentional. 1225 e) Authorization 1227 Additional to the description of the authorization steps of the 1228 Host/Router interface, user based authorization is added with the 1229 policy element providing user credentials. The inclusion of user and 1230 application specific information enables policy-based admission 1231 control with special user policies that are likely to be stored at a 1232 dedicated server. Hence a Policy Decision Point can query for example 1233 a LDAP server for a service level agreement stating the amount of 1234 resources a certain user is allowed to request. Additional to the 1235 user identity information group membership and other non-security 1236 related information may contribute to the evaluation of the final 1237 policy decision. If the user is not registered to the currently 1238 attached domain then there is the question of how much information 1239 the home domain of the user is willing to exchange. This also impacts 1240 the users privacy policy. In general the user may not want to 1241 distribute much of his policy information. Furthermore the missing 1242 standardized authorization data format may create interoperability 1243 problems when exchanging policy information. Hence we can assume that 1244 the policy decision point may use information from an initial 1245 authentication and key agreement protocol which may already required 1246 cross-realm communication with the user's home domain to only assume 1247 that the home domain knows the user and that the user is entitled to 1248 roam and to be able to forward accounting messages to this domain. 1249 This represents the traditional subscriber based accounting scenario. 1250 Non-traditional or alternative means of accounting might be deployed 1251 in the near future that do not require the any type of inter-domain 1252 communication. Obviously there is a strong interrelationship between 1253 the authorization and the process of accounting. Note that the term 1255 Tschofenig Informational - Expires September 2003 24 1256 accounting in this context is not only related to process of 1257 metering. Metering is only the process of measuring and collecting 1258 resource usage information. Instead the term unites metering, 1259 pricing, charging and billing. 1261 f) Performance 1263 If Kerberos is used for user authentication then a Kerberos ticket 1264 must be included in the CREDENTIAL Section of the AUTH_DATA element. 1265 The Kerberos ticket has a size larger than 500 bytes but only needs 1266 to be sent once since a performance optimization allows the session 1267 key to be cached as noted in Section 7.1 of [RFC2747]. It is assumed 1268 that subsequent RSVP messages only include the POLICY_DATA INTEGRITY 1269 object with a keyed message digest that uses the Kerberos session 1270 key. This however assumes that the security association required for 1271 the POLICY_DATA INTEGRITY object is created after (or modified) to 1272 allow the selection of the correct key. Otherwise it difficult to say 1273 which identifier is used to index the security association. 1275 When Kerberos is used as an authentication system then, from a 1276 performance perspective, then the message exchange to obtain the 1277 session key needs to be considered although the exchange only needs 1278 to be done once in a long time frame depending on the lifetime of the 1279 session ticket. This is particularly true in a mobile environment 1280 with a fast roaming user's host. 1282 Public key based authentication usually provides the best scalability 1283 characteristics for key distribution but the protocols are 1284 performance demanding. A major disadvantage of the public key based 1285 user authentication in RSVP is the non-existing possibility to derive 1286 a session key. Hence every RSVP PATH or RESV message includes the 1287 certificate and a digital signature, which is a huge performance and 1288 bandwidth penalty. For a mobile environment with low performance 1289 devices, high latency and low bandwidth links this seems to be less 1290 encouraging. Note that a public key infrastructure is required to 1291 allow the PDP (or the first-hop router) to verify the digital 1292 signature and the certificate. To check for revoked certificates, 1293 certificate revocation lists or protocols like the Online Certificate 1294 Status Protocol [RFC2560] and the Simple Certificate Validation 1295 Protocol [MHHF01]. Then the integrity of the AUTH_DATA object via the 1296 digital signature is verified. 1298 4.4 Communication between RSVP aware routers 1300 a) Authentication 1302 RSVP signaling messages are data origin authenticated and protected 1303 against modification and replay using the RSVP INTEGRITY object. 1304 IPsec may also provide RSVP signaling message protection is it, 1305 however, not suggested because of the problems described in Section 1306 5.6. Only in certain environments IPsec protection might not cause 1307 problems. The RSVP message flow between routers is protected based on 1309 Tschofenig Informational - Expires September 2003 25 1310 the chain of trust and hence each router only needs to have a 1311 security association with its neighboring routers. This assumption 1312 was made because of performance advantages and because of special 1313 security characteristics of the core network where no user hosts are 1314 directly attached. In the core network the network structure does not 1315 change frequently and the manual distribution of shared secrets for 1316 the RSVP INTEGRITY object may be acceptable. The shared secrets may 1317 be either manually configured or distributed by using network 1318 management protocols like SNMP. 1320 If IPsec is used in a hop-by-hop fashion then the required security 1321 associations may be manually created or dynamically distributed with 1322 IKE by either using symmetric or asymmetric authentication modes. A 1323 description of the existing IKE authentication modes and IKE security 1324 properties is outside the scope of this document. The reader is 1325 referred to the relevant documents at the IPsec working group. 1327 Independent of the key distribution mechanism host authentication 1328 with RSVP built-in mechanisms is accomplished with the keyed message 1329 digest in the RSVP INTEGRITY object computed using the previously 1330 exchanged symmetric key. In case of IPsec host authentication is 1331 accomplished with the keyed message digest included in the 1332 Authentication Data field of the IPsec Authentication Header included 1333 in every IP packet. 1335 b) Integrity Protection 1337 Integrity protection is either accomplished with the RSVP INTEGRITY 1338 object with the variable length Keyed Message Digest field or with 1339 the IPsec Authentication Header. A description of the IPsec AH is 1340 found in [RFC2402] and IPsec ESP [RFC2406] with null encryption is 1341 found in [RFC2410]. The main difference between IPsec and RSVP 1342 protection is the layer at which the security is applied. 1344 c) Replay Protection 1346 Replay protection with the RSVP INTEGRITY object is extensively 1347 described in previous Sections. IPsec provides an optional window- 1348 based replay protection, which may cause problems if a strict message 1349 ordering of RSVP messages is required. This problem was already 1350 discussed in a previous Section and a possible solution is to include 1351 the RSVP INTEGRITY object without a key, which reduces the RSVP 1352 integrity protection to a simple MD5 hash. This modification must 1353 however be integrated into an existing implementation and it is not 1354 clear whether the RSVP standard allows this modification. If the RSVP 1355 implementation is able to access the IPsec Security Association 1356 Database and retrieve the required security association then no such 1357 modification to RSVP is required and IKE is only used to distribute 1358 the security associations. This however requires the RSVP 1359 implementation to trigger the IKE exchange. 1361 Tschofenig Informational - Expires September 2003 26 1362 To enable crashed hosts to learn the latest sequence number used the 1363 Integrity Handshake mechanism is used in RSVP as explained in a 1364 Section above. IPsec does not provide such a mechanism since a 1365 crashed host looses its negotiated security associations and 1366 therefore has to re-negotiate them using IKE. Note that manually 1367 configured IPsec security associations do not provide replay 1368 protection because a sequence number rollover would require the 1369 establishment of a new SA. This is obviously not possible when using 1370 manually configured IPsec SAs. Using IKE with pre-shared secrets is 1371 therefore a simple solution. 1373 d) Confidentiality 1375 Confidentiality is not provided by RSVP but using IPsec ESP in a hop- 1376 by-hop mode can provide it. The usage of IPsec ESP for RSVP is not 1377 recommended because of the additional overhead for little additional 1378 security benefit if we think of the underlying assumed trust model of 1379 chain of trust. Hence there must be a good reason why to require 1380 confidentiality in a hop-by-hop fashion in the core network of the 1381 same administrative domain. If the RSVP network spawns different 1382 provider networks then it is possible to encapsulate RSVP messages 1383 between RSVP networks over a non-RSVP cloud similar to a VPN. Such a 1384 configuration is mainly determined by the network structure of a 1385 provider. 1387 e) Authorization 1389 Depending on the RSVP network QoS resource authorization at different 1390 routers may need to contact the PDP again. Since the PDP is allowed 1391 to modify the policy element, a token may be added to the policy 1392 element to increase the efficiency of the re-authorization procedure. 1393 This token is used to refer to an already computed policy decision. 1394 The communications interface from the PEP to the PDP must be properly 1395 secured. 1397 f) Performance 1399 The performance characteristics the protection of the RSVP signaling 1400 messages is largely determined by the key exchange protocol since the 1401 RSVP INTEGRITY object or IPsec AH are only used to compute a keyed 1402 message digest of the transmitted messages. Furthermore only RSVP 1403 signaling messages are protected and the protection of the 1404 application data stream is outside the scope of RSVP. IPsec ESP 1405 provides a performance penalty but may only be rarely used. A network 1406 administrator may however use IPsec ESP in transport mode with NULL 1407 encryption to provide the same functionality as IPsec AH but with the 1408 chance of better hardware support. 1410 The security associations within the core network i.e. between 1411 individual routers (in comparison to the security association between 1412 the user�s host and the first-hop router or with the attached network 1413 in general) can be established more easily because of the strong 1415 Tschofenig Informational - Expires September 2003 27 1416 trust assumptions. Furthermore it is possible to use security 1417 associations with an increased lifetime to avoid too frequent 1418 rekeying. Hence there is less impact for the performance compared to 1419 the user to network interface. The security association storage 1420 requirements are also less problematic. 1422 5 Miscellaneous Issues 1424 This section describes a number of issues which illustrate some of 1425 the short-comings of RSVP with respect to security. 1427 5.1 First Hop Issue 1429 In case of end-to-end signaling an end host starts signaling to its 1430 attached network. The first-hop communication is often more difficult 1431 because of the different requirements and a missing trust 1432 relationship. An end host must therefore obtain some information to 1433 start RSVP signaling: 1435 - Does this network support RSVP signaling? 1436 - Which node supports RSVP signaling? 1437 - To which node is authentication required? 1438 - Which identity is used for authentication? 1439 - Which security mechanisms are used for authentication? 1440 - Which algorithms have to be used? 1441 - Where should the keys/security association come from? 1442 - Should a security association be established? 1444 RSVP, as specified today, is used as a building block. Hence these 1445 questions have to be answered as part of overall architectural 1446 considerations. Without giving an answer to this question "ad-hoc" 1447 RSVP communication by an end host roaming to an unknown network is 1448 not possible. A negotiation of security mechanisms and algorithms is 1449 not supported for RSVP. 1451 5.2 Next-Hop Problem 1453 Throughout the document it was always assumed that the next RSVP node 1454 along the path is always known. Knowing your next hop is important to 1455 be able to select the correct key for the RSVP Integrity object to 1456 provide proper protection. In case that an RSVP node assumes to know 1457 which node is the next hop then the following protocol exchange can 1458 occur: 1460 Integrity 1461 (A<->C) +------+ 1462 (3) | RSVP | 1463 +------------->+ Node | 1464 | | B | 1465 Integrity | +--+---+ 1466 (A<->C) | | 1467 +------+ (2) +--+----+ | 1469 Tschofenig Informational - Expires September 2003 28 1470 (1) | RSVP +----------->+Router | | Error 1471 ----->| Node | | or +<-----------+ (I am B) 1472 | A +<-----------+Network| (4) 1473 +------+ (5) +--+----+ 1474 Error . 1475 (I am B) . +------+ 1476 . | RSVP | 1477 ...............+ Node | 1478 | C | 1479 +------+ 1480 Figure 5: Next-Hop Issue 1482 When RSVP node A in Figure x receives an incoming RSVP Path message 1483 then standard RSVP message processing takes place. Node A then has to 1484 decide which key to select to protect the signaling message. We 1485 assume that some mechanism which is not further specified is used to 1486 make this decision. In this example node A assumes that the message 1487 will travel to RSVP node C. However because of some reasons (e.g. a 1488 route change, inability to learn the next RSVP hop along the path, 1489 etc.) the message travels to node B via a non-RSVP supporting router 1490 which cannot verify the integrity of the message (or cannot decrypt 1491 the Kerberos service ticket). The processing failure causes a PathErr 1492 message to be returned to the originating sender of the Path message. 1493 This error message also contains information about the node 1494 recognizing the error. In many cases a security association might not 1495 be available. Node A receiving the PathErr message might use the 1496 information returned with the PathErr message to select a different 1497 security association (or to establish one). The RSVP Path message 1498 therefore provides a number of functions: path discovery, detecting 1499 route changes, learning of QoS capabilities along the path using the 1500 Adspec object, (with some interpretation) next-hop discovery and 1501 possibly security association establishment (for example in case of 1502 Kerberos). 1504 From a security point of view there is a conflict between 1506 - Idempotent messages delivery and efficiency 1508 Especially the RSVP Path message performs a number of functions. 1509 Supporting idempotent message delivery somehow contradicts with 1510 security association establishment and efficient message delivery and 1511 size. For example a "real" idempotent signaling message would contain 1512 enough information to perform security processing without depending 1513 on a previously executed message exchange. Adding a Kerberos ticket 1514 with every signaling message is, however, very inefficient. Using 1515 public key based mechanisms is even more inefficient when included in 1516 every signaling message. With public key based protection for 1517 idempotent messages there is additionally a risk of introducing 1518 denial of service attacks. 1520 - RSVP Path message functionality and next-hop discovery 1522 Tschofenig Informational - Expires September 2003 29 1523 To protect an RSVP signaling message (and a RSVP Path message in 1524 particular) it is necessary to know the identity of the next RSVP 1525 aware node (and some other parameters). Without a mechanism for next- 1526 hop discovery an RSVP Path message is also responsible for this task. 1527 Without knowing the identity of the next hop the Kerberos principal 1528 name is also unknown. The so-called Kerberos user-to-user 1529 authentication mechanism is not supported which would allow the 1530 receiver to trigger the process of establishing Kerberos 1531 authentication is not supported. This issue will again be discussed 1532 in relationship with the last-hop problem. 1534 It is fair to assume that a RSVP supporting node might not have a 1535 security association with all immediately neighboring RSVP nodes. 1536 Especially for inter-domain signaling, IntServ over DiffServ or for 1537 some new applications such as firewall signaling the next RSVP aware 1538 node might not be known in advance. The number of next RSVP nodes 1539 might be considerably large if they are separated by a large number 1540 of non-RSVP aware nodes. Hence a node transmitting a RSVP Path 1541 message might experience difficulties to properly protect the message 1542 if it serves as a mechanism to detect both the next RSVP node (i.e. 1543 Router Alert Option added to the signaling message and addressed to 1544 the destination address) and to detect route changes. It is fair to 1545 note that in an intra-domain case this might be possible due to 1546 manual configuration in case of a dense distribution of RSVP nodes. 1548 There is nothing which prevents an adversary from continuously 1549 flooding an RSVP node with bogus PathErr messages. It might be 1550 possible to protect the PathErr message with an existing security 1551 association if available. A legitimate RSVP node would believe that a 1552 change in the path took place. Hence this node would try to select a 1553 different security association or try to create one with the 1554 indicated node. Hence an adversary can send a PathErr message at any 1555 time to confuse an RSVP node. If an adversary is located along 1556 somewhere along the path then it might also be possible to act as a 1557 man-in-the-middle adversary if either authentication and/or 1558 authorization is not performed with the necessary accuracy. 1560 5.3 Last-Hop Issue 1562 This section tries to address practical difficulties when 1563 authentication and key establishment is accomplished with a protocol 1564 which shows some asymmetry in message processing when executed 1565 between two nodes. Kerberos is such a protocol and also the only 1566 supported protocol which provides dynamic session key establishment 1567 for RSVP. For first-hop communication authentication is typically 1568 done between a user and some network in the network (for example the 1569 access router). Especially in a mobile environment it is not feasible 1570 to authenticate end hosts based on their IP or MAC address. To show 1571 the problem the typical processing steps for Kerberos are shown for 1572 first-hop communication: 1574 Tschofenig Informational - Expires September 2003 30 1575 a) The end host A learns the identity (i.e. Kerberos principal name) 1576 of some entity B. This entity B is either the next RSVP node or a PDP 1577 or the next policy aware RSVP node. 1579 b) Entity A then requests a ticket granting ticket for the network 1580 domain. This assumes that the identity of the network domain is 1581 known. 1583 c) Entity A then requests a service ticket for entity B which was 1584 learned in step (a). 1586 d) Entity A includes the service ticket to the RSVP signaling message 1587 (inside the policy object). The Kerberos session key is used to 1588 protect the entire RSVP signaling message. 1590 For last-hop communication this processing step theoretically has to 1591 be reversed; entity A is then a node in the network (for example the 1592 access router) and entity B is the other end host. This assumes that 1593 RSVP signaling is accomplished between two end hosts and not between 1594 an end host and a application server. The access router might however 1595 in step (a) not be able to learn the identity of the user's principal 1596 name since this information might not be available. Entity A could 1597 reverse the process by triggering an IAKERB exchange. This would 1598 cause entity B to request a service ticket for A as described above. 1599 IAKERB is however not supported. 1601 5.4 RSVP and IPsec protected data traffic 1603 QoS signaling requires flow information to be established at routers 1604 along a path. This flow identifier installed at each devices tells 1605 the router which data packets should experience QoS treatment. RSVP 1606 typically establishes a flow identifier based on the 5-tuple (source 1607 IP address, destination IP address, transport protocol type, source 1608 port and destination port). If this 5-tuple information is not 1609 available then other identifiers have to be used. IPsec protected 1610 data traffic is such an example where the transport protocol and the 1611 port numbers are not accessible. Hence the IPsec SPI is used as a 1612 substitute for them. RFC 2207 considers these IPsec implications for 1613 RSVP and is based on three assumptions: 1615 a) An end host, which initiates the RSVP signaling message exchange, 1616 has to be able to retrieve the SPI for given flow. This requires some 1617 interaction with the IPsec SADB and SPD. An application usually does 1618 not know the SPI of the protected flow and cannot provide the desired 1619 values. It can provide the signaling protocol daemon with flow 1620 identifiers. The signaling daemon would then need to query the IPsec 1621 security association database by providing the flow identifiers as 1622 input parameters and the SPI as an output parameter. 1624 b) RFC 2207 assumes an end-to-end IPsec protection of the data 1625 traffic. In IPsec is applied in a nested fashion then parts of the 1626 path do not experience QoS treatment. This problem can be treated as 1628 Tschofenig Informational - Expires September 2003 31 1629 a tunneling problem but is initiated by the end host. A figure better 1630 illustrates the problem in case of enforcing secure network access: 1632 +------+ +---------------+ +--------+ +------+ 1633 | Host | | Security | | Router | | Host | 1634 | A | | Gateway (SGW) | | Rx | | B | 1635 +--+---+ +-------+-------+ +----+---+ +--+---+ 1636 | | | | 1637 |IPsec-Data( | | | 1638 | OuterSrc=A, | | | 1639 | OuterDst=SGW, | | | 1640 | SPI=SPI1, | | | 1641 | InnerSrc=A, | | | 1642 | OuterDst=B, | | | 1643 | Protocol=X, |IPsec-Data( | | 1644 | SrcPort=Y, | SrcIP=A, | | 1645 | DstPort=Z) | DstIP=B, | | 1646 |=====================>| Protocol=X, |IPsec-Data( | 1647 | | SrcPort=Y, | SrcIP=A, | 1648 | --IPsec protected-> | DstPort=Z) | DstIP=B, | 1649 | data traffic |------------------>| Protocol=X, | 1650 | | | SrcPort=Y, | 1651 | | | DstPort=Z) | 1652 | | |---------------->| 1653 | | | | 1654 | | --Unprotected data traffic-> | 1655 | | | | 1656 Figure 6: RSVP and IPsec protected data traffic 1658 Host A transmitting data traffic would either indicate a 3-tuple or a 5-tuple . In any case it is not 1660 possible to make a QoS reservation for the entire path. Similar 1661 examples are remote access using a VPN, protection of data traffic 1662 between the home agent (or a security gateway in the home network) 1663 and the mobile node and other. With a nested application of IPsec 1664 (for example IPsec between A and SGW and between A and B) the same 1665 problem occurs. 1667 One possible solution to this problem is to change the flow 1668 identifier along the path to capture the new flow identifier after an 1669 IPsec endpoint. 1671 IPsec tunnels which neither start nor terminate at one of the 1672 signaling end points (for example between two networks) should be 1673 addressed differently by recursively applying an RSVP signaling 1674 exchange for the IPsec tunnel. RSVP signaling within tunnels is 1675 addressed in [RFC2746]. 1677 c) It is assumed that SPIs do not change during the lifetime of the 1678 established QoS reservation. If a new IPsec SA is created then a new 1679 SPI is allocated for the security association. To reflect this change 1680 either a new reservation has to be established or the flow identifier 1682 Tschofenig Informational - Expires September 2003 32 1683 of the existing reservation has to be updated. Since IPsec SAs have a 1684 longer lifetime this issue does not seem to be a major issue. IPsec 1685 protection of SCTP data traffic might more often require an IPsec SA 1686 (and an SPI) change to reflect added and removed IP addresses from an 1687 SCTP association. 1689 5.5 End-to-End Security Issues and RSVP 1691 End-to-end security for RSVP has not been discussed throughout the 1692 document. In this context end-to-end security refers to credentials 1693 transmitted between the two end hosts using RSVP. It is obvious that 1694 care must be taken to ensure that routers along the path are able to 1695 process and modify the signaling messages according to the processing 1696 procedure. Some objects however could be used for end-to-end 1697 protection. The main question however is what the benefit of such an 1698 end-to-end security is. First there is the question how to establish 1699 the required security association. Between two arbitrary hosts on the 1700 Internet this might turn out to be quite difficult. Furthermore it 1701 depends on an architecture where RSVP is deployed whether it is 1702 useful to provide end-to-end security. If RSVP is only used to signal 1703 QoS information into the network and other protocols have to be 1704 executed beforehand to negotiate the parameters and to decide which 1705 entity is charged for the QoS reservation then no end-to-end security 1706 is likely to be required. Introducing end-to-end security to RSVP 1707 would then cause problems with extensions like RSVP proxy [GD+02], 1708 Localized RSVP [MS+02] and others which terminate RSVP signaling 1709 somewhere along the path without reaching the destination end host. 1710 Such a behavior could then be interpreted as a man-in-the-middle 1711 attack. 1713 5.6 IPsec protection of RSVP signaling messages 1715 In this document it was assumed that RSVP signaling messages can also 1716 be protected by IPsec in a hop-by-hop fashion between two adjacent 1717 RSVP nodes. RSVP uses a special processing of signaling messages 1718 which complicates IPsec protection. As we explain in this section 1719 IPsec should only be used for protection of RSVP signaling messages 1720 in a point-to-point communication environment (i.e. a RSVP message 1721 can only reach one RSVP router and not possibly more than one). This 1722 circumstance is caused by the combination of signaling message 1723 delivery and discovery into a single message. Furthermore the end-to- 1724 end addressing complicates IPsec handling considerably. This section 1725 tries to describe these complications. 1727 RSVP messages are transmitted as raw IP packets with protocol number 1728 46. It might be possible to encapsulate them in UDP as described in 1729 Appendix C of [RFC2205]. Some RSVP messages (Path, PathTear, and 1730 ResvConf) must have the Router Alert IP Option set in the IP header. 1731 These messages are addressed to the (unicast or multicast) 1732 destination address and not to the next RSVP node along the path. 1733 Hence an IPsec traffic selector can only use these fields for IPsec 1734 SA selection. If there is only a single path (and possibly every 1736 Tschofenig Informational - Expires September 2003 33 1737 traffic is protected) then there is no problem for IPsec protection 1738 of signaling messages. This type of protection is not common and 1739 might only be used to secure network access between an end host and 1740 its first-hop router. Since the described RSVP messages are addressed 1741 to the destination address instead of the next RSVP node it is not 1742 possible to use IPsec in transport mode - only IPsec in tunnel mode 1743 is possible. 1745 If there is more than one possible path which an RSVP message can 1746 take then the IPsec engine will experience difficulties to protect 1747 the message. Even if the RSVP daemon installs a traffic selector with 1748 the destination IP address then still there is no distinguishing 1749 element which allows to select the correct security association of 1750 one of the possible RSVP nodes along. Even if it possible to apply 1751 IPsec protection (in tunnel mode) for RSVP signaling messages by 1752 incorporating some additional information then there is still the 1753 possibility that the tunneled messages do not recognize a path change 1754 in a non-RSVP router. Then the signaling messages would simply follow 1755 different path than the data. 1757 RSVP messages like RESV can be protected by IPsec since they are 1758 contain enough information to create IPsec traffic selectors which 1759 allow a differentiation between different next RSVP nodes. A traffic 1760 selector would then contain the protocol number and the source / 1761 destination address pair. 1763 5.7 Accounting/Charging Framework 1765 In [TB+03] two trust models (NJ Turnpike and NJ Parkway model) and 1766 two authorization models (per-session and per-channel financial 1767 settlement). The NJ Turnpike model gives a justification for the hop- 1768 by-hop security protection. RSVP supports the NJ Parkway model and 1769 per-channel financial settlement to some extend only. The 1770 communication procedures defined for policy object [Her95] can be 1771 improved to support the more efficient per-channel financial 1772 settlement by avoiding policy handling between inter-domain networks 1773 at a signaling message granularity. 1775 6 Conclusions 1777 RSVP was the first QoS signaling protocol which provided some 1778 security protection. Whether RSVP provides enough security protection 1779 heavily depends on the environment where it is deployed. As RSVP is 1780 specified today should be seen as a building block that has to be 1781 adapted to a given architecture. 1783 This document aims to provide more insights into the security of 1784 RSVP. It cannot not be interpreted as a pass or fail evaluation of 1785 the security provided by RSVP. 1787 Certainly this document is not complete to describe all security 1788 issues related to RSVP. Some issues that require further 1790 Tschofenig Informational - Expires September 2003 34 1791 considerations are RSVP extensions (for example [RFC2207]), multicast 1792 issues and other security properties like traffic analysis etc. 1793 Additionally the interaction with mobility protocols (micro- and 1794 macro-mobility) from a security point of view demands further 1795 investigation. 1797 What can be learned from a practical protocol experience and from the 1798 increased awareness regarding security is that some of the available 1799 credential types have received more acceptance. Kerberos is such a 1800 system which is integrated in many IETF protocols today. 1801 Public key based authentication techniques are however still 1802 considered to be too heavy-weight (computationally and from a 1803 bandwidth perspective) to be used for a per-flow signaling. The 1804 increased focus on denial of service attacks additionally demands a 1805 closer look on public key based authentication. 1807 The following list briefly summarizes a few security or architectural 1808 issues which desire improvement: 1810 * Discovery and signaling message delivery should be separated. 1812 * For some applications and scenarios it cannot be assumed that 1813 neighboring RSVP aware nodes know each other. Hence some in-path 1814 discovery mechanism should be provided. 1816 * Addressing for signaling messages should be done in a hop-by-hop 1817 fashion. 1819 * Standard security protocols (IPsec, TLS or CMS) should be used 1820 whenever possible. Authentication and key exchange should separated 1821 from signaling message protection. In general it is necessary to 1822 provide key management to dynamically establish a security 1823 association for signaling message protection. Relying on manually 1824 configured keys between neighboring RSVP nodes is insufficient. 1826 * The usage of public key cryptography for authorization tokens, 1827 identity representation, selective object protection, etc. is likely 1828 to cause fragmentation and problems. 1830 * Public key authentication and user identity confidentiality 1831 provided with RSVP require some improvement. 1833 * Public key based user authentication only provides entity 1834 authentication. An additional security association is required to 1835 protect the signaling message. 1837 * Data origin authentication should not be provided by non-RSVP nodes 1838 (such as the PDP). Such a procedure could be accomplished by entity 1839 authentication during the authentication and key exchange phase. 1841 * Authorization and charging should be better integrated in the base 1842 protocol. 1844 Tschofenig Informational - Expires September 2003 35 1845 * Selective message protection should be provided. A protected 1846 message should be recognizable from a flag in the header. 1848 * Confidentiality protection is missing and should therefore be added 1849 to the protocol. 1851 * Parameter and mechanism negotiation should be provided. 1853 7 Security Considerations 1855 This document discusses security properties of RSVP and as such, it 1856 is concerned entirely with security. 1858 8 IANA considerations 1860 This document does not address any IANA considerations. 1862 9 Open Issues 1864 A future version of this draft will restructure and shorten the 1865 document and include references to other RSVP security related 1866 activities and papers. 1868 10 Acknowledgments 1870 I would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu and 1871 Guenther Schaefer for their valuable comments. Additionally I would 1872 like to thank Robert and Jorge for their time to discuss various 1873 issues with me. Furthermore I would like to thank Marc De Vuyst for 1874 his comments to the draft. 1876 Appendix A. Dictionary Attacks and Kerberos 1878 This section addresses issues related to Kerberos and its 1879 vulnerability against dictionary attacks since there often seems to 1880 be a misunderstanding. The reason for including this discussion in 1881 this document is that Kerberos seems to be one of the most widely 1882 supported authentication and key distribution systems available. 1884 The initial Kerberos AS_REQ request (without pre-authentication, 1885 various extensions and without PKINIT) is unprotected. The response 1886 message AS_REP is encrypted with the client's long-term key. An 1887 adversary can take advantage of this fact by requesting AS_REP 1888 messages to mount an off-line dictionary attack. Using pre- 1889 authentication ([Pat92]) can be used to reduce this problem. 1890 However pre-authentication does not entirely prevent dictionary 1891 attacks by an adversary since he can still eavesdrop Kerberos 1892 messages if being located at the path between the mobile node and the 1893 KDC. With mandatory pre-authentication for the initial request an 1894 adversary cannot request a Ticket Granting Ticket for an arbitrary 1896 Tschofenig Informational - Expires September 2003 36 1897 user. On-line password guessing attacks are still possible by 1898 choosing a password (e.g. from a dictionary) and then transmitting an 1899 initial request including pre-authentication data field. An 1900 unsuccessful authentication by the KDC results in an error message 1901 and the gives the adversary a hint to try a new password and restart 1902 the protocol again. 1904 There are however some proposals that prevent dictionary attacks from 1905 happening. The use of Public Key Cryptography for initial 1906 authentication [TN+01] (PKINIT) is one such solution. Other proposals 1907 use strong-password based authenticated key agreement protocols like 1908 the Encrypted Key Exchange protocol (EKE) to avoid leaking of user 1909 password information. B. Jaspan investigated the use of EKE for 1910 Kerberos V5 called "Dual-workfactor Encrypted Key Exchange" [Jas96] 1911 which is described below. 1913 With the PA-ENC-DH pre-authentication Jaspan included the Diffie- 1914 Hellman "public key" of the client encrypted with the user password 1915 in the initial AS_REQ to the Authentication Server. Additionally the 1916 modulus m is included since the client can choose this value 1917 dynamically. 1919 It is interesting to note that pre-authentication was orginally 1920 introduced to allow the user to authenticate to the AS with the 1921 inital AS_REQ message . The use of the Encrypted Key Exchange 1922 protocol [BM92] as a pre-authentication mechanism does not allow the 1923 Authentication Server to authenticate the client since this would 1924 require the client to include verifiable data (e.g. a keyed message 1925 digest for data origin authentication) but this destroys the 1926 properties of EKE. EKE was designed to create a strong-password based 1927 authentication protocol that is resistant against dictionary attacks. 1928 Hence after the second message the Authentication Server is 1929 authenticated to the client by showing that he was able to compute 1930 the shared key k(a,as) used to encrypt the first part of message (2). 1931 The client is not authenticated to the Authentication Server. 1933 It is obvious that both the client and the Authentication Server must 1934 be able to provide good random numbers for the creation of the 1935 Diffie-Hellman key pair. Jaspan additionally noted that the timestamp 1936 in the response from the Authentication Server (AS_REP message) can 1937 be used to eliminate the dependency on time synchronization of the 1938 Kerberos protocol. The client can use this value to adjust his clock 1939 after successful authentication of the Authentication Server. 1941 The vulnerability against denial of service attacks is a disadvantage 1942 common to many strong-password based authenticated key agreement 1943 protocols. Nothing prevents an adversary from flooding the 1944 Authentication Server with bogus AS_REQ messages using the pre- 1945 authentication method PA-ENC-DH. This forces the Authentication 1946 Server to create a Diffie-Hellman public/private key pair, to decrypt 1947 the received response and to compute the session key k(a,as) and to 1948 return a message to the source IP address of the previously received 1950 Tschofenig Informational - Expires September 2003 37 1951 message. Even if the Authentication Server does not re-create a new 1952 public/private key pair with every session he still has to compute 1953 the session key which requires multiprecision operations and this is 1954 time consuming. 1956 Jaspan furthermore noted that the missing client authentication can 1957 be used by an undetectable on-line password guessing attack as 1958 described in [DH95]. An adversary sends an AS_REQ for a user B 1959 encrypted with a password k(b�). The Authentication Server decrypts 1960 the value of the pre-authentication field with the real user password 1961 k(b) and encrypts his response to the adversary. If the adversary 1962 correctly guessed the password of user B then the receive response 1963 verifies correctly. Jaspan proposed to modify the KDC to allow only a 1964 certain number of requests per day but this can be used by an 1965 attacker to mount a denial of service attack against such users to 1966 lock their accounts by sending a number of incorrect requests to the 1967 KDC. The KDC would then reject Ticket Granting Ticket or even a 1968 service ticket from legitimate users. 1970 Tom Wu mentioned in [Wu99] the use of a variant of SRP [Wu98] and the 1971 use of SPEKE [Jab96] to be used in the pre-authentication process as 1972 possible candidates to prevent dictionary attacks. Unfortunately Wu 1973 does not explain the proposals in detail. 1975 Currently only PKINIT is available for preventing off-line dictionary 1976 attacks. Other proposals described above like SPEKE, SRP etc. are not 1977 included in the current Kerberos version. IPR issues may be one of 1978 the reasons. 1980 Appendix B. Example of User-to-PDP Authentication 1982 The following Section describes an example of user-to-PDP 1983 authentication. Note that the description below is not fully covered 1984 by the RSVP specification and hence it should only be seen as an 1985 example. 1987 Windows 2000, which integrates Kerberos into RSVP, uses a 1988 configuration with the user authentication to the PDP as described in 1989 [MADS01]. The steps for authenticating the user to the PDP in an 1990 intra-realm scenario are the following: 1992 - Windows 2000 requires the user to contact the KDC and to request a 1993 Kerberos service ticket for the PDP account AcsService in the local 1994 realm. 1996 - This ticket is then embedded in the AUTH_DATA element and included 1997 in either the PATH or the RESV message. In case of Microsoft�s 1998 implementation the user identity encoded as a distinguished name is 1999 encrypted with the session key provided with the Kerberos ticket. The 2000 Kerberos ticket is sent without the Kerberos authdata element that 2001 contains authorization information as explained in [MADS01]. 2003 Tschofenig Informational - Expires September 2003 38 2004 - The RSVP message is then intercepted by the PEP who forwards it to 2005 the PDP. [MADS01] does not state which protocol is used to forward 2006 the RSVP message to the PDP. 2008 - The PDP who finally receives the message decrypts the received 2009 service ticket. The ticket contains the session key which was used by 2010 the user's host to 2011 a) Encrypt the principal name inside the policy locator field of the 2012 AUTH_DATA object and to 2013 b) Create the integrity protected Keyed Message Digest field in the 2014 INTEGRITY object of the POLICY_DATA element. The protection described 2015 here is between the user's host and the PDP. The RSVP INTEGRITY 2016 object on the other hand is used to protect the path between the 2017 users host and the first-hop router since the two message parts 2018 terminate at a different node and a different security association 2019 must be used. The interface between the message intercepting first- 2020 hop router and the PDP must be protected as well. 2021 c) The PDP does not maintain a user database and [MADS01] describes 2022 that the PDP may query the Active Directory (a LDAP based directory 2023 service) for user policy information. 2025 11 References 2027 [BM92] Bellovin, B., Merrit, M.: "Encrypted Key Exchange: 2028 Password-based protocols secure against dictionary attacks", in 2029 "Proceedings of the IEEE Symposium on Research in Security and 2030 Privacy", May, 1992. 2032 [CA+02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G., 2033 Loughney, J.: "DIAMETER Base Protocol", , (work in progress), December, 2002. 2036 [DBP96] Dobbertin, H., Bosselaers, A., Preneel, B.: "RIPEMD- 2037 160: A strengthened version of RIPEMD", in "Fast Software Encryption, 2038 LNCS Vol 1039, pp. 71-82", 1996. 2040 [DG96] Davis, D., Geer, D.: "Kerberos With Clocks Adrift: 2041 History, Protocols and Implementation", in "USENIX Computing Systems 2042 Volume 9 no. 1, Winter", 1996. 2044 [DH95] Ding, Y., Horster, P.: "Undetectable On-line Password 2045 Guessing Attacks", Operating Systems Review, 29(No. 4), pp. 77-86, 2046 1995. 2048 [Dob96] Dobbertin, H.: "The Status of Md5 After a Recent 2049 Attack," RSA Laboratories' CryptoBytes, Volume 2, Number 2, 1996. 2051 [FH+01] Thomas, M., Vilhuber, J.: "Kerberized Internet 2052 Negotiation of Keys (KINK)", , (work in 2053 progress), January, 2003. 2055 Tschofenig Informational - Expires September 2003 39 2057 [GD+02] Gai, S., Dutt, D., Elfassy, N., Bernet, Y.: "RSVP 2058 Proxy", , (expired), March, 2002. 2060 [HA01] Hornstein, K., Altman, J.: "Distributing Kerberos KDC 2061 and Realm Information with DNS", , (work in progress), July, 2002. 2064 [HH01] Hess, R., Herzog, S.: "RSVP Extensions for Policy 2065 Control", , (expired), June, 2066 2001. 2068 [Jab96] Jablon, D.: "Strong password-only authenticated key 2069 exchange", Computer Communication Review, 26(5), pp. 5-26, October, 2070 1996. 2072 [Jas96] Jaspan, B.: "Dual-workfactor Encrypted Key Exchange: 2073 Efficiently Preventing Password Chaining and Dictionary Attacks", in 2074 "Proceedings of the Sixth Annual USENIX Security Conference", pp. 43- 2075 50, July, 1996. 2077 [MADS01] "Microsoft Authorization Data Specification v. 1.0 for 2078 Microsoft Windows 2000 Operating Systems", April, 2000, available at: 2079 http://www.microsoft.com/technet/security/kerberos/default.asp, 2080 February, 2001. 2082 [MHHF01] Malpani, A., Hoffman, P., Housley, R., Freeman, T.: 2083 "Simple Certificate Validation Protocol (SCVP)", , (work in progress), December, 2002. 2086 [MS+02] Manner, J., Suihko, T., Kojo, M., Liljeberg, 2087 M., Raatikainen, K.: "Localized RSVP", , 2088 (expired), May, 2002. 2090 [Pat92] Pato, J., "Using Pre-Authentication to Avoid Password 2091 Guessing Attacks", Open Software Foundation DCE Request for Comments 2092 26, December, 1992. 2094 [PGP] 2095 "Specifications and standard documents", 2096 http://www.pgpi.org/doc/specs/, March, 2002. 2098 [PKTSEC] PacketCable Security Specification, PKT-SP-SEC-I01- 2099 991201, Cable Television Laboratories, Inc., December 1, 1999, 2100 http://www.PacketCable.com/. 2102 [Rae01] Raeburn, K.: "Rijndael, Serpent, and Twofish 2103 Cryptosystems for Kerberos 5", , (expired), July, 2001. 2106 [RF2367] McDonald, D., Metz, C., Phan, B.: "PF_KEY Key 2107 Management API, Version 2", RFC 2367, July, 1998. 2109 Tschofenig Informational - Expires August 2002 40 2111 [RFC1321] Rivest, R.: "The MD5 Message-Digest Algorithm", RFC 2112 1321, April, 1992. 2114 [RFC1510] Kohl, J., Neuman, C.: "The Kerberos Network 2115 Authentication Service (V5)", RFC 1510, September 1993. 2117 [RFC2104] Krawczyk, H., Bellare, M., Canetti, R.: "HMAC: Keyed- 2118 Hashing for Message Authentication", RFC 2104, February, 1997. 2120 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, 2121 S.: �Resource ReSerVation Protocol (RSVP) � Version 1 Functional 2122 Specification", RFC 2205, September 1997. 2124 [RFC2207] Berger, L., O�Malley, T.: �RSVP Extensions for IPSEC 2125 Data Flows", RFC 2207, September 1997. 2127 [RFC2315] Kaliski, B.: " PKCS #7: Cryptographic Message Syntax 2128 Version 1.5", RFC 2315, March, 1998. 2130 [RFC2367] McDonald, D., Metz, C., Phan, B.: "PF_KEY Key 2131 Management API, Version 2", RFC 2367, July, 1998. 2133 [RFC2401] Kent, S., Atkinson, R.: "Security Architecture for the 2134 Internet Protocol", RFC 2401, November, 1998. 2136 [RFC2402] Kent, S., Atkinson, R.: "IP Authentication Header", RFC 2137 2402, November, 1998. 2139 [RFC2406] Kent, S., Atkinson, R.: "IP Encapsulating Security 2140 Payload (ESP)", RFC 2406, November, 1998. 2142 [RFC2409] Harkins, D., Carrel, D.: "The Internet Key Exchange 2143 (IKE)", RFC 2409, November, 1998. 2145 [RFC2410] Glenn, R., Kent, S.: "The NULL Encryption Algorithm and 2146 Its Use With IPsec", RFC 2410, November, 1998. 2148 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., Thayer, R.: 2149 "OpenPGP Message Format", RFC 2440, November, 1998. 2151 [RFC2495] Housley, R., Ford, W., Polk, W., Solo, D.: "Internet 2152 X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2153 2459, January, 1999. 2155 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., 2156 Adams, C.: "X.509 Internet Public Key Infrastructure Online 2157 Certificate Status Protocol � OCSP", RFC 2560, June, 1999. 2159 [RFC2630] Housley, R.: "Cryptographic Message Syntax", RFC 2630, 2160 June, 1999. 2162 Tschofenig Informational - Expires August 2002 41 2164 [RFC2747] Baker, F., Lindell, B., Talwar, M.: "RSVP Cryptographic 2165 Authentication", RC 2747, January, 2000. 2167 [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, 2168 R., Sastry, A.: "The COPS(Common Open Policy Service) Protocol", RFC 2169 2748, January, 2000. 2171 [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, 2172 R., Sastry, A.: "COPS usage for RSVP", RFC 2749, January, 2000. 2174 [RFC2750] Herzog, S.: "RSVP Extensions for Policy Control", RFC 2175 2750, January, 2000. 2177 [RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.: 2178 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 2179 June, 2000. 2181 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 2182 T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 2183 3182, October, 2001. 2185 [SHA] 2186 NIST, FIPS PUB 180-1, "Secure Hash Standard", April, 1995. 2188 [TN+01] Tung, B., Neuman, C., Hur, M., Medvinsky, A., 2189 Medvinsky, S., Wray, J., Trostle, J.: "Public Key Cryptography for 2190 Initial Authentication in Kerberos", , (work in progress), October, 2001. 2193 [Wu98] Wu, T.: "The Secure Remote Password Protocol", in 2194 "Proceedings of the Internet Society Network and Distributed System 2195 Security Symposium", pp. 97-111, March, 1998. 2197 [Wu99] Wu, T.: "A Real-World Analysis of Kerberos Password 2198 Security", in "Proceedings of the 1999 Network and Distributed System 2199 Security", February, 1999. 2201 [TB+03] H. Tschofenig, M. Buechli, S. Van den Bosch, H. 2202 Schulzrinne: "NSIS Authentication, Authorization and Accounting 2203 Issues", , (work in 2204 progress), March, 2003. 2206 [Her95] Herzog, S.: " Accounting and Access Control in RSVP", 2207 , (expired), November, 1995. 2209 12 Author's Contact Information 2211 Hannes Tschofenig 2212 Siemens AG 2213 Otto-Hahn-Ring 6 2214 81739 Munich 2215 Germany 2216 Email: Hannes.Tschofenig@siemens.com 2218 Tschofenig Informational - Expires August 2002 42 2219 13 Full Copyright Statement 2221 Copyright (C) The Internet Society (2000). All Rights Reserved. 2223 This document and translations of it may be copied and furnished to 2224 others, and derivative works that comment on or otherwise explain it 2225 or assist in its implementation may be prepared, copied, published 2226 and distributed, in whole or in part, without restriction of any 2227 kind, provided that the above copyright notice and this paragraph are 2228 included on all such copies and derivative works. However, this 2229 document itself may not be modified in any way, such as by removing 2230 the copyright notice or references to the Internet Society or other 2231 Internet organizations, except as needed for the purpose of 2232 developing Internet standards in which case the procedures for 2233 copyrights defined in the Internet Standards process must be 2234 followed, or as required to translate it into languages other than 2235 English. 2237 The limited permissions granted above are perpetual and will not be 2238 revoked by the Internet Society or its successors or assigns. 2240 This document and the information contained herein is provided on an 2241 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2242 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2243 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2244 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2245 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2247 Acknowledgement 2249 Funding for the RFC Editor function is currently provided by the 2250 Internet Society. 2252 Tschofenig Informational - Expires August 2002 43