idnits 2.17.1 draft-ietf-rap-session-auth-03.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 61 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 (February 2002) is 8106 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '4' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1030, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-rap-rsvp-authsession-02 ** Obsolete normative reference: RFC 2327 (ref. '8') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2543 (ref. '9') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 6 errors (**), 0 flaws (~~), 7 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-03.txt Nortel Networks 6 Hugh Shieh 7 AT&T Wireless 9 Category: Informational February 2002 11 Framework for session set-up with media authorization 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 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. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet- Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 The distribution of this memo is unlimited. This memo is filed as 32 , and expires August 31, 2002. 33 Please send comments to the authors. 35 Abstract 37 Establishing multimedia streams must take into account requirements 38 for end-to-end QoS, authorization of network resource usage and 39 accurate accounting for resources used. During session set up, 40 policies may be enforced to ensure that the media streams being 41 requested lie within the bounds of the service profile established 42 for the requesting host. Similarly, when a host requests resources 43 to provide a certain QoS for a packet flow, policies may be enforced 44 to ensure that the required resources lie within the bounds of the 45 resource profile established for the requesting host. 47 To prevent fraud and to ensure accurate billing, we describe various 48 scenarios and mechanisms that provide the linkage required to verify 49 that the resources being used to provide a requested QoS are in-line 50 with the media streams requested (and authorized) for the session. 52 Framework for session set-up with media authorization 53 Framework for session set-up with media authorization 55 Contents 57 Status of this Memo................................................1 58 Abstract...........................................................1 59 Contents...........................................................3 60 1. Introduction....................................................4 61 2. Conventions used in this document...............................5 62 3. Definition of terms.............................................6 63 4. The Coupled Model...............................................8 64 4.1 Coupled Model Message Flows..................................8 65 4.2 Coupled Model Authorization Token...........................10 66 4.3 Coupled Model Protocol Impacts..............................10 67 5. The Associated Model <>...............11 68 5.1 Associated Model Message Flows <>..12 69 5.2 Associated Model Authorization Token <>.......13 70 5.3 Associated Model Protocol Impacts <>..........13 71 5.4 Associated Model Network Impacts <>...........14 72 6. The Associated Model <>..............15 73 6.1 Associated Model Message Flows <>.............16 74 6.2 Associated Model Authorization Token <>.......17 75 6.3 Associated Model Protocol Impacts <>..........18 76 7. The Non-Associated Model.......................................19 77 7.1 Non-Associated Model Call Flow..............................19 78 7.2 Non-Associated Model Authorization Token....................21 79 7.3 Non-Associated Model Protocol Impacts.......................21 80 8. Conclusions....................................................22 81 9. Security Considerations........................................23 82 References........................................................23 83 Acknowledgments...................................................24 84 Authors' Addresses................................................24 85 Full Copyright Statement..........................................25 86 Expiration Date...................................................25 87 Framework for session set-up with media authorization 89 1. Introduction 91 Establishing multimedia streams must take into account requirements 92 for end-to-end QoS, authorization of network resource usage and 93 accurate accounting for resources used. During session set up, 94 policies may be enforced to ensure that the media streams being 95 requested lie within the bounds of the service profile established 96 for the requesting host. Similarly, when a host requests resources 97 to provide a certain QoS for a packet flow, policies may be enforced 98 to ensure that the required resources lie within the bounds of the 99 resource profile established for the requesting host. 101 Mechanisms have been defined through which end hosts can use a 102 session control protocol (e.g. SIP [9]) to indicate that QoS 103 requirements must be met in order to successfully set up a session. 104 However, a separate protocol (e.g. RSVP [10]) is used to request the 105 resources required to meet the end-to-end QoS of the media stream. 106 To prevent fraud and to ensure accurate billing, some linkage is 107 required to verify that the resources being used to provide the 108 requested QoS are in-line with the media streams requested (and 109 authorized) for the session. 111 This document describes such a linkage through use of a "token" that 112 provides capabilities similar to that of a gate in [7] and of a 113 ticket in the push model of [2]. The token is generated by a policy 114 server (or a session manager) and is transparently relayed through 115 the end host to the edge router where it is used as part of the 116 policy-controlled flow admission process. 118 In some environments, authorization of media streams can exploit the 119 fact that pre-established relationships exist between elements of 120 the network (e.g. session managers, edge routers, policy servers and 121 end hosts). In other environments, however, such pre-established 122 relationships may not exist either due to the complexity of creating 123 these associations a priori (e.g. in a network with many elements), 124 or due to the different business entities involved (e.g. service 125 provider and access provider), or due to the dynamic nature of these 126 associations (e.g. in a mobile environment). 128 In this document, we describe these various scenarios and the 129 mechanisms used for exchanging information between network elements 130 in order to authorize the use of resources for a service and to co- 131 ordinate actions between the session and resource management 132 entities. Specific extensions to session control protocols (e.g. SIP 133 [9], H.323), to resource reservation protocols (e.g. RSVP [6], 134 YESSIR) and to policy managements protocols (e.g. COPS-PR [12], 135 COPS-RSVP [5]) required to realize these scenarios and mechanisms 136 are beyond the scope of this document. 138 Framework for session set-up with media authorization 140 For clarity, this document will illustrate the media authorization 141 concepts using SIP for session signalling, RSVP for resource 142 reservation and COPS for interaction with the policy servers. Note, 143 however, that the framework could be applied to a multimedia 144 services scenario using different signalling protocols. 146 2. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 150 this document are to be interpreted as described in RFC-2119 [1]. 152 Framework for session set-up with media authorization 154 3. Definition of terms 156 Figure 1 introduces a generic model for session establishment, QoS 157 and policy enforcement. 159 +-------------------------------------+ +---+ 160 | SCD - Service Control District | | | 161 | +-----------------------+ +--------+| | I | 162 | |Session management | |Policy || | n | 163 | |server | |Server || | t | 164 | | +---------+ +------+ | | +----+||<->| e | 165 | | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r | 166 | | +---------+ +------+ | | +----+|| | - | 167 | +-----------------------+ +--------+| | c | 168 | | | o | 169 +-------------------------------------+ | n | 170 | n | 171 +-------------------------------------+ | e | 172 | RCD - Resource Control District | | c | 173 | | | t | 174 | | | i | 175 | +------------+ +-------------+ | | n | 176 +----------+ | |Edge Router | |Policy Server| | | g | 177 | End | | | | | | | | | 178 | Host | | |+----------+| |+----------+ | | | N | 179 |+--------+| | ||RSVP Agent|| ||PDP | | | | e | 180 ||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t | 181 ||Client || | |+----------+| | | | | w | 182 |+--------+| | || PEP || | | | | o | 183 ||SIP User|| | |+----------+| | | | | r | 184 ||Agent || | +------------+ +-------------+ | | k | 185 |+--------+| | | | | 186 +----------+ +-------------------------------------+ +---+ 188 Figure 1: Generic media authorization network model 190 EH - End Host: The End Host is a device used by a subscriber to 191 access network services. The End Host includes a client for 192 requesting network services (e.g. through SIP) and a client for 193 requesting network resources (e.g. through RSVP). 195 ER - Edge Router: The Edge Router is a network element connecting 196 the end host to the rest of the Resource Control District. The Edge 197 Router contains a PEP to enforce policies related to resource usage 198 in the Resource Control District by the End Host. It also contains a 199 signalling agent (e.g. for RSVP) for handling resource reservation 200 requests from the End Host. 202 Framework for session set-up with media authorization 204 PDP - Policy Decision Point: The PDP is a logical entity located in 205 the Policy Server that is responsible for authorizing or denying 206 access to services and/or resources. 208 PEP - Policy Enforcement Point: The PEP is a logical entity that 209 enforces policy decisions made by the PDP. Note that other PEPs may 210 reside in other network elements not shown in the model of Figure 1, 211 however they will not be discussed in this document. 213 PS - Policy Server: The Policy Server is a network element that 214 includes a PDP. Note that there may be a PS in the Service Control 215 District to control use of services and there may be a separate PS 216 in the Resource Control District to control use of resources along 217 the packet forwarding path. Note also that network topology may 218 require multiple Policy Servers within either district, however they 219 provide consistent policy decisions to offer the appearance of a 220 single PDP in each district. 222 RCD - Resource Control District: The Resource Control District is a 223 logical grouping of elements that provide connectivity along the 224 packet forwarding paths to and from an End Host. The RCD contains ER 225 and PS entities whose responsibilities include management of 226 resources along the packet forwarding paths. 228 SCD - Service Control District: The Service Control District is a 229 logical grouping of elements that offer applications and content to 230 subscribers of their services. The Session Management Server resides 231 in the SCD along with a PS. 233 SMS - Session Management Server: The Session Management Server is a 234 network element providing session management services (e.g. 235 telephony call control). The Session Management Server contains a 236 PEP to enforce policies related to use of services by the End Host. 237 It also contains a signalling agent or proxy (e.g. for SIP) for 238 handling service requests from the End Host. 240 Framework for session set-up with media authorization 242 4. The Coupled Model 244 In some environments, a pre-established trust relationship exists 245 between elements of the network (e.g. session managers, edge 246 routers, policy servers and end hosts). We refer to this as the 247 "coupled model", indicating the tight relationship between entities 248 that is presumed. The key aspects of this scenario are the 249 following: 251 - Policy decisions, including media authorization, are made by a 252 single Policy Server. 254 - The Edge Router, Session Manager and Policy Server involved in 255 establishing the session are known a priori. For example, the End 256 Host may be configured to use a Session Manager associated with 257 the Edge Router to which the EH is connected. 259 - There are pre-defined trust relationships between the SMS and the 260 PS and between the ER and the PS. 262 +--------+ 263 +------+ | | 264 | | 1 +--------------------+ 2 | | 265 | |-------->| Session Management |----->| | 266 | |<--------| Server |<-----| | 267 | | 4 +--------------------+ 3 | | 268 | End | | Policy | 269 | Host | | Server | 270 | | | | 271 | | 5 +--------------------+ 6 | | 272 | |-------->| Edge |----->| | 273 | |<--------| Router |<-----| | 274 | | 8 +--------------------+ 7 | | 275 +------+ | | 276 +--------+ 278 Figure 2: The Coupled Model 280 4.1 Coupled Model Message Flows 282 In this model, it is assumed that there is one Policy Server serving 283 both the Service Control and Resource Control districts and that 284 there are pre-defined trust relationships between the PS and SMS and 285 between the PS and ER. Communications between these entities are 286 then possible as described below. Only the originating side flows 287 are described for simplicity. The same concepts apply to the 288 terminating side. 290 Framework for session set-up with media authorization 292 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 293 the Session Manager indicating, among other things, the media 294 streams to be used in the session. As part of this step, the End 295 Host may authenticate itself to the Session Manager. 297 2. The Session Manager, possibly after waiting for negotiation of 298 the media streams to be completed, sends a policy decision 299 request (e.g. COPS REQ) to the Policy Server in order to 300 determine if the session set-up request should be allowed to 301 proceed. 303 3. The Policy Server sends a decision (e.g. COPS DEC) to the Session 304 Manager, possibly after modifying the parameters of the media to 305 be used. Included in this response is a "token" that can 306 subsequently be used by the Policy Server to identify the session 307 and the media it has authorized. 309 4. The Session Manager sends a response to the End Host (e.g. SIP 310 200 or 183) indicating that session set-up is complete or is 311 progressing. Included in this response is a description of the 312 negotiated media along with the token from the Policy Server. 314 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 315 resources necessary to provide the required QoS for the media 316 stream. Included in this request is the token from the Policy 317 Server provided via the Session Manager. 319 6. The Edge Router intercepts the reservation request and sends a 320 policy decision request (e.g. COPS REQ) to the Policy Server in 321 order to determine if the resource reservation request should be 322 allowed to proceed. Included in this request is the token from 323 the Policy Server provided by the End Host. The Policy Server 324 uses this token to correlate the request for resources with the 325 media authorization previously provided to the Session Manager. 327 7. The Policy Server sends a decision (e.g. COPS DEC) to the Edge 328 Router, possibly after modifying the parameters of the resources 329 to be reserved. 331 8. The Edge Router, possibly after waiting for end-to-end 332 negotiation for resources to be completed, sends a response to 333 the End Host (e.g. RSVP RESV) indicating that resource 334 reservation is complete or is progressing. 336 Framework for session set-up with media authorization 338 4.2 Coupled Model Authorization Token 340 In the Coupled Model, the Policy Server is the only network entity 341 that needs to interpret the contents of the token. Therefore, in 342 this model, the contents of the token are implementation dependent. 343 Since the End Host is assumed to be untrusted, the Policy Server 344 should take measures to ensure that the integrity of the token is 345 preserved in transit; the exact mechanisms to be used are also 346 implementation dependent. 348 4.3 Coupled Model Protocol Impacts 350 The use of a media authorization token in the Coupled Model requires 351 the addition of new fields to several protocols: 353 - Resource reservation protocol. A new protocol field or object 354 must be added to the resource reservation protocol to 355 transparently transport the token from the End Host to the Edge 356 Router. The content and internal structure (if any) of this 357 object should be opaque to the resource reservation protocol. For 358 example, this is achieved in RSVP with the Policy Data object 359 defined in [11]. 361 - Policy management protocol. A new protocol field or object must 362 be added to the policy management protocol to transparently 363 transport the token from the Policy Server to the Session 364 Management Server and from the Edge Router to the Policy Server. 365 The content and internal structure (if any) of this object should 366 be opaque to the policy management protocol. For example, this is 367 achieved in COPS-RSVP with the Policy Data object defined in 368 [11]. 370 - Session management protocol. A new protocol field or object must 371 be added to the session management protocol to transparently 372 transport the media authorization token from the Session 373 Management Server to the End Host. The content and internal 374 structure (if any) of this object should be opaque to the session 375 management protocol. 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 the 388 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 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 DEC) to the Session 448 Manager, possibly after modifying the parameters of the media to 449 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 [6]. 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 [11]. 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 [11]. 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. 547 5.4 Associated Model Network Impacts <> 549 The use of a media authorization token in this version of the 550 Associated Model requires that the Edge Router inspect the token to 551 learn which Policy Server authorized the media. In some 552 environments, it may not be possible for the Edge Router to perform 553 this function; in these cases, an Associated Model using Two Policy 554 Servers (section 6) is required. 556 This version of the Associated Model also requires that the Edge 557 Router interact with multiple Policy Servers. Policy decisions are 558 made by the same Policy Server for both the Session Manager and the 559 Edge Router, however the Policy Server may change on per-transaction 560 basis. Note that COPS does not currently allow PEPs to change PDP on 561 a per-transaction basis. To use this model, a new framework and 562 protocol must be defined for policy decision outsourcing. This model 563 also implies that the Policy Servers are able to interact and/or 564 make decisions for the Edge Router in a consistent manner (e.g. as 565 though there is only a single RCD Policy Server). How this is 566 accomplished is beyond the scope of this document. 568 Framework for session set-up with media authorization 570 6. The Associated Model <> 572 In this scenario, there are multiple instances of the Session 573 Management Servers, Edge Routers and Policy Servers. This leads to a 574 network of sufficient complexity that it precludes distributing 575 knowledge of network topology to all network entities. The key 576 aspects of this scenario are the following: 578 - Policy decisions, including media authorization, are made by 579 Policy Servers. 581 - There is a PS in the Resource Control District that is separate 582 from the PS in the Session Control District. 584 - The Edge Router, Session Manager and Policy Servers involved in 585 establishing the session are not known a priori. For example, the 586 End Host may be dynamically configured to use one of a pool of 587 Session Managers or the End Host may be mobile and continually 588 changing the Edge Router that it uses to communicate with the 589 rest of the network. 591 - There is a pre-defined trust relationship between the SMS and the 592 SCD PS. 594 - There is a pre-defined trust relationship between the ER and the 595 RCD PS. 597 - There is a pre-defined trust relationship between the RCD and SCD 598 Policy Servers. 600 +--------------------+ +--------+ 601 +------+ | SMS �n� | | | 602 | | 1 +-+------------------+ | | SCD | 603 | |-------->| Session Management |-+ 2 | Policy | 604 | |<--------| Server |----->| Server | 605 | | 4 +--------------------+<-----| | 606 | End | 3 +--------+ 607 | | 7 ^ | 608 | Host | +--------------------+ | v 8 609 | | | ER 'n' | +--------+ 610 | | 5 +-+------------------+ | | | 611 | |-------->| Edge |-+ 6 | RCD | 612 | |<--------| Router |----->| Policy | 613 | | 10 +--------------------+<--- -| Server | 614 +------+ 9 | | 615 +--------+ 617 Figure 4: The Associated Model using Two Policy Servers 618 Framework for session set-up with media authorization 620 6.1 Associated Model Message Flows <> 622 In this model, it is assumed that there is one Policy Server for the 623 Service Control District and a different Policy Server for the 624 Resource Control District. There are pre-defined trust relationships 625 between the SCD PS and SMS, between the RCD PS and ER and between 626 the RCD and SCD Policy Servers. Communications between these 627 entities are then possible as described below. Only the originating 628 side flows are described for simplicity. The same concepts apply to 629 the terminating side. 631 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 632 the Session Manager indicating, among other things, the media 633 streams to be used in the session. As part of this step, the End 634 Host may authenticate itself to the Session Manager. 636 2. The Session Manager, possibly after waiting for negotiation of 637 the media streams to be completed, sends a policy decision 638 request (e.g. COPS REQ) to the SCD Policy Server in order to 639 determine if the session set-up request should be allowed to 640 proceed. 642 3. The SCD Policy Server sends a decision (e.g. COPS DEC) to the 643 Session Manager, possibly after modifying the parameters of the 644 media to be used. Included in this response is a "token" that can 645 subsequently be used by the SCD Policy Server to identify the 646 session and the media it has authorized. 648 4. The Session Manager sends a response to the End Host (e.g. SIP 649 200 or 183) indicating that session set-up is complete or is 650 progressing. Included in this response is a description of the 651 negotiated media along with the token from the SCD Policy Server. 653 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 654 resources necessary to provide the required QoS for the media 655 stream. Included in this request is the token from the SCD Policy 656 Server provided via the Session Manager. 658 6. The Edge Router intercepts the reservation request and sends a 659 policy decision request (e.g. COPS REQ) to the RCD Policy Server 660 in order to determine if the resource reservation request should 661 be allowed to proceed. Included in this request is the token from 662 the SCD Policy Server provided by the End Host. 664 7. The RCD Policy Server uses this token to learn which SCD Policy 665 Server authorized the media. It then sends an authorization 666 request [3] to that SCD Policy Server in order to determine if 667 the resource reservation request should be allowed to proceed. 668 Included in this request is the token from the SCD Policy Server 669 provided by the End Host. 671 Framework for session set-up with media authorization 673 8. The SCD Policy Server uses this token to correlate the request 674 for resources with the media authorization previously provided to 675 the Session Manager. The SCD Policy Server sends a decision [3] 676 to the RCD Policy Server on whether the requested resources are 677 within the bounds authorized by the SCD Policy Server. 679 9. The RCD Policy Server sends a decision (e.g. COPS DEC) to the 680 Edge Router, possibly after modifying the parameters of the 681 resources to be reserved. 683 10. The Edge Router, possibly after waiting for end-to-end 684 negotiation for resources to be completed, sends a response to 685 the End Host (e.g. RSVP RESV) indicating that resource 686 reservation is complete or is progressing 688 6.2 Associated Model Authorization Token <> 690 Since the RCD Policy Server does not know which SMS and SCD PS are 691 involved in session establishment, the token must include: 693 - A correlation identifier. This is information that the SCD Policy 694 Server can use to correlate the resource reservation request with 695 the media authorized during session set up. The SCD Policy Server 696 is the only network entity that needs to interpret the contents 697 of the correlation identifier therefore, in this model, the 698 contents of the correlation identifier are implementation 699 dependent. Since the End Host is assumed to be untrusted, the SCD 700 Policy Server should take measures to ensure that the integrity 701 of the correlation identifier is preserved in transit; the exact 702 mechanisms to be used are also implementation dependent. 704 - The identity of the authorizing entity. This information is used 705 by the RCD Policy Server to determine which SCD Policy Server 706 should be used to verify the contents of the resource reservation 707 request. 709 In some environments, an RCD Policy Server may have no means for 710 determining if the identity refers to a legitimate SCD Policy 711 Server. In order to protect against redirection of authorization 712 requests to a bogus authorizing entity, the token should include: 714 - An authentication signature. This signature is calculated over 715 all other fields of the token using an agreed mechanism. The RCD 716 Policy Server must be able to verify the signature using 717 credentials of the signer to confirm a trust relationship. The 718 mechanism used by the RCD Policy Server is beyond the scope of 719 this document. 721 Framework for session set-up with media authorization 723 Note that the information in this token is the same as that in 724 Section 5.2 for the "One Policy Server" scenario. 726 The detailed semantics of an example token are defined in [6]. 728 6.3 Associated Model Protocol Impacts <> 730 The use of a media authorization token in this version of the 731 Associated Model requires the addition of new fields to several 732 protocols: 734 - Resource reservation protocol. A new protocol field or object 735 must be added to the resource reservation protocol to 736 transparently transport the token from the End Host to the Edge 737 Router. The content and internal structure of this object should 738 be opaque to the resource reservation protocol. For example, this 739 is achieved in RSVP with the Policy Data object defined in [11]. 741 - Policy management protocol. A new protocol field or object must 742 be added to the policy management protocol to transport the token 743 from the SCD Policy Server to the Session Management Server and 744 from the Edge Router to the RCD Policy Server. The content and 745 internal structure of this object must be specified so that the 746 Policy Servers can distinguish between the elements of the token 747 described in Section 6.2. For example, this is achieved in COPS- 748 RSVP with the Policy Data object defined in [11]. 750 - Session management protocol. A new protocol field or object must 751 be added to the session management protocol to transparently 752 transport the media authorization token from the Session 753 Management Server to the End Host. The content and internal 754 structure of this object should be opaque to the session 755 management protocol. 757 Note that these impacts are the same as those discussed in Section 758 5.3 for the "One Policy Server" scenario. However the use of two 759 Policy Servers has one additional impact: 761 - Authorization protocol. A new protocol field or object must be 762 added to the authorization protocol to transport the token from 763 the RCD Policy Server to the SCD Policy Server. The content and 764 internal structure of this object must be specified so that the 765 Policy Servers can distinguish between the elements of the token 766 described in Section 6.2. 768 Framework for session set-up with media authorization 770 7. The Non-Associated Model 772 In this scenario, the Session Management Servers and Edge Routers 773 are associated with different Policy Servers, the network entities 774 do not have a priori knowledge of the topology of the network and 775 there are no pre-established trust relationships between entities in 776 the Resource Control District and entities in the Service Control 777 District. The keys aspects of this scenario are the following: 779 - Policy decisions, including media authorization, are made by 780 Policy Servers. 782 - The PS in the Resource Control District is separate from the PS 783 in the Session Control District. 785 - There is a pre-defined trust relationship between the SMS and the 786 SCD PS. 788 - There is a pre-defined trust relationship between the ER and the 789 RCD PS. 791 - There are no pre-defined trust relationships between the ER and 792 SMS or between the RCD and SCD Policy Servers. 794 +--------+ 795 +------+ | | 796 | | 1 +--------------------+ 2 | SCD | 797 | |-------->| Session Management |----->| Policy | 798 | |<--------| Server |<-----| Server | 799 | | 4 +--------------------+ 3 | | 800 | End | +--------+ 801 | Host | 802 | | +--------+ 803 | | 5 +--------------------+ 6 | | 804 | |-------->| Edge |----->| RCD | 805 | |<--------| Router |<-----| Policy | 806 | | 8 +--------------------+ 7 | Server | 807 +------+ | | 808 +--------+ 810 Figure 5: The Non-Associated Model 812 7.1 Non-Associated Model Call Flow 814 In this model it is assumed that the policy servers make independent 815 decisions for their respective districts, obviating the need for 816 information exchange between policy servers. This model also enables 817 Framework for session set-up with media authorization 819 session authorization when communication between policy servers is 820 not possible for various reasons. It may also be used as a means to 821 speed up session setup and still ensure proper authorization is 822 performed. 824 This model does not preclude the possibility that the policy servers 825 may communicate at other times for other purposes (e.g. exchange of 826 accounting information). 828 Communications between network entities in this model is described 829 below. Only the originating side flows are described for simplicity. 830 The same concepts apply to the terminating side. 832 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 833 the Session Manager indicating, among other things, the media 834 streams to be used in the session. As part of this step, the End 835 Host may authenticate itself to the Session Manager. 837 2. The Session Manager, possibly after waiting for negotiation of 838 the media streams to be completed, sends a policy decision 839 request (e.g. COPS REQ) to the SCD Policy Server in order to 840 determine if the session set-up request should be allowed to 841 proceed. 843 3. The SCD Policy Server sends a decision (e.g. COPS DEC) to the 844 Session Manager, possibly after modifying the parameters of the 845 media to be used. Included in this response is a "token" that can 846 subsequently be used by the RCD Policy Server to determine what 847 media has been authorized. 849 4. The Session Manager sends a response to the End Host (e.g. SIP 850 200 or 183) indicating that session set-up is complete or is 851 progressing. Included in this response is a description of the 852 negotiated media along with the token from the SCD Policy Server. 854 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 855 resources necessary to provide the required QoS for the media 856 stream. Included in this request is the token from the SCD Policy 857 Server provided via the Session Manager. 859 6. The Edge Router intercepts the reservation request and sends a 860 policy decision request (e.g. COPS REQ) to the RCD Policy Server 861 in order to determine if the resource reservation request should 862 be allowed to proceed. Included in this request is the token from 863 the SCD Policy Server provided by the End Host. 865 7. The RCD Policy Server uses this token to extract information 866 about the media that was authorized by the SCD Policy Server. The 867 RCD Policy Server uses this information in making its decision on 868 whether the resource reservation should be allowed to proceed. 870 Framework for session set-up with media authorization 872 The Policy Server sends a decision (e.g. COPS DEC) to the Edge 873 Router, possibly after modifying the parameters of the resources 874 to be reserved. 876 8. The Edge Router, possibly after waiting for end-to-end 877 negotiation for resources to be completed, sends a response to 878 the End Host (e.g. RSVP RESV) indicating that resource 879 reservation is complete or is progressing 881 7.2 Non-Associated Model Authorization Token 883 In this model, the token must contain sufficient information to 884 allow the RCD Policy Server to make resource policy decisions 885 autonomously from the SCD Policy Server. The token is created using 886 information about the session received by the SMS. The information 887 in the token must include: 889 - Calling party IP address and port number (e.g. from SDP "c=" 890 parameter). 892 - Called party IP address and port number (e.g. from SDP "c=" 893 parameter). 895 - The characteristics of (each of) the media stream(s) authorized 896 for this session (e.g. codecs, maximum bandwidth from SDP "m=" 897 and/or "b=" parameters). 899 - The lifetime of (each of) the media stream(s) (e.g. from SDP "t=" 900 parameter). 902 - The authorization lifetime (e.g. the token should be valid for 903 only a few seconds after the start time of the session). 905 - The identity of the authorizing entity to allow for validation of 906 the token. 908 - An authentication signature used to prevent tampering with the 909 token and to provide the credentials of the authorizing entity. 910 This signature is calculated over all other fields of the token 911 using an agreed mechanism. The RCD Policy Server must be able to 912 verify the signature using credentials of the signer to confirm a 913 trust relationship. The mechanism used by the RCD Policy Server 914 is beyond the scope of this document. 916 The detailed semantics of the token are defined in [6]. 918 7.3 Non-Associated Model Protocol Impacts 919 Framework for session set-up with media authorization 921 The use of a media authorization token in the Non-Associated Model 922 requires the addition of new fields to several protocols: 924 - Resource reservation protocol. A new protocol field or object 925 must be added to the resource reservation protocol to 926 transparently transport the token from the End Host to the Edge 927 Router. The content and internal structure of this object should 928 be opaque to the resource reservation protocol. For example, this 929 is achieved in RSVP with the Policy Data object defined in [11]. 931 - Policy management protocol. A new protocol field or object must 932 be added to the policy management protocol to transport the token 933 from the SCD Policy Server to the Session Management Server and 934 from the Edge Router to the RCD Policy Server. The content and 935 internal structure of this object must be specified so that the 936 Policy Servers can distinguish between the elements of the token 937 described in Section 7.2. For example, this is achieved in COPS- 938 RSVP with the Policy Data object defined in [11]. 940 - Session management protocol. A new protocol field or object must 941 be added to the session management protocol to transparently 942 transport the media authorization token from the Session 943 Management Server to the End Host. The content and internal 944 structure of this object should be opaque to the session 945 management protocol. 947 8. Conclusions 949 In this document we have defined three models for authorizing media 950 during session establishment: 952 - The Coupled Model which assumes a priori knowledge of network 953 topology and where pre-established trust relationships exist 954 between network entities. 956 - The Associated Model where there are common or trusted policy 957 servers but knowledge of the network topology is not known a 958 priori. 960 - The Non-Associated Model where knowledge of the network topology 961 is not known a priori, where there are different policy servers 962 involved and where a trust relationship does not exist between 963 the policy servers. 965 The Associated Model is applicable to environments where the network 966 elements involved in establishing a session have a pre-determined 967 trust relationship but where their identities must be determined 968 dynamically during session set up. The Non-Associated Model is 969 applicable to environments where there is a complex network topology 970 Framework for session set-up with media authorization 972 and/or where trust relationships between domains do not exist (e.g. 973 when they are different business entities). 975 In any given network, one or more of these models may be applicable. 976 Indeed, the model to be used may be chosen dynamically during 977 session establishment based on knowledge of the end points involved 978 in the call. In all cases, however, there is no need for the End 979 Host, the Edge Router or the Session Management Server to understand 980 or interpret the authorization token - to them it is an opaque 981 protocol element that is simply copied from one container protocol 982 to another. 984 Finally, the framework defined in this document is extensible to any 985 kind of session management protocol coupled to any one of a number 986 of resource reservation and/or policy management protocols. 988 9. Security Considerations 990 The purpose of this draft is to describe a mechanism for media 991 authorization to prevent theft of service. It does not cover other 992 possible security breaches such as IP spoofing. 994 This draft assumes that trust relationships exist between various 995 network entities, as described in each of the models. The means for 996 establishing these relationships are beyond the scope of this 997 document. 999 For the authorization token to be effective, its integrity must be 1000 guaranteed as it passes through untrusted network entities such as 1001 the End Host. This can be achieved by using digital signatures. 1003 References 1005 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 1006 BCP 9, RFC 2026, October 1996. 1008 [2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, 1009 August 2000. 1011 [3] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August 1012 2000. 1014 [4] D. Durham et al., "The COPS (Common Open Policy Service) 1015 Protocol", RFC 2748, January 2000. 1017 [5] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January 1018 2000. 1020 Framework for session set-up with media authorization 1022 [6] L. Hamer et al. "Session Authorization for RSVP", Internet- 1023 Draft, draft-ietf-rap-rsvp-authsession-02.txt, February 2002, 1024 Work in progress. 1026 [7] "PacketCable Dynamic Quality of Service Specification", 1027 CableLabs, December 1999. 1028 http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf 1030 [8] M. Handley and V. Jacobson, "SDP: session description 1031 protocol," RFC 2327, Apr.1998. 1033 [9] Handley, Schulzrinne, Schooler & Rosenberg, RFC 2543, "SIP: 1034 Session Initiation Protocol", March 1999. 1036 [10] R. Braden et al.,"Resource ReSerVation protocol (RSVP) -- 1037 version 1 functional specification," RFC 2205, Sept.1997. 1039 [11] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, 1040 January 2000. 1042 [12] K. Chan et al., "COPS Usage for Policy Provisioning ( COPS-PR 1043 )", RFC 3084, March 2001. 1045 Acknowledgments 1047 The authors would like to thank to following people for their useful 1048 comments and suggestions related to this draft: Kwok Ho Chan, Doug 1049 Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, 1050 Francois Audet, Bill Marshall, Diana Rawlins. 1052 Authors' Addresses 1054 Louis-Nicolas Hamer 1055 Nortel Networks 1056 Ottawa, ON 1057 CANADA 1058 Email: nhamer@nortelnetworks.com 1060 Bill Gage 1061 Nortel Networks 1062 Ottawa, ON 1063 CANADA 1064 Email: gageb@nortelnetworks.com 1066 Hugh Shieh 1067 AT&T Wireless 1068 Redmond, WA 1069 USA 1070 Email: hugh.shieh@attws.com 1071 Framework for session set-up with media authorization 1073 Full Copyright Statement 1075 Copyright (C) The Internet Society (2002). All Rights Reserved. This 1076 document and translations of it may be copied and furnished to 1077 others, and derivative works that comment on or otherwise explain it 1078 or assist in its implementation may be prepared, copied, published 1079 and distributed, in whole or in part, without restriction of any 1080 kind, provided that the above copyright notice and this paragraph 1081 are included on all such copies and derivative works. However, this 1082 document itself may not be modified in any way, such as by removing 1083 the copyright notice or references to the Internet Society or other 1084 Internet organizations, except as needed for the purpose of 1085 developing Internet standards in which case the procedures for 1086 copyrights defined in the Internet Standards process must be 1087 followed, or as required to translate it into. 1089 Expiration Date 1091 This memo is filed as , and 1092 expires August 31, 2002.