idnits 2.17.1 draft-ietf-rap-session-auth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 2001) is 8198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '9' is defined on line 1038, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-sip-manyfolks-resource-02 == Outdated reference: A later version (-06) exists of draft-ietf-sip-call-auth-02 == Outdated reference: A later version (-05) exists of draft-ietf-rap-rsvp-authsession-01 ** Obsolete normative reference: RFC 2327 (ref. '9') (Obsoleted by RFC 4566) == Outdated reference: A later version (-09) exists of draft-ietf-sip-rfc2543bis-03 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAP Working Group L-N. Hamer 3 Internet Draft B. Gage 4 Document: draft-ietf-rap-session-auth-02.txt Nortel Networks 5 Hugh Shieh 6 AT&T Wireless 8 Category: Informational November 2001 10 Framework for session set-up with media authorization 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet- Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 The distribution of this memo is unlimited. This memo is filed as 31 , and expires June 31, 2002. 32 Please send comments to the authors. 34 Abstract 36 Establishing multimedia streams must take into account requirements 37 for end-to-end QoS, authorization of network resource usage and 38 accurate accounting for resources used. During session set up, 39 policies may be enforced to ensure that the media streams being 40 requested lie within the bounds of the service profile established 41 for the requesting host. Similarly, when a host requests resources 42 to provide a certain QoS for a packet flow, policies may be enforced 43 to ensure that the required resources lie within the bounds of the 44 resource profile established for the requesting host. 46 To prevent fraud and to ensure accurate billing, we describe various 47 scenarios and mechanisms that provide the linkage required to verify 48 that the resources being used to provide a requested QoS are in-line 49 with the media streams requested (and authorized) for the session. 51 Framework for session set-up with media authorization 52 Framework for session set-up with media authorization 54 Contents 56 Status of this Memo................................................1 57 Abstract...........................................................1 58 Contents...........................................................3 59 1. Introduction....................................................4 60 2. Conventions used in this document...............................5 61 3. Definition of terms.............................................6 62 4. The Coupled Model...............................................8 63 4.1 Coupled Model Message Flows..................................8 64 4.2 Coupled Model Authorization Token...........................10 65 4.3 Coupled Model Protocol Impacts..............................10 66 5. The Associated Model <>...............11 67 5.1 Associated Model Message Flows <>..12 68 5.2 Associated Model Authorization Token <>.......13 69 5.3 Associated Model Protocol Impacts <>..........13 70 5.4 Associated Model Network Impacts <>...........14 71 6. The Associated Model <>..............15 72 6.1 Associated Model Message Flows <>.............16 73 6.2 Associated Model Authorization Token <>.......17 74 6.3 Associated Model Protocol Impacts <>..........18 75 7. The Non-Associated Model.......................................19 76 7.1 Non-Associated Model Call Flow..............................19 77 7.2 Non-Associated Model Authorization Token....................21 78 7.3 Non-Associated Model Protocol Impacts.......................21 79 8. Conclusions....................................................22 80 9. Security Considerations........................................23 81 References........................................................23 82 Acknowledgments...................................................24 83 Authors' Addresses................................................24 84 Full Copyright Statement..........................................25 85 Expiration Date...................................................25 86 Framework for session set-up with media authorization 88 1. Introduction 90 Establishing multimedia streams must take into account requirements 91 for end-to-end QoS, authorization of network resource usage and 92 accurate accounting for resources used. During session set up, 93 policies may be enforced to ensure that the media streams being 94 requested lie within the bounds of the service profile established 95 for the requesting host. Similarly, when a host requests resources 96 to provide a certain QoS for a packet flow, policies may be enforced 97 to ensure that the required resources lie within the bounds of the 98 resource profile established for the requesting host. 100 Reference [5] defines a mechanism through which end hosts can use a 101 session control protocol (e.g. SIP [10]) to indicate that QoS 102 requirements must be met in order to successfully set up a session. 103 However, a separate protocol (e.g. RSVP [11]) is used to request the 104 resources required to meet the end-to-end QoS of the media stream. 105 To prevent fraud and to ensure accurate billing, some linkage is 106 required to verify that the resources being used to provide the 107 requested QoS are in-line with the media streams requested (and 108 authorized) for the session. 110 This document describes such a linkage through use of a "token" that 111 provides capabilities similar to that of a gate in [8] and of a 112 ticket in the push model of [2]. The token is generated by a policy 113 server (or a session manager) and is transparently relayed through 114 the end host to the edge router where it is used as part of the 115 policy-controlled flow admission process. 117 In some environments, authorization of media streams can exploit the 118 fact that pre-established relationships exist between elements of 119 the network (e.g. session managers, edge routers, policy servers and 120 end hosts). In other environments, however, such pre-established 121 relationships may not exist either due to the complexity of creating 122 these associations a priori (e.g. in a network with many elements), 123 or due to the different business entities involved (e.g. service 124 provider and access provider), or due to the dynamic nature of these 125 associations (e.g. in a mobile environment). 127 In this document, we describe these various scenarios and the 128 mechanisms used for exchanging information between network elements 129 in order to authorize the use of resources for a service and to co- 130 ordinate actions between the session and resource management 131 entities. Specific extensions to session control protocols (e.g. SIP 132 [6], H.323), to resource reservation protocols (e.g. RSVP [7], 133 YESSIR) and to policy managements protocols (e.g. COPS-SIP [12], 134 COPS-RSVP [4]) required to realize these scenarios and mechanisms 135 are beyond the scope of this document. 137 Framework for session set-up with media authorization 139 For clarity, this document will illustrate the media authorization 140 concepts using SIP for session signalling, RSVP for resource 141 reservation and COPS for interaction with the policy servers. Note, 142 however, that the framework could be applied to a multimedia 143 services scenario using different signalling protocols. 145 2. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 149 this document are to be interpreted as described in RFC-2119 [1]. 151 Framework for session set-up with media authorization 153 3. Definition of terms 155 Figure 1 introduces a generic model for session establishment, QoS 156 and policy enforcement. 158 +-------------------------------------+ +---+ 159 | SCD - Service Control District | | | 160 | +-----------------------+ +--------+| | I | 161 | |Session management | |Policy || | n | 162 | |server | |Server || | t | 163 | | +---------+ +------+ | | +----+||<->| e | 164 | | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r | 165 | | +---------+ +------+ | | +----+|| | - | 166 | +-----------------------+ +--------+| | c | 167 | | | o | 168 +-------------------------------------+ | n | 169 | n | 170 +-------------------------------------+ | e | 171 | RCD - Resource Control District | | c | 172 | | | t | 173 | | | i | 174 | +------------+ +-------------+ | | n | 175 +----------+ | |Edge Router | |Policy Server| | | g | 176 | End | | | | | | | | | 177 | Host | | |+----------+| |+----------+ | | | N | 178 |+--------+| | ||RSVP Agent|| ||PDP | | | | e | 179 ||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t | 180 ||Client || | |+----------+| | | | | w | 181 |+--------+| | || PEP || | | | | o | 182 ||SIP User|| | |+----------+| | | | | r | 183 ||Agent || | +------------+ +-------------+ | | k | 184 |+--------+| | | | | 185 +----------+ +-------------------------------------+ +---+ 187 Figure 1: Generic media authorization network model 189 EH - End Host: The End Host is a device used by a subscriber to 190 access network services. The End Host includes a client for 191 requesting network services (e.g. through SIP) and a client for 192 requesting network resources (e.g. through RSVP). 194 ER - Edge Router: The Edge Router is a network element connecting 195 the end host to the rest of the Resource Control District. The Edge 196 Router contains a PEP to enforce policies related to resource usage 197 in the Resource Control District by the End Host. It also contains a 198 signalling agent (e.g. for RSVP) for handling resource reservation 199 requests from the End Host. 201 Framework for session set-up with media authorization 203 PDP - Policy Decision Point: The PDP is a logical entity located in 204 the Policy Server that is responsible for authorizing or denying 205 access to services and/or resources. 207 PEP - Policy Enforcement Point: The PEP is a logical entity that 208 enforces policy decisions made by the PDP. Note that other PEPs may 209 reside in other network elements not shown in the model of Figure 1, 210 however they will not be discussed in this document. 212 PS - Policy Server: The Policy Server is a network element that 213 includes a PDP. Note that there may be a PS in the Service Control 214 District to control use of services and there may be a separate PS 215 in the Resource Control District to control use of resources along 216 the packet forwarding path. Note also that network topology may 217 require multiple Policy Servers within either district, however they 218 provide consistent policy decisions to offer the appearance of a 219 single PDP in each district. 221 RCD - Resource Control District: The Resource Control District is a 222 logical grouping of elements that provide connectivity along the 223 packet forwarding paths to and from an End Host. The RCD contains ER 224 and PS entities whose responsibilities include management of 225 resources along the packet forwarding paths. 227 SCD - Service Control District: The Service Control District is a 228 logical grouping of elements that offer applications and content to 229 subscribers of their services. The Session Management Server resides 230 in the SCD along with a PS. 232 SMS - Session Management Server: The Session Management Server is a 233 network element providing session management services (e.g. 234 telephony call control). The Session Management Server contains a 235 PEP to enforce policies related to use of services by the End Host. 236 It also contains a signalling agent or proxy (e.g. for SIP) for 237 handling service requests from the End Host. 239 Framework for session set-up with media authorization 241 4. The Coupled Model 243 In some environments, a pre-established trust relationship exists 244 between elements of the network (e.g. session managers, edge 245 routers, policy servers and end hosts). We refer to this as the 246 "coupled model", indicating the tight relationship between entities 247 that is presumed. The key aspects of this scenario are the 248 following: 250 - Policy decisions, including media authorization, are made by a 251 single Policy Server. 253 - The Edge Router, Session Manager and Policy Server involved in 254 establishing the session are known a priori. For example, the End 255 Host may be configured to use a Session Manager associated with 256 the Edge Router to which the EH is connected. 258 - There are pre-defined trust relationships between the SMS and the 259 PS and between the ER and the PS. 261 +--------+ 262 +------+ | | 263 | | 1 +--------------------+ 2 | | 264 | |-------->| Session Management |----->| | 265 | |<--------| Server |<-----| | 266 | | 4 +--------------------+ 3 | | 267 | End | | Policy | 268 | Host | | Server | 269 | | | | 270 | | 5 +--------------------+ 6 | | 271 | |-------->| Edge |----->| | 272 | |<--------| Router |<-----| | 273 | | 8 +--------------------+ 7 | | 274 +------+ | | 275 +--------+ 277 Figure 2: The Coupled Model 279 4.1 Coupled Model Message Flows 281 In this model, it is assumed that there is one Policy Server serving 282 both the Service Control and Resource Control districts and that 283 there are pre-defined trust relationships between the PS and SMS and 284 between the PS and ER. Communications between these entities are 285 then possible as described below. Only the originating side flows 286 are described for simplicity. The same concepts apply to the 287 terminating side. 289 Framework for session set-up with media authorization 291 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 292 the Session Manager indicating, among other things, the media 293 streams to be used in the session. As part of this step, the End 294 Host may authenticate itself to the Session Manager. 296 2. The Session Manager, possibly after waiting for negotiation of 297 the media streams to be completed, sends a policy decision 298 request (e.g. COPS-SIP REQ) to the Policy Server in order to 299 determine if the session set-up request should be allowed to 300 proceed. 302 3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 303 Session Manager, possibly after modifying the parameters of the 304 media to be used. Included in this response is a "token" that can 305 subsequently be used by the Policy Server to identify the session 306 and the media it has authorized. 308 4. The Session Manager sends a response to the End Host (e.g. SIP 309 200 or 183) indicating that session set-up is complete or is 310 progressing. Included in this response is a description of the 311 negotiated media along with the token from the Policy Server. 313 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 314 resources necessary to provide the required QoS for the media 315 stream. Included in this request is the token from the Policy 316 Server provided via the Session Manager. 318 6. The Edge Router intercepts the reservation request and sends a 319 policy decision request (e.g. COPS-RSVP REQ) to the Policy Server 320 in order to determine if the resource reservation request should 321 be allowed to proceed. Included in this request is the token from 322 the Policy Server provided by the End Host. The Policy Server 323 uses this token to correlate the request for resources with the 324 media authorization previously provided to the Session Manager. 326 7. The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 327 Edge Router, possibly after modifying the parameters of the 328 resources to be reserved. 330 8. The Edge Router, possibly after waiting for end-to-end 331 negotiation for resources to be completed, sends a response to 332 the End Host (e.g. RSVP RESV) indicating that resource 333 reservation is complete or is progressing. 335 Framework for session set-up with media authorization 337 4.2 Coupled Model Authorization Token 339 In the Coupled Model, the Policy Server is the only network entity 340 that needs to interpret the contents of the token. Therefore, in 341 this model, the contents of the token are implementation dependent. 342 Since the End Host is assumed to be untrusted, the Policy Server 343 should take measures to ensure that the integrity of the token is 344 preserved in transit; the exact mechanisms to be used are also 345 implementation dependent. 347 4.3 Coupled Model Protocol Impacts 349 The use of a media authorization token in the Coupled Model requires 350 the addition of new fields to several protocols: 352 - Resource reservation protocol. A new protocol field or object 353 must be added to the resource reservation protocol to 354 transparently transport the token from the End Host to the Edge 355 Router. The content and internal structure (if any) of this 356 object should be opaque to the resource reservation protocol. For 357 example, this is achieved in RSVP with the Policy Data object 358 defined in [13]. 360 - Policy management protocol. A new protocol field or object must 361 be added to the policy management protocol to transparently 362 transport the token from the Policy Server to the Session 363 Management Server and from the Edge Router to the Policy Server. 364 The content and internal structure (if any) of this object should 365 be opaque to the policy management protocol. For example, this is 366 achieved in COPS-RSVP with the Policy Data object defined in 367 [13]. 369 - Session management protocol. A new protocol field or object must 370 be added to the session management protocol to transparently 371 transport the media authorization token from the Session 372 Management Server to the End Host. The content and internal 373 structure (if any) of this object should be opaque to the session 374 management protocol. For example, this is achieved in SIP with 375 the proposed header extensions in [6]. 377 Framework for session set-up with media authorization 379 5. The Associated Model <> 381 In this scenario, there are multiple instances of the Session 382 Management Servers, Edge Routers and Policy Servers. This leads to a 383 network of sufficient complexity that it precludes distributing 384 knowledge of network topology to all network entities. The key 385 aspects of this scenario are the following: 387 - Policy decisions, including media authorization, are made by a 388 the same Policy Server for both the Session Manager and the Edge 389 Router. However, the Policy Server may change on per-transaction 390 basis. 392 - The Edge Router, Session Manager and Policy Server involved in 393 establishing the session are not known a priori. For example, the 394 End Host may be dynamically configured to use one of a pool of 395 Session Managers and each of the Session Managers may be 396 statically configured to use one of a pool of Policy Servers. 398 In another example, the End Host may be mobile and continually 399 changing the Edge Router that its point of attachment uses to 400 communicate with the rest of the network. 402 - There are pre-defined trust relationships between the SMS and the 403 PS and between the ER and the PS. 405 +---------------------+ +---------+ 406 | SMS 'n' |<-->| PS 'm' | 407 +---------------------+ +--------+ | 408 +------+ : : : | | | 409 | | 1 +--------------------+ 2 | | | 410 | |-------->| Session Management |----->| | | 411 | |<--------| Server 1 |<-----| | | 412 | | 4 +--------------------+ 3 | | | 413 | End | | Policy | | 414 | Host | +--------------------+ | Server | | 415 | | | ER 'n' | | 1 | | 416 | | 5 +-+------------------+ | | | | 417 | |-------->| Edge |-+ 6 | | | 418 | |<--------| Router |----->| | | 419 | | 8 +--------------------+ 7 | | | 420 +------+ <-----| |-+ 421 +--------+ 423 Figure 3: The Associated Model using One Policy Server 424 Framework for session set-up with media authorization 426 5.1 Associated Model Message Flows <> 428 In this model, it is assumed that a Policy Server can make decisions 429 for both the Service Control and Resource Control districts and that 430 there are pre-defined trust relationships between the PS and SMS and 431 between the PS and ER. Communications between these entities are 432 then possible as described below. Only the originating side flows 433 are described for simplicity. The same concepts apply to the 434 terminating side. 436 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 437 the Session Manager indicating, among other things, the media 438 streams to be used in the session. As part of this step, the End 439 Host may authenticate itself to the Session Manager. 441 2. The Session Manager, possibly after waiting for negotiation of 442 the media streams to be completed, sends a policy decision 443 request (e.g. COPS-SIP REQ) to the Policy Server in order to 444 determine if the session set-up request should be allowed to 445 proceed. 447 3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 448 Session Manager, possibly after modifying the parameters of the 449 media to be used. Included in this response is a "token" that can 450 subsequently be used by the Policy Server to identify the session 451 and the media it has authorized. 453 4. The Session Manager sends a response to the End Host (e.g. SIP 454 200 or 183) indicating that session set-up is complete or is 455 progressing. Included in this response is a description of the 456 negotiated media along with the token from the Policy Server. 458 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 459 resources necessary to provide the required QoS for the media 460 stream. Included in this request is the token from the Policy 461 Server provided via the Session Manager. 463 6. The Edge Router intercepts the reservation request and inspects 464 the token to learn which Policy Server authorized the media. It 465 then sends a policy decision request to that Policy Server in 466 order to determine if the resource reservation request should be 467 allowed to proceed. Included in this request is the token from 468 the Policy Server provided by the End Host. The Policy Server 469 uses this token to correlate the request for resources with the 470 media authorization previously provided to the Session Manager. 472 7. The Policy Server sends a decision to the Edge Router, possibly 473 after modifying the parameters of the resources to be reserved. 475 Framework for session set-up with media authorization 477 8. The Edge Router, possibly after waiting for end-to-end 478 negotiation for resources to be completed, sends a response to 479 the End Host (e.g. RSVP RESV) indicating that resource 480 reservation is complete or is progressing. 482 5.2 Associated Model Authorization Token <> 484 Since the ER does not know which SMS and PS are involved in session 485 establishment, the token must include: 487 - A correlation identifier. This is information that the Policy 488 Server can use to correlate the resource reservation request with 489 the media authorized during session set up. The Policy Server is 490 the only network entity that needs to interpret the contents of 491 the correlation identifier therefore, in this model, the contents 492 of the correlation identifier are implementation dependent. Since 493 the End Host is assumed to be untrusted, the Policy Server should 494 take measures to ensure that the integrity of the correlation 495 identifier is preserved in transit; the exact mechanisms to be 496 used are also implementation dependent. 498 - The identity of the authorizing entity. This information is used 499 by the Edge Router to determine which Policy Server should be 500 used to solicit resource policy decisions. 502 In some environments, an Edge Router may have no means for 503 determining if the identity refers to a legitimate Policy Server 504 within its domain. In order to protect against redirection of 505 authorization requests to a bogus authorizing entity, the token 506 should also include: 508 - An authentication signature. This signature is calculated over 509 all other fields of the token using an agreed mechanism. The Edge 510 Router must be able to verify the signature using credentials of 511 the signer to confirm a trust relationship. The mechanism used by 512 the Edge Router is beyond the scope of this document. 514 The detailed semantics of an example token are defined in [7]. 516 5.3 Associated Model Protocol Impacts <> 518 The use of a media authorization token in this version of the 519 Associated Model requires the addition of new fields to several 520 protocols: 522 - Resource reservation protocol. A new protocol field or object 523 must be added to the resource reservation protocol to 524 transparently transport the token from the End Host to the Edge 525 Framework for session set-up with media authorization 527 Router. The content and internal structure of this object must be 528 specified so that the Edge Router can distinguish between the 529 elements of the token described in Section 5.2. For example, this 530 is achieved in RSVP with the Policy Data object defined in [13]. 532 - Policy management protocol. A new protocol field or object must 533 be added to the policy management protocol to transparently 534 transport the token -- or at least the correlation identifier -- 535 from the Edge Router to the Policy Server. The content and 536 internal structure of this object should be opaque to the policy 537 management protocol. For example, this is achieved in COPS-RSVP 538 with the Policy Data object defined in [13]. 540 - Session management protocol. A new protocol field or object must 541 be added to the session management protocol to transparently 542 transport the media authorization token from the Session 543 Management Server to the End Host. The content and internal 544 structure of this object should be opaque to the session 545 management protocol. For example, this is achieved in SIP with 546 the proposed header extensions in [6]. 548 5.4 Associated Model Network Impacts <> 550 The use of a media authorization token in this version of the 551 Associated Model requires that the Edge Router inspect the token to 552 learn which Policy Server authorized the media. In some 553 environments, it may not be possible for the Edge Router to perform 554 this function; in these cases, an Associated Model using Two Policy 555 Servers (section 6) is required. 557 This version of the Associated Model also requires that the Edge 558 Router interact with multiple Policy Servers. Policy decisions are 559 made by the same Policy Server for both the Session Manager and the 560 Edge Router, however the Policy Server may change on per-transaction 561 basis. Note that COPS does not currently allow PEPs to change PDP on 562 a per-transaction basis. To use this model, a new framework and 563 protocol must be defined for policy decision outsourcing. This model 564 also implies that the Policy Servers are able to interact and/or 565 make decisions for the Edge Router in a consistent manner (e.g. as 566 though there is only a single RCD Policy Server). How this is 567 accomplished is beyond the scope of this document. 569 Framework for session set-up with media authorization 571 6. The Associated Model <> 573 In this scenario, there are multiple instances of the Session 574 Management Servers, Edge Routers and Policy Servers. This leads to a 575 network of sufficient complexity that it precludes distributing 576 knowledge of network topology to all network entities. The key 577 aspects of this scenario are the following: 579 - Policy decisions, including media authorization, are made by 580 Policy Servers. 582 - There is a PS in the Resource Control District that is separate 583 from the PS in the Session Control District. 585 - The Edge Router, Session Manager and Policy Servers involved in 586 establishing the session are not known a priori. For example, the 587 End Host may be dynamically configured to use one of a pool of 588 Session Managers or the End Host may be mobile and continually 589 changing the Edge Router that it uses to communicate with the 590 rest of the network. 592 - There is a pre-defined trust relationship between the SMS and the 593 SCD PS. 595 - There is a pre-defined trust relationship between the ER and the 596 RCD PS. 598 - There is a pre-defined trust relationship between the RCD and SCD 599 Policy Servers. 601 +--------------------+ +--------+ 602 +------+ | SMS �n� | | | 603 | | 1 +-+------------------+ | | SCD | 604 | |-------->| Session Management |-+ 2 | Policy | 605 | |<--------| Server |----->| Server | 606 | | 4 +--------------------+<-----| | 607 | End | 3 +--------+ 608 | | 7 ^ | 609 | Host | +--------------------+ | v 8 610 | | | ER 'n' | +--------+ 611 | | 5 +-+------------------+ | | | 612 | |-------->| Edge |-+ 6 | RCD | 613 | |<--------| Router |----->| Policy | 614 | | 10 +--------------------+<--- -| Server | 615 +------+ 9 | | 616 +--------+ 618 Figure 4: The Associated Model using Two Policy Servers 619 Framework for session set-up with media authorization 621 6.1 Associated Model Message Flows <> 623 In this model, it is assumed that there is one Policy Server for the 624 Service Control District and a different Policy Server for the 625 Resource Control District. There are pre-defined trust relationships 626 between the SCD PS and SMS, between the RCD PS and ER and between 627 the RCD and SCD Policy Servers. Communications between these 628 entities are then possible as described below. Only the originating 629 side flows are described for simplicity. The same concepts apply to 630 the terminating side. 632 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 633 the Session Manager indicating, among other things, the media 634 streams to be used in the session. As part of this step, the End 635 Host may authenticate itself to the Session Manager. 637 2. The Session Manager, possibly after waiting for negotiation of 638 the media streams to be completed, sends a policy decision 639 request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to 640 determine if the session set-up request should be allowed to 641 proceed. 643 3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 644 Session Manager, possibly after modifying the parameters of the 645 media to be used. Included in this response is a "token" that can 646 subsequently be used by the SCD Policy Server to identify the 647 session and the media it has authorized. 649 4. The Session Manager sends a response to the End Host (e.g. SIP 650 200 or 183) indicating that session set-up is complete or is 651 progressing. Included in this response is a description of the 652 negotiated media along with the token from the SCD Policy Server. 654 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 655 resources necessary to provide the required QoS for the media 656 stream. Included in this request is the token from the SCD Policy 657 Server provided via the Session Manager. 659 6. The Edge Router intercepts the reservation request and sends a 660 policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy 661 Server in order to determine if the resource reservation request 662 should be allowed to proceed. Included in this request is the 663 token from the SCD Policy Server provided by the End Host. 665 7. The RCD Policy Server uses this token to learn which SCD Policy 666 Server authorized the media. It then sends an authorization 667 request [3] to that SCD Policy Server in order to determine if 668 the resource reservation request should be allowed to proceed. 669 Included in this request is the token from the SCD Policy Server 670 provided by the End Host. 672 Framework for session set-up with media authorization 674 8. The SCD Policy Server uses this token to correlate the request 675 for resources with the media authorization previously provided to 676 the Session Manager. The SCD Policy Server sends a decision [3] 677 to the RCD Policy Server on whether the requested resources are 678 within the bounds authorized by the SCD Policy Server. 680 9. The RCD Policy Server sends a decision (e.g. COPS-RSVP DEC) to 681 the Edge Router, possibly after modifying the parameters of the 682 resources to be reserved. 684 10. The Edge Router, possibly after waiting for end-to-end 685 negotiation for resources to be completed, sends a response to 686 the End Host (e.g. RSVP RESV) indicating that resource 687 reservation is complete or is progressing 689 6.2 Associated Model Authorization Token <> 691 Since the RCD Policy Server does not know which SMS and SCD PS are 692 involved in session establishment, the token must include: 694 - A correlation identifier. This is information that the SCD Policy 695 Server can use to correlate the resource reservation request with 696 the media authorized during session set up. The SCD Policy Server 697 is the only network entity that needs to interpret the contents 698 of the correlation identifier therefore, in this model, the 699 contents of the correlation identifier are implementation 700 dependent. Since the End Host is assumed to be untrusted, the SCD 701 Policy Server should take measures to ensure that the integrity 702 of the correlation identifier is preserved in transit; the exact 703 mechanisms to be used are also implementation dependent. 705 - The identity of the authorizing entity. This information is used 706 by the RCD Policy Server to determine which SCD Policy Server 707 should be used to verify the contents of the resource reservation 708 request. 710 In some environments, an RCD Policy Server may have no means for 711 determining if the identity refers to a legitimate SCD Policy 712 Server. In order to protect against redirection of authorization 713 requests to a bogus authorizing entity, the token should include: 715 - An authentication signature. This signature is calculated over 716 all other fields of the token using an agreed mechanism. The RCD 717 Policy Server must be able to verify the signature using 718 credentials of the signer to confirm a trust relationship. The 719 mechanism used by the RCD Policy Server is beyond the scope of 720 this document. 722 Framework for session set-up with media authorization 724 Note that the information in this token is the same as that in 725 Section 5.2 for the "One Policy Server" scenario. 727 The detailed semantics of an example token are defined in [7]. 729 6.3 Associated Model Protocol Impacts <> 731 The use of a media authorization token in this version of the 732 Associated Model requires the addition of new fields to several 733 protocols: 735 - Resource reservation protocol. A new protocol field or object 736 must be added to the resource reservation protocol to 737 transparently transport the token from the End Host to the Edge 738 Router. The content and internal structure of this object should 739 be opaque to the resource reservation protocol. For example, this 740 is achieved in RSVP with the Policy Data object defined in [13]. 742 - Policy management protocol. A new protocol field or object must 743 be added to the policy management protocol to transport the token 744 from the SCD Policy Server to the Session Management Server and 745 from the Edge Router to the RCD Policy Server. The content and 746 internal structure of this object must be specified so that the 747 Policy Servers can distinguish between the elements of the token 748 described in Section 6.2. For example, this is achieved in COPS- 749 RSVP with the Policy Data object defined in [13]. 751 - Session management protocol. A new protocol field or object must 752 be added to the session management protocol to transparently 753 transport the media authorization token from the Session 754 Management Server to the End Host. The content and internal 755 structure of this object should be opaque to the session 756 management protocol. For example, this is achieved in SIP with 757 the proposed header extensions in [6]. 759 Note that these impacts are the same as those discussed in Section 760 5.3 for the "One Policy Server" scenario. However the use of two 761 Policy Servers has one additional impact: 763 - Authorization protocol. A new protocol field or object must be 764 added to the authorization protocol to transport the token from 765 the RCD Policy Server to the SCD Policy Server. The content and 766 internal structure of this object must be specified so that the 767 Policy Servers can distinguish between the elements of the token 768 described in Section 6.2. 770 Framework for session set-up with media authorization 772 7. The Non-Associated Model 774 In this scenario, the Session Management Servers and Edge Routers 775 are associated with different Policy Servers, the network entities 776 do not have a priori knowledge of the topology of the network and 777 there are no pre-established trust relationships between entities in 778 the Resource Control District and entities in the Service Control 779 District. The keys aspects of this scenario are the following: 781 - Policy decisions, including media authorization, are made by 782 Policy Servers. 784 - The PS in the Resource Control District is separate from the PS 785 in the Session Control District. 787 - There is a pre-defined trust relationship between the SMS and the 788 SCD PS. 790 - There is a pre-defined trust relationship between the ER and the 791 RCD PS. 793 - There are no pre-defined trust relationships between the ER and 794 SMS or between the RCD and SCD Policy Servers. 796 +--------+ 797 +------+ | | 798 | | 1 +--------------------+ 2 | SCD | 799 | |-------->| Session Management |----->| Policy | 800 | |<--------| Server |<-----| Server | 801 | | 4 +--------------------+ 3 | | 802 | End | +--------+ 803 | Host | 804 | | +--------+ 805 | | 5 +--------------------+ 6 | | 806 | |-------->| Edge |----->| RCD | 807 | |<--------| Router |<-----| Policy | 808 | | 8 +--------------------+ 7 | Server | 809 +------+ | | 810 +--------+ 812 Figure 5: The Non-Associated Model 814 7.1 Non-Associated Model Call Flow 816 In this model it is assumed that the policy servers make independent 817 decisions for their respective districts, obviating the need for 818 information exchange between policy servers. This model also enables 819 Framework for session set-up with media authorization 821 session authorization when communication between policy servers is 822 not possible for various reasons. It may also be used as a means to 823 speed up session setup and still ensure proper authorization is 824 performed. 826 This model does not preclude the possibility that the policy servers 827 may communicate at other times for other purposes (e.g. exchange of 828 accounting information). 830 Communications between network entities in this model is described 831 below. Only the originating side flows are described for simplicity. 832 The same concepts apply to the terminating side. 834 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 835 the Session Manager indicating, among other things, the media 836 streams to be used in the session. As part of this step, the End 837 Host may authenticate itself to the Session Manager. 839 2. The Session Manager, possibly after waiting for negotiation of 840 the media streams to be completed, sends a policy decision 841 request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to 842 determine if the session set-up request should be allowed to 843 proceed. 845 3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 846 Session Manager, possibly after modifying the parameters of the 847 media to be used. Included in this response is a "token" that can 848 subsequently be used by the RCD Policy Server to determine what 849 media has been authorized. 851 4. The Session Manager sends a response to the End Host (e.g. SIP 852 200 or 183) indicating that session set-up is complete or is 853 progressing. Included in this response is a description of the 854 negotiated media along with the token from the SCD Policy Server. 856 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 857 resources necessary to provide the required QoS for the media 858 stream. Included in this request is the token from the SCD Policy 859 Server provided via the Session Manager. 861 6. The Edge Router intercepts the reservation request and sends a 862 policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy 863 Server in order to determine if the resource reservation request 864 should be allowed to proceed. Included in this request is the 865 token from the SCD Policy Server provided by the End Host. 867 7. The RCD Policy Server uses this token to extract information 868 about the media that was authorized by the SCD Policy Server. The 869 RCD Policy Server uses this information in making its decision on 870 whether the resource reservation should be allowed to proceed. 872 Framework for session set-up with media authorization 874 The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 875 Edge Router, possibly after modifying the parameters of the 876 resources to be reserved. 878 8. The Edge Router, possibly after waiting for end-to-end 879 negotiation for resources to be completed, sends a response to 880 the End Host (e.g. RSVP RESV) indicating that resource 881 reservation is complete or is progressing 883 7.2 Non-Associated Model Authorization Token 885 In this model, the token must contain sufficient information to 886 allow the RCD Policy Server to make resource policy decisions 887 autonomously from the SCD Policy Server. The token is created using 888 information about the session received by the SMS. The information 889 in the token must include: 891 - Calling party IP address and port number (e.g. from SDP "c=" 892 parameter). 894 - Called party IP address and port number (e.g. from SDP "c=" 895 parameter). 897 - The characteristics of (each of) the media stream(s) authorized 898 for this session (e.g. codecs, maximum bandwidth from SDP "m=" 899 and/or "b=" parameters). 901 - The lifetime of (each of) the media stream(s) (e.g. from SDP "t=" 902 parameter). 904 - The authorization lifetime (e.g. the token should be valid for 905 only a few seconds after the start time of the session). 907 - The identity of the authorizing entity to allow for validation of 908 the token. 910 - An authentication signature used to prevent tampering with the 911 token and to provide the credentials of the authorizing entity. 912 This signature is calculated over all other fields of the token 913 using an agreed mechanism. The RCD Policy Server must be able to 914 verify the signature using credentials of the signer to confirm a 915 trust relationship. The mechanism used by the RCD Policy Server 916 is beyond the scope of this document. 918 The detailed semantics of the token are defined in [7]. 920 7.3 Non-Associated Model Protocol Impacts 921 Framework for session set-up with media authorization 923 The use of a media authorization token in the Non-Associated Model 924 requires the addition of new fields to several protocols: 926 - Resource reservation protocol. A new protocol field or object 927 must be added to the resource reservation protocol to 928 transparently transport the token from the End Host to the Edge 929 Router. The content and internal structure of this object should 930 be opaque to the resource reservation protocol. For example, this 931 is achieved in RSVP with the Policy Data object defined in [13]. 933 - Policy management protocol. A new protocol field or object must 934 be added to the policy management protocol to transport the token 935 from the SCD Policy Server to the Session Management Server and 936 from the Edge Router to the RCD Policy Server. The content and 937 internal structure of this object must be specified so that the 938 Policy Servers can distinguish between the elements of the token 939 described in Section 7.2. For example, this is achieved in COPS- 940 RSVP with the Policy Data object defined in [13]. 942 - Session management protocol. A new protocol field or object must 943 be added to the session management protocol to transparently 944 transport the media authorization token from the Session 945 Management Server to the End Host. The content and internal 946 structure of this object should be opaque to the session 947 management protocol. For example, this is achieved in SIP with 948 the proposed header extensions in [6]. 950 8. Conclusions 952 In this document we have defined three models for authorizing media 953 during session establishment: 955 - The Coupled Model which assumes a priori knowledge of network 956 topology and where pre-established trust relationships exist 957 between network entities. 959 - The Associated Model where there are common or trusted policy 960 servers but knowledge of the network topology is not known a 961 priori. 963 - The Non-Associated Model where knowledge of the network topology 964 is not known a priori, where there are different policy servers 965 involved and where a trust relationship does not exist between 966 the policy servers. 968 The Associated Model is applicable to environments where the network 969 elements involved in establishing a session have a pre-determined 970 trust relationship but where their identities must be determined 971 dynamically during session set up. The Non-Associated Model is 972 Framework for session set-up with media authorization 974 applicable to environments where there is a complex network topology 975 and/or where trust relationships between domains do not exist (e.g. 976 when they are different business entities). 978 In any given network, one or more of these models may be applicable. 979 Indeed, the model to be used may be chosen dynamically during 980 session establishment based on knowledge of the end points involved 981 in the call. In all cases, however, there is no need for the End 982 Host, the Edge Router or the Session Management Server to understand 983 or interpret the authorization token - to them it is an opaque 984 protocol element that is simply copied from one container protocol 985 to another. 987 Finally, the framework defined in this document is extensible to any 988 kind of session management protocol coupled to any one of a number 989 of resource reservation and/or policy management protocols. 991 9. Security Considerations 993 The purpose of this draft is to describe a mechanism for media 994 authorization to prevent theft of service. It does not cover other 995 possible security breaches such as IP spoofing. 997 This draft assumes that trust relationships exist between various 998 network entities, as described in each of the models. The means for 999 establishing these relationships are beyond the scope of this 1000 document. 1002 For the authorization token to be effective, its integrity must be 1003 guaranteed as it passes through untrusted network entities such as 1004 the End Host. This can be achieved by using digital signatures. 1006 References 1008 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 1009 BCP 9, RFC 2026, October 1996. 1011 [2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, 1012 August 2000 1014 [3] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August 1015 2000 1017 [4] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January 1018 2000. 1020 [5] W.Marshall et al. "Integration of Resource Management and SIP", 1021 Internet-Draft, draft-ietf-sip-manyfolks-resource-02, August 1022 2001, Work in progress. 1024 Framework for session set-up with media authorization 1026 [6] W. Marshall et al., "SIP Extensions for Media Authorization", 1027 Internet-Draft, draft-ietf-sip-call-auth-02.txt, August 2001, 1028 Work in progress. 1030 [7] L. Hamer et al. "Session Authorization for RSVP", Internet- 1031 Draft, draft-ietf-rap-rsvp-authsession-01.txt, November 2001, 1032 Work in progress. 1034 [8] "PacketCable Dynamic Quality of Service Specification", 1035 CableLabs, December 1999. 1036 http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf 1038 [9] M. Handley and V. Jacobson, "SDP: session description 1039 protocol," RFC 2327, Apr.1998. 1041 [10] Handley, Schulzrinne, Schooler & Rosenberg, Internet-Draft, 1042 "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis- 1043 03.txt, May 2001, Work in progress. 1045 [11] R. Braden et al.,"Resource ReSerVation protocol (RSVP) -- 1046 version 1 functional specification," RFC 2205, Sept.1997. 1048 [12] G. Gross et al., "COPS usage for SIP", Internet-Draft, draft- 1049 gross-cops-sip-01.txt, April 2001, Work in progress. 1051 [13] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, 1052 January 2000. 1054 Acknowledgments 1056 The authors would like to thank to following people for their useful 1057 comments and suggestions related to this draft: Kwok Ho Chan, Doug 1058 Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, 1059 Francois Audet, Bill Marshall, Diana Rawlins and many others. 1061 Authors' Addresses 1063 Louis-Nicolas Hamer 1064 Nortel Networks 1065 Ottawa, ON 1066 CANADA 1067 Email: nhamer@nortelnetworks.com 1069 Bill Gage 1070 Nortel Networks 1071 Ottawa, ON 1072 CANADA 1073 Email: gageb@nortelnetworks.com 1074 Framework for session set-up with media authorization 1076 Hugh Shieh 1077 AT&T Wireless 1078 Redmond, WA 1079 USA 1080 Email: hugh.shieh@attws.com 1082 Full Copyright Statement 1084 Copyright (C) The Internet Society (2001). All Rights Reserved. This 1085 document and translations of it may be copied and furnished to 1086 others, and derivative works that comment on or otherwise explain it 1087 or assist in its implementation may be prepared, copied, published 1088 and distributed, in whole or in part, without restriction of any 1089 kind, provided that the above copyright notice and this paragraph 1090 are included on all such copies and derivative works. However, this 1091 document itself may not be modified in any way, such as by removing 1092 the copyright notice or references to the Internet Society or other 1093 Internet organizations, except as needed for the purpose of 1094 developing Internet standards in which case the procedures for 1095 copyrights defined in the Internet Standards process must be 1096 followed, or as required to translate it into. 1098 Expiration Date 1100 This memo is filed as , and 1101 expires June 31, 2002.