idnits 2.17.1 draft-ietf-sipping-policy-package-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2006) is 6515 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-01 ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Lucent Technologies 4 Expires: December 27, 2006 G. Camarillo 5 Ericsson 6 June 25, 2006 8 A Session Initiation Protocol (SIP) Event Package for Session-Specific 9 Session Policies. 10 draft-ietf-sipping-policy-package-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This specification defines a Session Initiation Protocol (SIP) event 44 package for session-specific policies. This event package enables 45 user agents to subscribe to session policies for a SIP session and to 46 receive notifications if these policies change. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Event Package Formal Definition . . . . . . . . . . . . . . . 4 53 3.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 4 55 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 56 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 6 57 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 58 3.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 7 59 3.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 7 60 3.8. Notifier generation of NOTIFY requests . . . . . . . . . . 8 61 3.9. Subscriber processing of NOTIFY requests . . . . . . . . . 9 62 3.10. Handling of forked requests . . . . . . . . . . . . . . . 9 63 3.11. Rate of notifications . . . . . . . . . . . . . . . . . . 9 64 3.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 16 76 1. Introduction 78 The Framework for Session Initiation Protocol (SIP) [5] Session 79 Policies [6] specifies a protocol framework for session policies. 80 The framework enables a proxy to define and impact policies on 81 sessions such as the codecs or media types to be used. More details 82 on session policies can be found in [6]. 84 Two types of session policies exist: session-specific and session- 85 independent policies. Session-specific policies are policies that 86 are created for one particular session, based on the session 87 description of this session. They enable a network intermediary to 88 inspect the session description a UA is proposing and to return a 89 policy specifically generated for this session description. For 90 example, an intermediary could open pinholes in a firewall/NAT for 91 each media stream in a session and return a policy that replaces the 92 internal IP addresses and ports with external ones. Since session- 93 specific policies are tailored to a session, they only apply to the 94 session they are created for. A user agent requests session-specific 95 policies on a session-by-session basis at the time a session is 96 created and the session description is known. Session-independent 97 policies on the other hand are policies that are created independent 98 of a session and generally apply to the SIP sessions set up by a user 99 agent (see [6]). 101 The Framework for SIP Session Policies [6] defines a mechanism that 102 enables UAs to discover the URIs of session-specific policy servers. 104 This specification defines a mechanism that enables UAs to contact 105 policy servers, provide information about the current session to the 106 policy server and to receive session policies and updates to these 107 policies in response. The mechanism is realized by enabling UAs to 108 subscribe to the session-specific policies on a policy server. This 109 specification defines a SIP event package [4] for subscriptions to 110 session-specific policies. 112 Subscribing to session-specific policies involves the following steps 113 (see [6]): 115 1. A user agent submits the details of the session it is trying to 116 establish to the policy server and asks whether a session using 117 these parameters is permissible. For example, a user agent might 118 propose a session that contains the media types audio and video. 119 2. The policy server generates a policy decision for this session 120 and returns the decision to the user agent. Possible policy 121 decisions are (1) to deny the session, (2) to propose changes to 122 the session parameters with which the session would be 123 acceptable, or (3) to accept the session as it was proposed. An 124 example for a policy decision is to disallow the use of video but 125 agree to all other aspects of the proposed session. 126 3. The policy server can update the policy decision at a later time. 127 A policy decision update can, for example, require additional 128 changes to the session (e.g. because the available bandwidth has 129 changed) or deny a previously accepted session (i.e. disallow the 130 continuation of a session). 132 The event package for session-specific policies enables a user agent 133 to subscribe to the policies for a SIP session following the above 134 abstract model. The subscriber initiates a subscription by 135 submitting the details of the session it is trying to establish to 136 the notifier (i.e. the policy server) in the body of a SUBSCRIBE 137 request. The notifier uses this information to determine the policy 138 decision for this session. This policy decision is the resource to 139 which the subscriber is subscribing. The notifier conveys the 140 initial policy decision to the subscriber in a NOTIFY request and all 141 changes to this decision in subsequent NOTIFY requests. 143 2. Terminology 145 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 146 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 147 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 148 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 149 compliant implementations. 151 3. Event Package Formal Definition 153 This document provides the details for defining a SIP event package 154 as required by RFC 3265 [4]. 156 3.1. Event Package Name 158 The name of the event package defined in this specification is 159 "session-spec-policy". 161 3.2. Event Package Parameters 163 This package defines the optional event package parameter "local- 164 only". This parameter is only defined for NOTIFY requests and MUST 165 be ignored if received in a SUBSCRIBE request. The usage of the 166 "local-only" parameter is described in Section 3.3, Section 3.8 and 167 Section 3.9. 169 3.3. SUBSCRIBE Bodies 171 A SUBSCRIBE for the session-specific policy package SHOULD contain a 172 body that describes a SIP session. The purpose of this body is to 173 enable the notifier to generate the policies the subscriber is 174 interested in. In this event package, the Request-URI, the event 175 package name and event parameters are not sufficient to determine the 176 resource a subscription is for. With the session description in the 177 SUBSCRIBE body, the notifier can generate the requested policy 178 decision and create policy events for this resource. 180 All subscribers and notifiers MUST support the MIME type 181 "application/session-policy+xml" as defined in the User Agent Profile 182 Data Set for Media Policy [3]. The "application/session-policy+xml" 183 format is the default format for SUBSCRIBE bodies in this event 184 package. Subscribers and notifiers MAY negotiate the use of other 185 formats capable of representing a session. 187 OPEN ISSUE: this is a significant change from the previous version 188 of the draft where the SUBSCRIBE body contained a session 189 description in SDP format. Using an XML based policy format has a 190 number of advantages: i) it is more flexible and enables the 191 inclusion of information that can't be expressed via SDP (e.g. the 192 target URI), ii) it enables the encoding of local and remote 193 session descriptions in a single document (not requiring the use 194 of MIME multipart and new content disposition types), and iii) 195 aligns the formats used for session-specific and session- 196 independent policies. However, a drawback is that it requires the 197 UA to generate these XML documents instead of simply inserting the 198 session description. 200 Note: the "application/session-policy+xml" format does not yet 201 support all functionality needed for the use in SUBSCRIBE bodies. 203 Subscriptions to the session-specific policy package are typically 204 created in conjunction with an SDP offer/answer exchange [7] during 205 the establishment of a session (see [6]). If used with an offer/ 206 answer exchange, the subscriber SHOULD insert the representation of 207 the local session description in the SUBSCRIBE body. The local 208 session description is the one that was created by the subscriber 209 (e.g. the offer if the subscriber has initiated the offer/answer 210 exchange). 212 The subscriber SHOULD also include a representation of the remote 213 session description in the SUBSCRIBE body. The remote session 214 description is the one the subscriber has received (i.e. the answer 215 if the subscriber has initiated the offer/answer exchange). In some 216 scenarios, the remote session description is not available to the 217 subscriber at the time the subscription to session-specific policies 218 is established. In this case, the initial SUBSCRIBE message SHOULD 219 only contain a representation of the local session description. When 220 the remote description becomes available, the subscriber SHOULD 221 refresh the subscription by sending another SUBSCRIBE request, which 222 then contains the local and the remote session description. The 223 subscriber MAY skip sending the remote session description to the 224 notifier if it has received a NOTIFY with the "local-only" parameter. 225 A notifier will typically include this parameter in a NOTIFY when it 226 has received the local session description and does not need to see 227 the remote session description. 229 3.4. Subscription Duration 231 A subscription to the session-specific policy package is usually 232 established at the beginning of a session and terminated when the 233 corresponding session ends (it may, of course, be terminated 234 earlier). A typical duration of a phone call is a few minutes. 236 Since the duration of a subscription to the session-specific policy 237 package is closely related to the lifetime of the corresponding 238 session, the value for the duration of a subscription is largely 239 irrelevant. However, it SHOULD be longer than the typical duration 240 of a session. The default subscription duration for this event 241 package is set to two hours. 243 3.5. NOTIFY Bodies 245 In this event package, the body of a notification contains the 246 session policy requested by the subscriber. All subscribers and 247 notifiers MUST support the format "application/session-policy+xml" 248 [3] as a format for NOTIFY bodies. 250 The SUBSCRIBE request MAY contain an Accept header field. If no such 251 header field is present, it has a default value of "application/ 252 session-policy+xml". If the header field is present, it MUST include 253 "application/session-policy+xml", and MAY include any other MIME type 254 capable of representing session-specific policies. As defined RFC 255 3265 [4], the body of notifications MUST be in one of the formats 256 defined in the Accept header of the SUBSCRIBE request or in the 257 default format. 259 If the notifier uses the same format in NOTIFY bodies that was used 260 by the subscriber in the SUBSCRIBE body (e.g. "application/ 261 session-policy+xml"), the notifier can expect that the subscriber 262 supports all format extensions that were used in the SUBSCRIBE body. 263 However, the notifier cannot assume that the subscriber supports 264 other extensions beyond that. If the notifier uses other format 265 extensions, it cannot count on the fact that they will be understood 266 by the subscriber. The rationale behind this is that the notifier 267 will often return a modified version of the document that was 268 submitted by the subscriber. 270 If the SUBSCRIBE request contained a representation of the local 271 session description and the subscription was accepted, then the 272 NOTIFY body MUST contain a policy for the local session description. 273 If the SUBSCRIBE request of an accepted subscription contained the 274 local and the remote session description, then the NOTIFY body MUST 275 contain two policies, one for the local and one for the remote 276 session description. 278 3.6. Subscriber generation of SUBSCRIBE requests 280 The subscriber follows the general rules for generating SUBSCRIBE 281 requests defined in [4]. The subscriber SHOULD include enough 282 information in the SUBSCRIBE body to accurately describe the session 283 for which it seeks to receive session-specific policies. It SHOULD 284 use the most recent session description if multiple versions are 285 available. 287 OPEN ISSUE: is there a need to define a basic set of elements a 288 subscriber should try to include (if known/applicable)? 290 A user agent can, of course, change the session description of an 291 ongoing session. A change in the session description will typically 292 affect the policy decisions for this session. A subscriber SHOULD 293 therefore refresh the subscription to session-specific policies every 294 time the session description of a session changes. It does so by 295 sending a SUBSCRIBE request, which contains the details of the 296 updated session descriptions. 298 Session policies can contain sensitive information. Moreover, policy 299 decisions can significantly impact the behavior of a user agent. A 300 user agent should therefore verify the identity of a policy server 301 and make sure that policies have not been altered in transit. All 302 implementations of this package MUST support TLS [2] and the SIPS URI 303 scheme. A subscriber SHOULD use SIPS URIs, if possible, when 304 subscribing to session-specific policies so that policies are 305 transmitted over TLS. If possible, subscribers SHOULD perform server 306 authentication, for example, via TLS or another transport mechanism. 308 3.7. Notifier processing of SUBSCRIBE requests 310 All subscriptions to session-specific policies SHOULD be 311 authenticated and authorized before approval. The notifier SHOULD 312 authenticate the subscriber using any of the techniques available 313 through SIP, including digest, S/MIME, TLS or other transport 314 specific mechanisms. Administrators SHOULD use a SIPS URI as a 315 policy server URI. 317 The authorization policy is at the discretion of the administrator. 318 It is RECOMMENDED that all users are allowed to subscribe to the 319 session-specific policies of their sessions. A subscription to this 320 event package will typically be established by a device that needs to 321 know about the policies for its sessions. However, subscriptions may 322 also be established by applications and automata (e.g. a conference 323 server). In those cases, an authorization policy will typically be 324 provided for these applications. 326 Responding timely to a SUBSCRIBE request is crucial for this event 327 package. A notifier must minimize the time needed for processing 328 SUBSCRIBE requests and generating the initial NOTIFY. This includes 329 minimizing the time needed to generate an initial policy decision. A 330 short response time is in particular important for this event package 331 since it minimizes the delay for fetching policies during an INVITE 332 transaction and therefore reduces call setup time. In addition, 333 subscriptions to session-specific policies can be established while 334 the subscriber is in an INVITE transaction at a point where it has 335 received the 200 OK but before sending the ACK. Delaying the 336 creation of the initial NOTIFY would delay the transmission of the 337 ACK (a more detailed discussion of this scenario can be found in 338 [6]). 340 3.8. Notifier generation of NOTIFY requests 342 A notifier sends a notification in response to SUBSCRIBE requests as 343 defined in RFC 3265 [4]. In addition, a notifier MAY send a 344 notification at any time during the subscription. Typically, it will 345 send one every time the policy decision this subscription is for has 346 changed. When and why a policy decision changes is entirely at the 347 discretion of the administrator. A change in the policy decision may 348 be triggered, for example, by a change in the network status, a 349 change in the services used by the user or by an update of the 350 service level agreement. 352 The policy document in a NOTIFY body MUST represent a complete policy 353 decision. Notifications that contain the deltas to previous policy 354 decisions or partial policy decisions are not supported in this event 355 package. 357 The policy decision to reject a session is expressed by returning an 358 empty NOTIFY body. The notifier MAY terminate the subscription after 359 sending such a notification if it can be expected that this decision 360 will not change in the foreseeable future. The notifier SHOULD keep 361 the subscription alive, if it expects that the session can be 362 admitted at a later point in time. A session is admitted by 363 returning a policy decision document that requires some or no changes 364 to the session. The decision to admit a session and possibly the 365 changes needed are expressed in the format negotiated for the NOTIFY 366 body (e.g. "application/session-policy+xml"). 368 Some session-specific policies do not require the disclosure of the 369 remote session description to the notifier. If a notifier determines 370 that this is the case after receiving a SUBSCRIBE request, it MAY 371 include the "local-only" event parameter in NOTIFY requests. 373 3.9. Subscriber processing of NOTIFY requests 375 A subscriber SHOULD apply the policy decision received in a NOTIFY to 376 the session associated with this subscription. 378 If the subscriber receives a notification with an empty body, the 379 session has been rejected. The subscriber SHOULD NOT attempt to 380 establish this session. However, the subscriber MAY still keep up 381 the subscription to session-specific policies for this session since 382 the policy decision may change and the session may be admitted at a 383 later time. If the notifier has terminated the subscription, the 384 subscriber SHOULD NOT try to re-subscribe for the same session. 386 A subscriber may receive an update to a policy decision for a session 387 that is already established. The subscriber SHOULD apply the new 388 policy decision to this session. It may need to generate a re-INVITE 389 or UPDATE request in this session if the session description has 390 changed or it may need to terminate this session. 392 If the subscriber receives a NOTIFY that contains the "local-only" 393 event parameter, it MAY stop inserting the remote session description 394 in SUBSCRIBE requests within this subscription. It MAY skip 395 refreshing the subscription in order to convey information about the 396 remote session description to the notifier. 398 3.10. Handling of forked requests 400 This event package allows the creation of only one dialog as a result 401 of an initial SUBSCRIBE request. The techniques to achieve this 402 behavior are described in [4]. 404 3.11. Rate of notifications 406 It is anticipated that the rate of policy changes will be very low. 407 In any case, notifications SHOULD NOT be generated at a rate of more 408 than once every five seconds. 410 3.12. State Agents 412 State agents play no role in this package. 414 3.13. Examples 416 The following message flow illustrates how a user agent (Alice's 417 phone) can subscribe to session-specific policies when establishing a 418 call (here to Bob's phone). The flow assumes that the user agent has 419 already received the policy server URI (e.g. through configuration or 420 as described in [6]) and it does not show messages for authentication 421 on transport or SIP level. 423 These call flow examples are informative and not normative. 424 Implementers should consult the main text of this document for exact 425 protocol details. 427 Policy Server Alice Bob 428 | | | 429 |(1) SUBSCRIBE | | 430 |<------------------| | 431 |(2) 200 OK | | 432 |------------------>| | 433 |(3) NOTIFY | | 434 |------------------>| | 435 |(4) 200 OK | | 436 |<------------------| | 437 | |(5) INVITE | 438 | |------------------>| 439 | | | 440 | |(6) 200 OK | 441 | |<------------------| 442 | |(7) ACK | 443 | |------------------>| 444 |(8) SUBSCRIBE | | 445 |<------------------| | 446 |(9) 200 OK | | 447 |------------------>| | 448 |(10) NOTIFY | | 449 |------------------>| | 450 |(11) 200 OK | | 451 |<------------------| | 452 | | | 454 Message Details 455 (1) SUBSCRIBE Alice -> Policy Server 457 SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0 458 Via: SIP/2.0/TLS pc.biloxi.example.com:5061 459 ;branch=z9hG4bK74bf 460 Max-Forwards: 70 461 From: Alice ;tag=8675309 462 To: PS 463 Call-ID: rt4353gs2egg@pc.biloxi.example.com 464 CSeq: 1 SUBSCRIBE 465 Contact: 466 Expires: 7200 467 Event: session-spec-policy 468 Accept: application/session-policy+xml 469 Content-Type: application/session-policy+xml 470 Content-Length: ... 472 [Local session description (offer)] 474 (2) 200 OK Policy Server -> Alice 476 (3) NOTIFY Policy Server -> Alice 478 NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0 479 Via: SIP/2.0/TLS srvr.biloxi.example.com:5061 480 ;branch=z9hG4bK74br 481 Max-Forwards: 70 482 From: PS ;tag=31451098 483 To: Alice ;tag=8675309 484 Call-ID: rt4353gs2egg@pc.biloxi.example.com 485 CSeq: 1 NOTIFY 486 Event: session-spec-policy 487 Subscription-State: active;expires=7200 488 Content-Type: application/session-policy+xml 489 Content-Length: ... 491 [Policy for local session description (offer)] 493 (4) 200 OK Alice -> Policy Server 495 (5) INVITE Alice -> Bob 497 (6) 200 OK Bob -> Alice 499 (7) ACK Alice -> Bob 500 (8) SUBSCRIBE Alice -> Policy Server 502 SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0 503 Via: SIP/2.0/TLS pc.biloxi.example.com:5061 504 ;branch=z9hG4bKna998sl 505 Max-Forwards: 70 506 From: Alice ;tag=8675309 507 To: PS ;tag=31451098 508 Call-ID: rt4353gs2egg@pc.biloxi.example.com 509 CSeq: 2 SUBSCRIBE 510 Expires: 7200 511 Event: session-spec-policy 512 Accept: application/session-policy+xml 513 Content-Type: application/session-policy+xml 514 Content-Length: ... 516 [Local session description (offer)] 517 [Remote session description (answer)] 519 (9) 200 OK Policy Server -> Alice 521 (10) NOTIFY Policy Server -> Alice 523 NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0 524 Via: SIP/2.0/TLS srvr.biloxi.example.com:5061 525 ;branch=z9hG4bKna998sk 526 Max-Forwards: 70 527 From: PS ;tag=31451098 528 To: Alice ;tag=8675309 529 Call-ID: rt4353gs2egg@pc.biloxi.example.com 530 CSeq: 2 NOTIFY 531 Event: session-spec-policy 532 Subscription-State: active;expires=7200 533 Content-Type: application/session-policy+xml 534 Content-Length: ... 536 [Policy for local session description (offer)] 537 [Policy for remote session description (answer)] 539 F6 200 OK Alice -> Policy Server 541 4. Security Considerations 543 Session policies can significantly change the behavior of a user 544 agent and can therefore be used by an attacker to compromise a user 545 agent. For example, session policies can be used to set up a user 546 agent so that it is unable to successfully establish a session (e.g. 547 by setting the available bandwidth to zero). Such a policy can be 548 submitted to the user agent during a session, which will cause the UA 549 to terminate the session. 551 A user agent transmits session information to a policy server. This 552 session information may contain sensitive data the user may not want 553 an eavesdropper or an unauthorized policy server to see. In 554 particular, the session information may contain the encryption keys 555 for media streams. Vice versa, session policies may also contain 556 sensitive information about the network or service level agreements 557 the service provider may not want to disclose to an eavesdropper or 558 an unauthorized user agent. 560 To prevent these attacks, a subscriber using this event package 561 SHOULD authenticate the notifier (i.e. the policy server) before 562 disclosing session information or accepting a session policy. This 563 requires the subscriber to perform server authentication which can be 564 done, for example, via TLS or another transport mechanism. A 565 subscriber SHOULD use SIPS URIs, if possible, when subscribing to 566 session-specific policy events so that policies are transmitted over 567 TLS. 569 Similarly, notifiers SHOULD authenticate subscribers using any of the 570 techniques available through SIP, including digest, S/MIME, TLS or 571 other transport specific mechanisms. Administrators SHOULD use SIPS 572 URIs as policy server URIs. 574 A session description may contain sensitive information a subscriber 575 does not want to share with the notifier. For example, a user agent 576 may not want to share the media encryption keys with the policy 577 server. The subscriber should therefore ensure that it is only 578 sending session information to the notifier that it is willing to 579 disclose. 581 5. IANA Considerations 583 5.1. Event Package Name 585 This specification registers an event package, based on the 586 registration procedures defined in RFC 3265 [2]. The following is 587 the information required for such a registration: 589 Package Name: session-spec-policy 590 Package or Template-Package: This is a package. 592 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 593 with the RFC number of this specification). 595 Person to Contact: Volker Hilt, volkerh@bell-labs.com. 597 Appendix A. Acknowledgements 599 Many thanks to Jonathan Rosenberg for the many discussions and 600 suggestions for this draft. 602 6. References 604 6.1. Normative References 606 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 607 Levels", BCP 14, RFC 2119, March 1997. 609 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 610 RFC 2246, January 1999. 612 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 613 Data Set for Media Policy", 614 draft-ietf-sipping-media-policy-dataset-01 (work in progress), 615 March 2006. 617 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 618 Notification", RFC 3265, June 2002. 620 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 621 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 622 Session Initiation Protocol", RFC 3261, June 2002. 624 6.2. Informative References 626 [6] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for 627 Session Initiation Protocol (SIP) Session Policies", 628 draft-ietf-sipping-session-policy-framework-01 (work in 629 progress), March 2006. 631 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 632 Session Description Protocol (SDP)", RFC 3264, June 2002. 634 Authors' Addresses 636 Volker Hilt 637 Bell Labs/Lucent Technologies 638 101 Crawfords Corner Rd 639 Holmdel, NJ 07733 640 USA 642 Email: volkerh@bell-labs.com 644 Gonzalo Camarillo 645 Ericsson 646 Hirsalantie 11 647 Jorvas 02420 648 Finland 650 Email: Gonzalo.Camarillo@ericsson.com 652 Intellectual Property Statement 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org. 676 Disclaimer of Validity 678 This document and the information contained herein are provided on an 679 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 680 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 681 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 682 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 683 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 684 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 686 Copyright Statement 688 Copyright (C) The Internet Society (2006). This document is subject 689 to the rights, licenses and restrictions contained in BCP 78, and 690 except as set forth therein, the authors retain all their rights. 692 Acknowledgment 694 Funding for the RFC Editor function is currently provided by the 695 Internet Society.