idnits 2.17.1 draft-ietf-rap-session-auth-01.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. == 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 (July 2001) is 8320 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '9' is defined on line 1017, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-sip-manyfolks-resource-01 == Outdated reference: A later version (-06) exists of draft-ietf-sip-call-auth-01 == Outdated reference: A later version (-05) exists of draft-ietf-rap-rsvp-authsession-00 ** 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 (~~), 8 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 5 Document: draft-ietf-rap-session-auth-01.txt Nortel Networks 6 Category: Informational July 2001 8 Framework for session set-up with media authorization 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet- Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 The distribution of this memo is unlimited. This memo is filed as 29 , and expires December 31, 2001. 30 Please send comments to the authors. 32 Abstract 34 Establishing multimedia streams must take into account requirements 35 for end-to-end QoS, authorization of network resource usage and 36 accurate accounting for resources used. During session set up, 37 policies may be enforced to ensure that the media streams being 38 requested lie within the bounds of the service profile established 39 for the requesting host. Similarly, when a host requests resources 40 to provide a certain QoS for a packet flow, policies may be enforced 41 to ensure that the required resources lie within the bounds of the 42 resource profile established for the requesting host. 44 To prevent fraud and to ensure accurate billing, we describe various 45 scenarios and mechanisms that provide the linkage required to verify 46 that the resources being used to provide a requested QoS are in-line 47 with the media streams requested (and authorized) for the session. 49 Framework for session set-up with media authorization 51 Contents 53 Status of this Memo................................................1 54 Abstract...........................................................1 55 Contents...........................................................2 56 1. Introduction....................................................3 57 2. Conventions used in this document...............................4 58 3. Definition of terms.............................................5 59 4. The Coupled Model...............................................7 60 4.1 Coupled Model Message Flows..................................7 61 4.2 Coupled Model Authorization Token............................9 62 4.3 Coupled Model Protocol Impacts...............................9 63 5. The Associated Model <>...............10 64 5.1 Associated Model Message Flows <>..11 65 5.2 Associated Model Authorization Token <>.......12 66 5.3 Associated Model Protocol Impacts <>..........12 67 5.4 Associated Model Network Impacts <>...........13 68 6. The Associated Model <>..............14 69 6.1 Associated Model Message Flows <>.............15 70 6.2 Associated Model Authorization Token <>.......16 71 6.3 Associated Model Protocol Impacts <>..........17 72 7. The Non-Associated Model.......................................18 73 7.1 Non-Associated Model Call Flow..............................18 74 7.2 Non-Associated Model Authorization Token....................20 75 7.3 Non-Associated Model Protocol Impacts.......................20 76 8. Conclusions....................................................21 77 9. Security Considerations........................................22 78 References........................................................22 79 Acknowledgments...................................................23 80 Authors' Addresses................................................23 81 Full Copyright Statement..........................................23 82 Expiration Date...................................................24 83 Framework for session set-up with media authorization 85 1. Introduction 87 Establishing multimedia streams must take into account requirements 88 for end-to-end QoS, authorization of network resource usage and 89 accurate accounting for resources used. During session set up, 90 policies may be enforced to ensure that the media streams being 91 requested lie within the bounds of the service profile established 92 for the requesting host. Similarly, when a host requests resources 93 to provide a certain QoS for a packet flow, policies may be enforced 94 to ensure that the required resources lie within the bounds of the 95 resource profile established for the requesting host. 97 Reference [5] defines a mechanism through which end hosts can use a 98 session control protocol (e.g. SIP [10]) to indicate that QoS 99 requirements must be met in order to successfully set up a session. 100 However, a separate protocol (e.g. RSVP [11]) is used to request the 101 resources required to meet the end-to-end QoS of the media stream. 102 To prevent fraud and to ensure accurate billing, some linkage is 103 required to verify that the resources being used to provide the 104 requested QoS are in-line with the media streams requested (and 105 authorized) for the session. 107 This document describes such a linkage through use of a "token" that 108 provides capabilities similar to that of a gate in [8] and of a 109 ticket in the push model of [2]. The token is generated by a policy 110 server (or a session manager) and is transparently relayed through 111 the end host to the edge router where it is used as part of the 112 policy-controlled flow admission process. 114 In some environments, authorization of media streams can exploit the 115 fact that pre-established relationships exist between elements of 116 the network (e.g. session managers, edge routers, policy servers and 117 end hosts). In other environments, however, such pre-established 118 relationships may not exist either due to the complexity of creating 119 these associations a priori (e.g. in a network with many elements), 120 or due to the different business entities involved (e.g. service 121 provider and access provider), or due to the dynamic nature of these 122 associations (e.g. in a mobile environment). 124 In this document, we describe these various scenarios and the 125 mechanisms used for exchanging information between network elements 126 in order to authorize the use of resources for a service and to co- 127 ordinate actions between the session and resource management 128 entities. Specific extensions to session control protocols (e.g. SIP 129 [6], H.323), to resource reservation protocols (e.g. RSVP [7], 130 YESSIR) and to policy managements protocols (e.g. COPS-SIP [12], 131 COPS-RSVP [4]) required to realize these scenarios and mechanisms 132 are beyond the scope of this document. 134 Framework for session set-up with media authorization 136 For clarity, this document will illustrate the media authorization 137 concepts using SIP for session signalling, RSVP for resource 138 reservation and COPS for interaction with the policy servers. Note, 139 however, that the framework could be applied to a multimedia 140 services scenario using different signalling protocols. 142 2. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 146 this document are to be interpreted as described in RFC-2119 [1]. 148 Framework for session set-up with media authorization 150 3. Definition of terms 152 Figure 1 introduces a generic model for session establishment, QoS 153 and policy enforcement. 155 +-------------------------------------+ +---+ 156 | SCD - Service Control District | | | 157 | +-----------------------+ +--------+| | I | 158 | |Session management | |Policy || | n | 159 | |server | |Server || | t | 160 | | +---------+ +------+ | | +----+||<->| e | 161 | | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r | 162 | | +---------+ +------+ | | +----+|| | - | 163 | +-----------------------+ +--------+| | c | 164 | | | o | 165 +-------------------------------------+ | n | 166 | n | 167 +-------------------------------------+ | e | 168 | RCD - Resource Control District | | c | 169 | | | t | 170 | | | i | 171 | +------------+ +-------------+ | | n | 172 +----------+ | |Edge Router | |Policy Server| | | g | 173 | End | | | | | | | | | 174 | Host | | |+----------+| |+----------+ | | | N | 175 |+--------+| | ||RSVP Agent|| ||PDP | | | | e | 176 ||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t | 177 ||Client || | |+----------+| | | | | w | 178 |+--------+| | || PEP || | | | | o | 179 ||SIP User|| | |+----------+| | | | | r | 180 ||Agent || | +------------+ +-------------+ | | k | 181 |+--------+| | | | | 182 +----------+ +-------------------------------------+ +---+ 184 Figure 1: Generic media authorization network model 186 EH - End Host: The End Host is a device used by a subscriber to 187 access network services. The End Host includes a client for 188 requesting network services (e.g. through SIP) and a client for 189 requesting network resources (e.g. through RSVP). 191 ER - Edge Router: The Edge Router is a network element connecting 192 the end host to the rest of the Resource Control District. The Edge 193 Router contains a PEP to enforce policies related to resource usage 194 in the Resource Control District by the End Host. It also contains a 195 signalling agent (e.g. for RSVP) for handling resource reservation 196 requests from the End Host. 198 Framework for session set-up with media authorization 200 PDP - Policy Decision Point: The PDP is a logical entity located in 201 the Policy Server that is responsible for authorizing or denying 202 access to services and/or resources. 204 PEP - Policy Enforcement Point: The PEP is a logical entity that 205 enforces policy decisions made by the PDP. Note that other PEPs may 206 reside in other network elements not shown in the model of Figure 1, 207 however they will not be discussed in this document. 209 PS - Policy Server: The Policy Server is a network element that 210 includes a PDP. Note that there may be a PS in the Service Control 211 District to control use of services and there may be a separate PS 212 in the Resource Control District to control use of resources along 213 the packet forwarding path. Note also that network topology may 214 require multiple Policy Servers within either district, however they 215 provide consistent policy decisions to offer the appearance of a 216 single PDP in each district. 218 RCD - Resource Control District: The Resource Control District is a 219 logical grouping of elements that provide connectivity along the 220 packet forwarding paths to and from an End Host. The RCD contains ER 221 and PS entities whose responsibilities include management of 222 resources along the packet forwarding paths. 224 SCD - Service Control District: The Service Control District is a 225 logical grouping of elements that offer applications and content to 226 subscribers of their services. The Session Management Server resides 227 in the SCD along with a PS. 229 SMS - Session Management Server: The Session Management Server is a 230 network element providing session management services (e.g. 231 telephony call control). The Session Management Server contains a 232 PEP to enforce policies related to use of services by the End Host. 233 It also contains a signalling agent or proxy (e.g. for SIP) for 234 handling service requests from the End Host. 236 Framework for session set-up with media authorization 238 4. The Coupled Model 240 In some environments, a pre-established trust relationship exists 241 between elements of the network (e.g. session managers, edge 242 routers, policy servers and end hosts). We refer to this as the 243 "coupled model", indicating the tight relationship between entities 244 that is presumed. The key aspects of this scenario are the 245 following: 247 - Policy decisions, including media authorization, are made by a 248 single Policy Server. 250 - The Edge Router, Session Manager and Policy Server involved in 251 establishing the session are known a priori. For example, the End 252 Host may be configured to use a Session Manager associated with 253 the Edge Router to which the EH is connected. 255 - There are pre-defined trust relationships between the SMS and the 256 PS and between the ER and the PS. 258 +--------+ 259 +------+ | | 260 | | 1 +--------------------+ 2 | | 261 | |-------->| Session Management |----->| | 262 | |<--------| Server |<-----| | 263 | | 4 +--------------------+ 3 | | 264 | End | | Policy | 265 | Host | | Server | 266 | | | | 267 | | 5 +--------------------+ 6 | | 268 | |-------->| Edge |----->| | 269 | |<--------| Router |<-----| | 270 | | 8 +--------------------+ 7 | | 271 +------+ | | 272 +--------+ 274 Figure 2: The Coupled Model 276 4.1 Coupled Model Message Flows 278 In this model, it is assumed that there is one Policy Server serving 279 both the Service Control and Resource Control districts and that 280 there are pre-defined trust relationships between the PS and SMS and 281 between the PS and ER. Communications between these entities are 282 then possible as described below: 284 Framework for session set-up with media authorization 286 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 287 the Session Manager indicating, among other things, the media 288 streams to be used in the session. As part of this step, the End 289 Host may authenticate itself to the Session Manager. 291 2. The Session Manager, possibly after waiting for negotiation of 292 the media streams to be completed, sends a policy decision 293 request (e.g. COPS-SIP REQ) to the Policy Server in order to 294 determine if the session set-up request should be allowed to 295 proceed. 297 3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 298 Session Manager, possibly after modifying the parameters of the 299 media to be used. Included in this response is a "token" that can 300 subsequently be used by the Policy Server to identify the session 301 and the media it has authorized. 303 4. The Session Manager sends a response to the End Host (e.g. SIP 304 200 or 183) indicating that session set-up is complete or is 305 progressing. Included in this response is a description of the 306 negotiated media along with the token from the Policy Server. 308 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 309 resources necessary to provide the required QoS for the media 310 stream. Included in this request is the token from the Policy 311 Server provided via the Session Manager. 313 6. The Edge Router intercepts the reservation request and sends a 314 policy decision request (e.g. COPS-RSVP REQ) to the Policy Server 315 in order to determine if the resource reservation request should 316 be allowed to proceed. Included in this request is the token from 317 the Policy Server provided by the End Host. The Policy Server 318 uses this token to correlate the request for resources with the 319 media authorization previously provided to the Session Manager. 321 7. The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 322 Edge Router, possibly after modifying the parameters of the 323 resources to be reserved. 325 8. The Edge Router, possibly after waiting for end-to-end 326 negotiation for resources to be completed, sends a response to 327 the End Host (e.g. RSVP RESV) indicating that resource 328 reservation is complete or is progressing. 330 Framework for session set-up with media authorization 332 4.2 Coupled Model Authorization Token 334 In the Coupled Model, the Policy Server is the only network entity 335 that needs to interpret the contents of the token. Therefore, in 336 this model, the contents of the token are implementation dependent. 337 Since the End Host is assumed to be untrusted, the Policy Server 338 should take measures to ensure that the integrity of the token is 339 preserved in transit; the exact mechanisms to be used are also 340 implementation dependent. 342 4.3 Coupled Model Protocol Impacts 344 The use of a media authorization token in the Coupled Model requires 345 the addition of new fields to several protocols: 347 - Resource reservation protocol. A new protocol field or object 348 must be added to the resource reservation protocol to 349 transparently transport the token from the End Host to the Edge 350 Router. The content and internal structure (if any) of this 351 object should be opaque to the resource reservation protocol. For 352 example, this is achieved in RSVP with the Policy Data object 353 defined in [13]. 355 - Policy management protocol. A new protocol field or object must 356 be added to the policy management protocol to transparently 357 transport the token from the Policy Server to the Session 358 Management Server and from the Edge Router to the Policy Server. 359 The content and internal structure (if any) of this object should 360 be opaque to the policy management protocol. For example, this is 361 achieved in COPS-RSVP with the Policy Data object defined in 362 [13]. 364 - Session management protocol. A new protocol field or object must 365 be added to the session management protocol to transparently 366 transport the media authorization token from the Session 367 Management Server to the End Host. The content and internal 368 structure (if any) of this object should be opaque to the session 369 management protocol. For example, this is achieved in SIP with 370 the proposed header extensions in [6]. 372 Framework for session set-up with media authorization 374 5. The Associated Model <> 376 In this scenario, there are multiple instances of the Session 377 Management Servers, Edge Routers and Policy Servers. This leads to a 378 network of sufficient complexity that it precludes distributing 379 knowledge of network topology to all network entities. The key 380 aspects of this scenario are the following: 382 - Policy decisions, including media authorization, are made by a 383 the same Policy Server for both the Session Manager and the Edge 384 Router. However, the Policy Server may change on per-transaction 385 basis. 387 - The Edge Router, Session Manager and Policy Server involved in 388 establishing the session are not known a priori. For example, the 389 End Host may be dynamically configured to use one of a pool of 390 Session Managers and each of the Session Managers may be 391 statically configured to use one of a pool of Policy Servers. 393 In another example, the End Host may be mobile and continually 394 changing the Edge Router that its point of attachment uses to 395 communicate with the rest of the network. 397 - There are pre-defined trust relationships between the SMS and the 398 PS and between the ER and the PS. 400 +---------------------+ +---------+ 401 | SMS 'n' |<-->| PS 'm' | 402 +---------------------+ +--------+ | 403 +------+ : : : | | | 404 | | 1 +--------------------+ 2 | | | 405 | |-------->| Session Management |----->| | | 406 | |<--------| Server 1 |<-----| | | 407 | | 4 +--------------------+ 3 | | | 408 | End | | Policy | | 409 | Host | | Server | | 410 | | | 1 | | 411 | | 5 +--------------------+ 6 | | | 412 | |-------->| Edge |----->| | | 413 | |<--------| Router |<-----| | | 414 | | 8 +--------------------+ 7 | | | 415 +------+ | |-+ 416 +--------+ 418 Figure 3: The Associated Model using One Policy Server 419 Framework for session set-up with media authorization 421 5.1 Associated Model Message Flows <> 423 In this model, it is assumed that a Policy Server can make decisions 424 for both the Service Control and Resource Control districts and that 425 there are pre-defined trust relationships between the PS and SMS and 426 between the PS and ER. Communications between these entities are 427 then possible as described below: 429 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 430 the Session Manager indicating, among other things, the media 431 streams to be used in the session. As part of this step, the End 432 Host may authenticate itself to the Session Manager. 434 2. The Session Manager, possibly after waiting for negotiation of 435 the media streams to be completed, sends a policy decision 436 request (e.g. COPS-SIP REQ) to the Policy Server in order to 437 determine if the session set-up request should be allowed to 438 proceed. 440 3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 441 Session Manager, possibly after modifying the parameters of the 442 media to be used. Included in this response is a "token" that can 443 subsequently be used by the Policy Server to identify the session 444 and the media it has authorized. 446 4. The Session Manager sends a response to the End Host (e.g. SIP 447 200 or 183) indicating that session set-up is complete or is 448 progressing. Included in this response is a description of the 449 negotiated media along with the token from the Policy Server. 451 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 452 resources necessary to provide the required QoS for the media 453 stream. Included in this request is the token from the Policy 454 Server provided via the Session Manager. 456 6. The Edge Router intercepts the reservation request and inspects 457 the token to learn which Policy Server authorized the media. It 458 then sends a policy decision request (e.g. COPS-RSVP REQ) to that 459 Policy Server in order to determine if the resource reservation 460 request should be allowed to proceed. Included in this request is 461 the token from the Policy Server provided by the End Host. The 462 Policy Server uses this token to correlate the request for 463 resources with the media authorization previously provided to the 464 Session Manager. 466 7. The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 467 Edge Router, possibly after modifying the parameters of the 468 resources to be reserved. 470 8. The Edge Router, possibly after waiting for end-to-end 471 negotiation for resources to be completed, sends a response to 472 Framework for session set-up with media authorization 474 the End Host (e.g. RSVP RESV) indicating that resource 475 reservation is complete or is progressing. 477 5.2 Associated Model Authorization Token <> 479 Since the ER does not know which SMS and PS are involved in session 480 establishment, the token must include: 482 - A correlation identifier. This is information that the Policy 483 Server can use to correlate the resource reservation request with 484 the media authorized during session set up. The Policy Server is 485 the only network entity that needs to interpret the contents of 486 the correlation identifier therefore, in this model, the contents 487 of the correlation identifier are implementation dependent. Since 488 the End Host is assumed to be untrusted, the Policy Server should 489 take measures to ensure that the integrity of the correlation 490 identifier is preserved in transit; the exact mechanisms to be 491 used are also implementation dependent. 493 - The identity of the authorizing entity. This information is used 494 by the Edge Router to determine which Policy Server should be 495 used to solicit resource policy decisions. 497 In some environments, an Edge Router may have no means for 498 determining if the identity refers to a legitimate Policy Server 499 within its domain. In order to protect against redirection of 500 authorization requests to a bogus authorizing entity, the token 501 should also include: 503 - An authentication signature. This signature is calculated over 504 all other fields of the token using an agreed mechanism. The Edge 505 Router must be able to verify the signature using credentials of 506 the signer to confirm a trust relationship. The mechanism used by 507 the Edge Router is beyond the scope of this document. 509 The detailed semantics of the token are defined in [7]. 511 5.3 Associated Model Protocol Impacts <> 513 The use of a media authorization token in this version of the 514 Associated Model requires the addition of new fields to several 515 protocols: 517 - Resource reservation protocol. A new protocol field or object 518 must be added to the resource reservation protocol to 519 transparently transport the token from the End Host to the Edge 520 Router. The content and internal structure of this object must be 521 specified so that the Edge Router can distinguish between the 522 Framework for session set-up with media authorization 524 elements of the token described in Section 5.2. For example, this 525 is achieved in RSVP with the Policy Data object defined in [13]. 527 - Policy management protocol. A new protocol field or object must 528 be added to the policy management protocol to transparently 529 transport the token -- or at least the correlation identifier -- 530 from the Edge Router to the Policy Server. The content and 531 internal structure of this object should be opaque to the policy 532 management protocol. For example, this is achieved in COPS-RSVP 533 with the Policy Data object defined in [13]. 535 - Session management protocol. A new protocol field or object must 536 be added to the session management protocol to transparently 537 transport the media authorization token from the Session 538 Management Server to the End Host. The content and internal 539 structure of this object should be opaque to the session 540 management protocol. For example, this is achieved in SIP with 541 the proposed header extensions in [6]. 543 5.4 Associated Model Network Impacts <> 545 The use of a media authorization token in this version of the 546 Associated Model requires that the Edge Router inspect the token to 547 learn which Policy Server authorized the media. In some 548 environments, it may not be possible for the Edge Router to perform 549 this function; in these cases, an Associated Model using Two Policy 550 Servers (section 6) is required. 552 This version of the Associated Model also requires that the Edge 553 Router interact with multiple Policy Servers. Policy decisions are 554 made by the same Policy Server for both the Session Manager and the 555 Edge Router, however the Policy Server may change on per-transaction 556 basis. This implies that the Policy Servers are able to interact 557 and/or make decisions for the Edge Router in a consistent manner 558 (e.g. as though there is only a single RCD Policy Server). How this 559 is accomplished is beyond the scope of this document. 561 Framework for session set-up with media authorization 563 6. The Associated Model <> 565 In this scenario, there are multiple instances of the Session 566 Management Servers, Edge Routers and Policy Servers. This leads to a 567 network of sufficient complexity that it precludes distributing 568 knowledge of network topology to all network entities. The key 569 aspects of this scenario are the following: 571 - Policy decisions, including media authorization, are made by 572 Policy Servers. 574 - There is a PS in the Resource Control District that is separate 575 from the PS in the Session Control District. 577 - The Edge Router, Session Manager and Policy Servers involved in 578 establishing the session are not known a priori. For example, the 579 End Host may be dynamically configured to use one of a pool of 580 Session Managers or the End Host may be mobile and continually 581 changing the Edge Router that it uses to communicate with the 582 rest of the network. 584 - There is a pre-defined trust relationship between the SMS and the 585 SCD PS. 587 - There is a pre-defined trust relationship between the ER and the 588 RCD PS. 590 - There is a pre-defined trust relationship between the RCD and SCD 591 Policy Servers. 593 +--------+ 594 +------+ | | 595 | | 1 +--------------------+ 2 | SCD | 596 | |-------->| Session Management |----->| Policy | 597 | |<--------| Server |<-----| Server | 598 | | 4 +--------------------+ 3 | | 599 | End | +--------+ 600 | | 7 ^ | 601 | Host | | v 8 602 | | +--------+ 603 | | 5 +--------------------+ 6 | | 604 | |-------->| Edge |----->| RCD | 605 | |<--------| Router |<-----| Policy | 606 | | 10 +--------------------+ 9 | Server | 607 +------+ | | 608 +--------+ 610 Figure 4: The Associated Model using Two Policy Servers 611 Framework for session set-up with media authorization 613 6.1 Associated Model Message Flows <> 615 In this model, it is assumed that there is one Policy Server for the 616 Service Control District and a different Policy Server for the 617 Resource Control District. There are pre-defined trust relationships 618 between the SCD PS and SMS, between the RCD PS and ER and between 619 the RCD and SCD Policy Servers. Communications between these 620 entities are then possible as described below: 622 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 623 the Session Manager indicating, among other things, the media 624 streams to be used in the session. As part of this step, the End 625 Host may authenticate itself to the Session Manager. 627 2. The Session Manager, possibly after waiting for negotiation of 628 the media streams to be completed, sends a policy decision 629 request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to 630 determine if the session set-up request should be allowed to 631 proceed. 633 3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 634 Session Manager, possibly after modifying the parameters of the 635 media to be used. Included in this response is a "token" that can 636 subsequently be used by the SCD Policy Server to identify the 637 session and the media it has authorized. 639 4. The Session Manager sends a response to the End Host (e.g. SIP 640 200 or 183) indicating that session set-up is complete or is 641 progressing. Included in this response is a description of the 642 negotiated media along with the token from the SCD Policy Server. 644 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 645 resources necessary to provide the required QoS for the media 646 stream. Included in this request is the token from the SCD Policy 647 Server provided via the Session Manager. 649 6. The Edge Router intercepts the reservation request and sends a 650 policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy 651 Server in order to determine if the resource reservation request 652 should be allowed to proceed. Included in this request is the 653 token from the SCD Policy Server provided by the End Host. 655 7. The RCD Policy Server uses this token to learn which SCD Policy 656 Server authorized the media. It then sends an authorization 657 request [3] to that SCD Policy Server in order to determine if 658 the resource reservation request should be allowed to proceed. 659 Included in this request is the token from the SCD Policy Server 660 provided by the End Host. 662 Framework for session set-up with media authorization 664 8. The SCD Policy Server uses this token to correlate the request 665 for resources with the media authorization previously provided to 666 the Session Manager. The SCD Policy Server sends a decision [3] 667 to the RCD Policy Server on whether the requested resources are 668 within the bounds authorized by the SCD Policy Server. 670 9. The RCD Policy Server sends a decision (e.g. COPS-RSVP DEC) to 671 the Edge Router, possibly after modifying the parameters of the 672 resources to be reserved. 674 10. The Edge Router, possibly after waiting for end-to-end 675 negotiation for resources to be completed, sends a response to 676 the End Host (e.g. RSVP RESV) indicating that resource 677 reservation is complete or is progressing 679 6.2 Associated Model Authorization Token <> 681 Since the RCD Policy Server does not know which SMS and SCD PS are 682 involved in session establishment, the token must include: 684 - A correlation identifier. This is information that the SCD Policy 685 Server can use to correlate the resource reservation request with 686 the media authorized during session set up. The SCD Policy Server 687 is the only network entity that needs to interpret the contents 688 of the correlation identifier therefore, in this model, the 689 contents of the correlation identifier are implementation 690 dependent. Since the End Host is assumed to be untrusted, the SCD 691 Policy Server should take measures to ensure that the integrity 692 of the correlation identifier is preserved in transit; the exact 693 mechanisms to be used are also implementation dependent. 695 - The identity of the authorizing entity. This information is used 696 by the RCD Policy Server to determine which SCD Policy Server 697 should be used to verify the contents of the resource reservation 698 request. 700 In some environments, an RCD Policy Server may have no means for 701 determining if the identity refers to a legitimate SCD Policy 702 Server. In order to protect against redirection of authorization 703 requests to a bogus authorizing entity, the token should include: 705 - An authentication signature. This signature is calculated over 706 all other fields of the token using an agreed mechanism. The RCD 707 Policy Server must be able to verify the signature using 708 credentials of the signer to confirm a trust relationship. The 709 mechanism used by the RCD Policy Server is beyond the scope of 710 this document. 712 Framework for session set-up with media authorization 714 Note that the information in this token is the same as that in 715 Section 5.2 for the "One Policy Server" scenario. 717 The detailed semantics of the token are defined in [7]. 719 6.3 Associated Model Protocol Impacts <> 721 The use of a media authorization token in this version of the 722 Associated Model requires the addition of new fields to several 723 protocols: 725 - Resource reservation protocol. A new protocol field or object 726 must be added to the resource reservation protocol to 727 transparently transport the token from the End Host to the Edge 728 Router. The content and internal structure of this object should 729 be opaque to the resource reservation protocol. For example, this 730 is achieved in RSVP with the Policy Data object defined in [13]. 732 - Policy management protocol. A new protocol field or object must 733 be added to the policy management protocol to transport the token 734 from the SCD Policy Server to the Session Management Server and 735 from the Edge Router to the RCD Policy Server. The content and 736 internal structure of this object must be specified so that the 737 Policy Servers can distinguish between the elements of the token 738 described in Section 6.2. For example, this is achieved in COPS- 739 RSVP with the Policy Data object defined in [13]. 741 - Session management protocol. A new protocol field or object must 742 be added to the session management protocol to transparently 743 transport the media authorization token from the Session 744 Management Server to the End Host. The content and internal 745 structure of this object should be opaque to the session 746 management protocol. For example, this is achieved in SIP with 747 the proposed header extensions in [6]. 749 Note that these impacts are the same as those discussed in Section 750 5.3 for the "One Policy Server" scenario. However the use of two 751 Policy Servers has one additional impact: 753 - Authorization protocol. A new protocol field or object must be 754 added to the authorization protocol to transport the token from 755 the RCD Policy Server to the SCD Policy Server. The content and 756 internal structure of this object must be specified so that the 757 Policy Servers can distinguish between the elements of the token 758 described in Section 6.2. 760 Framework for session set-up with media authorization 762 7. The Non-Associated Model 764 In this scenario, the Session Management Servers and Edge Routers 765 are associated with different Policy Servers, the network entities 766 do not have a priori knowledge of the topology of the network and 767 there are no pre-established trust relationships between entities in 768 the Resource Control District and entities in the Service Control 769 District. The keys aspects of this scenario are the following: 771 - Policy decisions, including media authorization, are made by 772 Policy Servers. 774 - The PS in the Resource Control District is separate from the PS 775 in the Session Control District. 777 - There is a pre-defined trust relationship between the SMS and the 778 SCD PS. 780 - There is a pre-defined trust relationship between the ER and the 781 RCD PS. 783 - There are no pre-defined trust relationships between the ER and 784 SMS or between the RCD and SCD Policy Servers. 786 +--------+ 787 +------+ | | 788 | | 1 +--------------------+ 2 | SCD | 789 | |-------->| Session Management |----->| Policy | 790 | |<--------| Server |<-----| Server | 791 | | 4 +--------------------+ 3 | | 792 | End | +--------+ 793 | Host | 794 | | +--------+ 795 | | 5 +--------------------+ 6 | | 796 | |-------->| Edge |----->| RCD | 797 | |<--------| Router |<-----| Policy | 798 | | 8 +--------------------+ 7 | Server | 799 +------+ | | 800 +--------+ 802 Figure 5: The Non-Associated Model 804 7.1 Non-Associated Model Call Flow 806 In this model it is assumed that the policy servers make independent 807 decisions for their respective districts, obviating the need for 808 Framework for session set-up with media authorization 810 information exchange between policy servers. Communications between 811 network entities in this model is described below: 813 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 814 the Session Manager indicating, among other things, the media 815 streams to be used in the session. As part of this step, the End 816 Host may authenticate itself to the Session Manager. 818 2. The Session Manager, possibly after waiting for negotiation of 819 the media streams to be completed, sends a policy decision 820 request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to 821 determine if the session set-up request should be allowed to 822 proceed. 824 3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 825 Session Manager, possibly after modifying the parameters of the 826 media to be used. Included in this response is a "token" that can 827 subsequently be used by the RCD Policy Server to determine what 828 media has been authorized. 830 4. The Session Manager sends a response to the End Host (e.g. SIP 831 200 or 183) indicating that session set-up is complete or is 832 progressing. Included in this response is a description of the 833 negotiated media along with the token from the SCD Policy Server. 835 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 836 resources necessary to provide the required QoS for the media 837 stream. Included in this request is the token from the SCD Policy 838 Server provided via the Session Manager. 840 6. The Edge Router intercepts the reservation request and sends a 841 policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy 842 Server in order to determine if the resource reservation request 843 should be allowed to proceed. Included in this request is the 844 token from the SCD Policy Server provided by the End Host. 846 7. The RCD Policy Server uses this token to extract information 847 about the media that was authorized by the SCD Policy Server. The 848 RCD Policy Server uses this information in making its decision on 849 whether the resource reservation should be allowed to proceed. 851 The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 852 Edge Router, possibly after modifying the parameters of the 853 resources to be reserved. 855 8. The Edge Router, possibly after waiting for end-to-end 856 negotiation for resources to be completed, sends a response to 857 the End Host (e.g. RSVP RESV) indicating that resource 858 reservation is complete or is progressing 859 Framework for session set-up with media authorization 861 7.2 Non-Associated Model Authorization Token 863 In this model, the token must contain sufficient information to 864 allow the RCD Policy Server to make resource policy decisions 865 autonomously from the SCD Policy Server. The token is created using 866 information about the session received by the SMS. The information 867 in the token must include: 869 - Calling party IP address and port number (e.g. from SDP "c=" 870 parameter). 872 - Called party IP address and port number (e.g. from SDP "c=" 873 parameter). 875 - The characteristics of (each of) the media stream(s) authorized 876 for this session (e.g. codecs, maximum bandwidth from SDP "m=" 877 and/or "b=" parameters). 879 - The lifetime of (each of) the media stream(s) (e.g. from SDP "t=" 880 parameter). 882 - The authorization lifetime (e.g. the token should be valid for 883 only a few seconds after the start time of the session). 885 - The identity of the authorizing entity to allow for validation of 886 the token. 888 - An authentication signature used to prevent tampering with the 889 token and to provide the credentials of the authorizing entity. 890 This signature is calculated over all other fields of the token 891 using an agreed mechanism. The RCD Policy Server must be able to 892 verify the signature using credentials of the signer to confirm a 893 trust relationship. The mechanism used by the RCD Policy Server 894 is beyond the scope of this document. 896 The detailed semantics of the token are defined in [7]. 898 7.3 Non-Associated Model Protocol Impacts 900 The use of a media authorization token in the Non-Associated Model 901 requires the addition of new fields to several protocols: 903 - Resource reservation protocol. A new protocol field or object 904 must be added to the resource reservation protocol to 905 transparently transport the token from the End Host to the Edge 906 Router. The content and internal structure of this object should 907 be opaque to the resource reservation protocol. For example, this 908 is achieved in RSVP with the Policy Data object defined in [13]. 910 Framework for session set-up with media authorization 912 - Policy management protocol. A new protocol field or object must 913 be added to the policy management protocol to transport the token 914 from the SCD Policy Server to the Session Management Server and 915 from the Edge Router to the RCD Policy Server. The content and 916 internal structure of this object must be specified so that the 917 Policy Servers can distinguish between the elements of the token 918 described in Section 7.2. For example, this is achieved in COPS- 919 RSVP with the Policy Data object defined in [13]. 921 - Session management protocol. A new protocol field or object must 922 be added to the session management protocol to transparently 923 transport the media authorization token from the Session 924 Management Server to the End Host. The content and internal 925 structure of this object should be opaque to the session 926 management protocol. For example, this is achieved in SIP with 927 the proposed header extensions in [6]. 929 8. Conclusions 931 In this document we have defined three models for authorizing media 932 during session establishment: 934 - The Coupled Model which assumes a priori knowledge of network 935 topology and where pre-established trust relationships exist 936 between network entities. 938 - The Associated Model where there are common or trusted policy 939 servers but knowledge of the network topology is not known a 940 priori. 942 - The Non-Associated Model where knowledge of the network topology 943 is not known a priori, where there are different policy servers 944 involved and where a trust relationship does not exist between 945 the policy servers. 947 The Associated Model is applicable to environments where the network 948 elements involved in establishing a session have a pre-determined 949 trust relationship but where their identities must be determined 950 dynamically during session set up. The Non-Associated Model is 951 applicable to environments where there is a complex network topology 952 and/or where trust relationships between domains do not exist (e.g. 953 when they are different business entities). 955 In any given network, one or more of these models may be applicable. 956 Indeed, the model to be used may be chosen dynamically during 957 session establishment based on knowledge of the end points involved 958 in the call. In all cases, however, there is no need for the End 959 Host, the Edge Router or the Session Management Server to understand 960 or interpret the authorization token - to them it is an opaque 961 Framework for session set-up with media authorization 963 protocol element that is simply copied from one container protocol 964 to another. 966 Finally, the framework defined in this document is extensible to any 967 kind of session management protocol coupled to any one of a number 968 of resource reservation and/or policy management protocols. 970 9. Security Considerations 972 The purpose of this draft is to describe a mechanism for media 973 authorization to prevent theft of service. It does not cover other 974 possible security breaches such as IP spoofing. 976 This draft assumes that trust relationships exist between various 977 network entities, as described in each of the models. The means for 978 establishing these relationships are beyond the scope of this 979 document. 981 For the authorization token to be effective, its integrity must be 982 guaranteed as it passes through untrusted network entities such as 983 the End Host. This can be achieved by using digital signatures. 985 References 987 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 988 BCP 9, RFC 2026, October 1996. 990 [2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, 991 August 2000 993 [3] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August 994 2000 996 [4] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January 997 2000. 999 [5] W.Marshall et al. "Integration of Resource Management and SIP", 1000 Internet-Draft, draft-ietf-sip-manyfolks-resource-01, February 1001 2001, Work in progress. 1003 [6] W. Marshall et al., "SIP Extensions for Media Authorization", 1004 Internet-Draft, draft-ietf-sip-call-auth-01.txt, February 2001, 1005 Work in progress. 1007 [7] L. Hamer et al. "Session Authorization for RSVP", Internet- 1008 Draft, draft-ietf-rap-rsvp-authsession-00.txt, April2001, Work 1009 in progress. 1011 Framework for session set-up with media authorization 1013 [8] "PacketCable Dynamic Quality of Service Specification", 1014 CableLabs, December 1999. 1015 http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf 1017 [9] M. Handley and V. Jacobson, "SDP: session description 1018 protocol," RFC 2327, Apr.1998. 1020 [10] Handley, Schulzrinne, Schooler & Rosenberg, Internet-Draft, 1021 "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis- 1022 03.txt, May 2001, Work in progress. 1024 [11] R. Braden et al.,"Resource ReSerVation protocol (RSVP) -- 1025 version 1 functional specification," RFC 2205, Sept.1997. 1027 [12] G. Gross et al., "COPS usage for SIP", Internet-Draft, draft- 1028 gross-cops-sip-01.txt, April 2001, Work in progress. 1030 [13] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, 1031 January 2000. 1033 Acknowledgments 1035 The authors would like to thank to following people for their useful 1036 comments and suggestions related to this draft: Doug Reeves, Sam 1037 Christie, Matt Broda, Brett Kosinski, Francois Audet, 1038 Bill Marshall, Kwok Chan and many others. 1040 Authors' Addresses 1042 Louis-Nicolas Hamer 1043 Nortel Networks 1044 Ottawa, ON 1045 CANADA 1046 Email: nhamer@nortelnetworks.com 1048 Bill Gage 1049 Nortel Networks 1050 Ottawa, ON 1051 CANADA 1052 Email: gageb@nortelnetworks.com 1054 Full Copyright Statement 1056 Copyright (C) The Internet Society (2001). All Rights Reserved. This 1057 document and translations of it may be copied and furnished to 1058 others, and derivative works that comment on or otherwise explain it 1059 or assist in its implementation may be prepared, copied, published 1060 and distributed, in whole or in part, without restriction of any 1061 Framework for session set-up with media authorization 1063 kind, provided that the above copyright notice and this paragraph 1064 are included on all such copies and derivative works. However, this 1065 document itself may not be modified in any way, such as by removing 1066 the copyright notice or references to the Internet Society or other 1067 Internet organizations, except as needed for the purpose of 1068 developing Internet standards in which case the procedures for 1069 copyrights defined in the Internet Standards process must be 1070 followed, or as required to translate it into. 1072 Expiration Date 1074 This memo is filed as , and 1075 expires December 31, 2001.