idnits 2.17.1 draft-hamer-rap-session-auth-00.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. 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 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 954, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-17 == Outdated reference: A later version (-07) exists of draft-ietf-sip-manyfolks-resource-00 == Outdated reference: A later version (-06) exists of draft-ietf-sip-call-auth-01 Summary: 4 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-hamer-rap-session-auth-00.txt Nortel Networks 5 Category: Informational February 2001 7 Framework for session set-up with media authorization 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet- Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html 27 The distribution of this memo is unlimited. This memo is filed as 28 , and expires August 31, 2001. 29 Please send comments to the authors. 31 Abstract 33 Establishing multimedia streams must take into account requirements 34 for end-to-end QoS, authorization of network resource usage and 35 accurate accounting for resources used. During session set up, 36 policies may be enforced to ensure that the media streams being 37 requested lie within the bounds of the service profile established 38 for the requesting host. Similarly, when a host requests resources 39 to provide a certain QoS for a packet flow, policies may be enforced 40 to ensure that the required resources lie within the bounds of the 41 resource profile established for the requesting host. 43 To prevent fraud and to ensure accurate billing, we describe various 44 scenarios and mechanisms that provide the linkage required to verify 45 that the resources being used to provide a requested QoS are in-line 46 with the media streams requested (and authorized) for the session. 48 Framework for session set-up with media authorization 50 Contents 52 Status of this Memo................................................1 53 Abstract...........................................................1 54 Contents...........................................................2 55 1. Introduction....................................................3 56 2. Conventions used in this document...............................4 57 3. Definition of terms.............................................5 58 4. The Coupled Model...............................................7 59 4.1 Coupled Model Message Flows..................................7 60 4.2 Coupled Model Authorization Token............................9 61 4.3 Coupled Model Protocol Impacts...............................9 62 5. The Associated Model <>...............10 63 5.1 Associated Model Message Flows <>.............11 64 5.2 Associated Model Authorization Token <>.......12 65 5.3 Associated Model Protocol Impacts <>..........12 66 6. The Associated Model <>..............14 67 6.1 Associated Model Message Flows <>.............15 68 6.2 Associated Model Authorization Token <>.......16 69 6.3 Associated Model Protocol Impacts <>..........17 70 7. The Non-Associated Model.......................................18 71 7.1 Non-Associated Model Call Flow..............................18 72 7.2 Non-Associated Model Authorization Token....................20 73 7.3 Non-Associated Model Protocol Impacts.......................20 74 8. Conclusions....................................................21 75 9. Security Considerations........................................22 76 References........................................................22 77 Acknowledgments...................................................23 78 Authors' Addresses................................................23 79 Full Copyright Statement..........................................23 80 Expiration Date...................................................23 81 Framework for session set-up with media authorization 83 1. Introduction 85 Establishing multimedia streams must take into account requirements 86 for end-to-end QoS, authorization of network resource usage and 87 accurate accounting for resources used. During session set up, 88 policies may be enforced to ensure that the media streams being 89 requested lie within the bounds of the service profile established 90 for the requesting host. Similarly, when a host requests resources 91 to provide a certain QoS for a packet flow, policies may be enforced 92 to ensure that the required resources lie within the bounds of the 93 resource profile established for the requesting host. 95 Reference [5] defines a mechanism through which end hosts can use a 96 session control protocol (SIP) to indicate that QoS requirements 97 must be met in order to successfully set up a session. However, a 98 separate protocol (e.g. RSVP) is used to request the resources 99 required to meet the end-to-end QoS of the media stream. To prevent 100 fraud and to ensure accurate billing, some linkage is required to 101 verify that the resources being used to provide the requested QoS 102 are in-line with the media streams requested (and authorized) for 103 the session. 105 This document describes such a linkage through use of a "token" that 106 provides capabilities similar to that of a gate in [8] and of a 107 ticket in the push model of [2]. The token is generated by a policy 108 server (or a session manager) and is transparently relayed through 109 the end host to the edge router where it is used as part of the 110 policy-controlled flow admission process. 112 In some environments, authorization of media streams can exploit the 113 fact that pre-established relationships exist between elements of 114 the network (e.g. session managers, edge routers, policy servers and 115 end hosts). In other environments, however, such pre-established 116 relationships may not exist either due to the complexity of creating 117 these associations a priori (e.g. in a network with many elements), 118 or due to the different business entities involved (e.g. service 119 provider and access provider), or due to the dynamic nature of these 120 associations (e.g. in a mobile environment). 122 In this document, we describe these various scenarios and the 123 mechanisms used for exchanging information between network elements 124 in order to authorize the use of resources for a service and to co- 125 ordinate actions between the session and resource management 126 entities. Specific extensions to session control protocols (e.g. SIP 127 [6], H.323), to resource reservation protocols (e.g. RSVP [7], 128 YESSIR) and to policy managements protocols (e.g. COPS-SIP, COPS- 129 RSVP [4]) required to realize these scenarios and mechanisms are 130 beyond the scope of this document. 132 Framework for session set-up with media authorization 134 For clarity, this document will illustrate the media authorization 135 concepts using SIP for session signalling, RSVP for resource 136 reservation and COPS for interaction with the policy servers. Note, 137 however, that the framework could be applied to a multimedia 138 services scenario using different signalling protocols. 140 2. Conventions used in this document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 144 this document are to be interpreted as described in RFC-2119 [1]. 146 Framework for session set-up with media authorization 148 3. Definition of terms 150 Figure 1 introduces a generic model for session establishment, QoS 151 and policy enforcement. 153 +-------------------------------------+ +---+ 154 | SCD - Service Control District | | | 155 | +-----------------------+ +--------+| | I | 156 | |Session management | |Policy || | n | 157 | |server | |Server || | t | 158 | | +---------+ +------+ | | +----+||<->| e | 159 | | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r | 160 | | +---------+ +------+ | | +----+|| | - | 161 | +-----------------------+ +--------+| | c | 162 | | | o | 163 +-------------------------------------+ | n | 164 | n | 165 +-------------------------------------+ | e | 166 | RCD - Resource Control District | | c | 167 | | | t | 168 | | | i | 169 | +------------+ +-------------+ | | n | 170 +----------+ | |Edge Router | |Policy Server| | | g | 171 | End | | | | | | | | | 172 | Host | | |+----------+| |+----------+ | | | N | 173 |+--------+| | ||RSVP Agent|| ||PDP | | | | e | 174 ||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t | 175 ||Client || | |+----------+| | | | | w | 176 |+--------+| | || PEP || | | | | o | 177 ||SIP User|| | |+----------+| | | | | r | 178 ||Agent || | +------------+ +-------------+ | | k | 179 |+--------+| | | | | 180 +----------+ +-------------------------------------+ +---+ 182 Figure 1: Generic media authorization network model 184 EH - End Host: The End Host is a device used by a subscriber to 185 access network services. The End Host includes a client for 186 requesting network services (e.g. through SIP) and a client for 187 requesting network resources (e.g. through RSVP). 189 ER - Edge Router: The Edge Router is a network element connecting 190 the end host to the rest of the Resource Control District. The Edge 191 Router contains a PEP to enforce policies related to resource usage 192 in the Resource Control District by the End Host. It also contains a 193 signalling agent (e.g. for RSVP) for handling resource reservation 194 requests from the End Host. 196 Framework for session set-up with media authorization 198 PDP - Policy Decision Point: The PDP is a logical entity located in 199 the Policy Server that is responsible for authorizing or denying 200 access to services and/or resources. 202 PEP - Policy Enforcement Point: The PEP is a logical entity that 203 enforces policy decisions made by the PDP. Note that other PEPs may 204 reside in other network elements not shown in the model of Figure 1, 205 however they will not be discussed in this document. 207 PS - Policy Server: The Policy Server is a network element that 208 includes a PDP. Note that there may be a PS in the Service Control 209 District to control use of services and there may be a separate PS 210 in the Resource Control District to control use of resources along 211 the packet forwarding path. Note also that network topology may 212 require multiple Policy Servers within either district, however they 213 provide consistent policy decisions to offer the appearance of a 214 single PDP in each district. 216 RCD - Resource Control District: The Resource Control District is a 217 logical grouping of elements that provide connectivity along the 218 packet forwarding paths to and from an End Host. The RCD contains ER 219 and PS entities whose responsibilities include management of 220 resources along the packet forwarding paths. 222 SCD - Service Control District: The Service Control District is a 223 logical grouping of elements that offer applications and content to 224 subscribers of their services. The Session Management Server resides 225 in the SCD along with a PS. 227 SMS - Session Management Server: The Session Management Server is a 228 network element providing session management services (e.g. 229 telephony call control). The Session Management Server contains a 230 PEP to enforce policies related to use of services by the End Host. 231 It also contains a signalling agent or proxy (e.g. for SIP) for 232 handling service requests from the End Host. 234 Framework for session set-up with media authorization 236 4. The Coupled Model 238 In some environments, a pre-established trust relationship exists 239 between elements of the network (e.g. session managers, edge 240 routers, policy servers and end hosts). We refer to this as the 241 "coupled model", indicating the tight relationship between entities 242 that is presumed. The key aspects of this scenario are the 243 following: 245 - Policy decisions, including media authorization, are made by a 246 single Policy Server. 248 - The Edge Router, Session Manager and Policy Server involved in 249 establishing the session are known a priori. For example, the End 250 Host may be configured to use a Session Manager associated with 251 the Edge Router to which the EH is connected. 253 - There are pre-defined trust relationships between the SMS and the 254 PS and between the ER and the PS. 256 +--------+ 257 +------+ | | 258 | | 1 +--------------------+ 2 | | 259 | |-------->| Session Management |----->| | 260 | |<--------| Server |<-----| | 261 | | 4 +--------------------+ 3 | | 262 | End | | Policy | 263 | Host | | Server | 264 | | | | 265 | | 5 +--------------------+ 6 | | 266 | |-------->| Edge |----->| | 267 | |<--------| Router |<-----| | 268 | | 8 +--------------------+ 7 | | 269 +------+ | | 270 +--------+ 272 Figure 2: The Coupled Model 274 4.1 Coupled Model Message Flows 276 In this model, it is assumed that there is one Policy Server serving 277 both the Service Control and Resource Control districts and that 278 there are pre-defined trust relationships between the PS and SMS and 279 between the PS and ER. Communications between these entities are 280 then possible as described below: 282 Framework for session set-up with media authorization 284 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 285 the Session Manager indicating, among other things, the media 286 streams to be used in the session. As part of this step, the End 287 Host may authenticate itself to the Session Manager. 289 2. The Session Manager, possibly after waiting for negotiation of 290 the media streams to be completed, sends a policy decision 291 request (e.g. COPS-SIP REQ) to the Policy Server in order to 292 determine if the session set-up request should be allowed to 293 proceed. 295 3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 296 Session Manager, possibly after modifying the parameters of the 297 media to be used. Included in this response is a "token" that can 298 subsequently be used by the Policy Server to identify the session 299 and the media it has authorized. 301 4. The Session Manager sends a response to the End Host (e.g. SIP 302 200 or 183) indicating that session set-up is complete or is 303 progressing. Included in this response is a description of the 304 negotiated media along with the token from the Policy Server. 306 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 307 resources necessary to provide the required QoS for the media 308 stream. Included in this request is the token from the Policy 309 Server provided via the Session Manager. 311 6. The Edge Router intercepts the reservation request and sends a 312 policy decision request (e.g. COPS-RSVP REQ) to the Policy Server 313 in order to determine if the resource reservation request should 314 be allowed to proceed. Included in this request is the token from 315 the Policy Server provided by the End Host. The Policy Server 316 uses this token to correlate the request for resources with the 317 media authorization previously provided to the Session Manager. 319 7. The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 320 Edge Router, possibly after modifying the parameters of the 321 resources to be reserved. 323 8. The Edge Router, possibly after waiting for end-to-end 324 negotiation for resources to be completed, sends a response to 325 the End Host (e.g. RSVP RESV) indicating that resource 326 reservation is complete or is progressing. 328 Framework for session set-up with media authorization 330 4.2 Coupled Model Authorization Token 332 In the Coupled Model, the Policy Server is the only network entity 333 that needs to interpret the contents of the token. Therefore, in 334 this model, the contents of the token are implementation dependent. 335 Since the End Host is assumed to be untrusted, the Policy Server 336 should take measures to ensure that the integrity of the token is 337 preserved in transit; the exact mechanisms to be used are also 338 implementation dependent. 340 4.3 Coupled Model Protocol Impacts 342 The use of a media authorization token in the Coupled Model requires 343 the addition of new fields to several protocols: 345 - Resource reservation protocol. A new protocol field or object 346 must be added to the resource reservation protocol to 347 transparently transport the token from the End Host to the Edge 348 Router. The content and internal structure (if any) of this 349 object should be opaque to the resource reservation protocol. 351 - Policy management protocol. A new protocol field or object must 352 be added to the policy management protocol to transparently 353 transport the token from the Policy Server to the Session 354 Management Server and from the Edge Router to the Policy Server. 355 The content and internal structure (if any) of this object should 356 be opaque to the policy management protocol. 358 - Session management protocol. A new protocol field or object must 359 be added to the session management protocol to transparently 360 transport the media authorization token from the Session 361 Management Server to the End Host. The content and internal 362 structure (if any) of this object should be opaque to the session 363 management protocol. 365 Framework for session set-up with media authorization 367 5. The Associated Model <> 369 In this scenario, there are multiple instances of the Session 370 Management Servers, Edge Routers and Policy Servers. This leads to a 371 network of sufficient complexity that it precludes distributing 372 knowledge of network topology to all network entities. The key 373 aspects of this scenario are the following: 375 - Policy decisions, including media authorization, are made by a 376 the same Policy Server for both the Session Manager and the Edge 377 Router. Basically, the SCD and RCD outsource policy decisions to 378 the same policy server. However, the Policy Server may change on 379 per-transaction basis. 381 - The Edge Router, Session Manager and Policy Server involved in 382 establishing the session are not known a priori. For example, the 383 End Host may be dynamically configured to use one of a pool of 384 Session Managers and each of the Session Managers may be 385 statically configured to use one of a pool of Policy Servers. 387 In another example, the End Host may be mobile and continually 388 changing the Edge Router that its point of attachment uses to 389 communicate with the rest of the network. 391 - There are pre-defined trust relationships between the SMS and the 392 PS and between the ER and the PS. 394 +---------------------+ +---------+ 395 | SMS �n� |<-->| PS �m� | 396 +---------------------+ +--------+ | 397 +------+ : : : | | | 398 | | 1 +--------------------+ 2 | | | 399 | |-------->| Session Management |----->| | | 400 | |<--------| Server 1 |<-----| | | 401 | | 4 +--------------------+ 3 | | | 402 | End | | Policy | | 403 | Host | | Server | | 404 | | | 1 | | 405 | | 5 +--------------------+ 6 | | | 406 | |-------->| Edge |----->| | | 407 | |<--------| Router |<-----| | | 408 | | 8 +--------------------+ 7 | | | 409 +------+ | |-+ 410 +--------+ 412 Figure 3: The Associated Model using One Policy Server 413 Framework for session set-up with media authorization 415 5.1 Associated Model Message Flows <> 417 In this model, it is assumed that a Policy Server can make decisions 418 for both the Service Control and Resource Control districts and that 419 there are pre-defined trust relationships between the PS and SMS and 420 between the PS and ER. Communications between these entities are 421 then possible as described below: 423 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 424 the Session Manager indicating, among other things, the media 425 streams to be used in the session. As part of this step, the End 426 Host may authenticate itself to the Session Manager. 428 2. The Session Manager, possibly after waiting for negotiation of 429 the media streams to be completed, sends a policy decision 430 request (e.g. COPS-SIP REQ) to the Policy Server in order to 431 determine if the session set-up request should be allowed to 432 proceed. 434 3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 435 Session Manager, possibly after modifying the parameters of the 436 media to be used. Included in this response is a "token" that can 437 subsequently be used by the Policy Server to identify the session 438 and the media it has authorized. 440 4. The Session Manager sends a response to the End Host (e.g. SIP 441 200 or 183) indicating that session set-up is complete or is 442 progressing. Included in this response is a description of the 443 negotiated media along with the token from the Policy Server. 445 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 446 resources necessary to provide the required QoS for the media 447 stream. Included in this request is the token from the Policy 448 Server provided via the Session Manager. 450 6. The Edge Router intercepts the reservation request and inspects 451 the token to learn which Policy Server authorized the media. It 452 then sends a policy decision request (e.g. COPS-RSVP REQ) to that 453 Policy Server in order to determine if the resource reservation 454 request should be allowed to proceed. Included in this request is 455 the token from the Policy Server provided by the End Host. The 456 Policy Server uses this token to correlate the request for 457 resources with the media authorization previously provided to the 458 Session Manager. 460 7. The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 461 Edge Router, possibly after modifying the parameters of the 462 resources to be reserved. 464 8. The Edge Router, possibly after waiting for end-to-end 465 negotiation for resources to be completed, sends a response to 466 Framework for session set-up with media authorization 468 the End Host (e.g. RSVP RESV) indicating that resource 469 reservation is complete or is progressing. 471 5.2 Associated Model Authorization Token <> 473 Since the ER does not know which SMS and PS are involved in session 474 establishment, the token must include: 476 - A correlation identifier. This is information that the Policy 477 Server can use to correlate the resource reservation request with 478 the media authorized during session set up. The Policy Server is 479 the only network entity that needs to interpret the contents of 480 the correlation identifier therefore, in this model, the contents 481 of the correlation identifier are implementation dependent. Since 482 the End Host is assumed to be untrusted, the Policy Server should 483 take measures to ensure that the integrity of the correlation 484 identifier is preserved in transit; the exact mechanisms to be 485 used are also implementation dependent. 487 - The identity of the authorizing entity. This information is used 488 by the Edge Router to determine which Policy Server should be 489 used to solicit resource policy decisions. 491 In some environments, an Edge Router may have no means for 492 determining if the identity refers to a legitimate Policy Server 493 within its domain. In order to protect against redirection of 494 authorization requests to a bogus authorizing entity, the token 495 should also include: 497 - An authentication signature. This signature is calculated over 498 all other fields of the token using an agreed mechanism. The Edge 499 Router must be able to verify the signature using credentials of 500 the signer to confirm a trust relationship. The mechanism used by 501 the Edge Router is beyond the scope of this document. 503 5.3 Associated Model Protocol Impacts <> 505 The use of a media authorization token in this version of the 506 Associated Model requires the addition of new fields to several 507 protocols: 509 - Resource reservation protocol. A new protocol field or object 510 must be added to the resource reservation protocol to 511 transparently transport the token from the End Host to the Edge 512 Router. The content and internal structure of this object must be 513 specified so that the Edge Router can distinguish between the 514 elements of the token described in Section 5.2. 516 Framework for session set-up with media authorization 518 - Policy management protocol. A new protocol field or object must 519 be added to the policy management protocol to transparently 520 transport the token -- or at least the correlation identifier -- 521 from the Edge Router to the Policy Server. The content and 522 internal structure of this object should be opaque to the policy 523 management protocol. 525 - Session management protocol. A new protocol field or object must 526 be added to the session management protocol to transparently 527 transport the media authorization token from the Session 528 Management Server to the End Host. The content and internal 529 structure of this object should be opaque to the session 530 management protocol. 532 Framework for session set-up with media authorization 534 6. The Associated Model <> 536 In this scenario, there are multiple instances of the Session 537 Management Servers, Edge Routers and Policy Servers. This leads to a 538 network of sufficient complexity that it precludes distributing 539 knowledge of network topology to all network entities. The key 540 aspects of this scenario are the following: 542 - Policy decisions, including media authorization, are made by 543 Policy Servers. 545 - There is a PS in the Resource Control District that is separate 546 from the PS in the Session Control District. 548 - The Edge Router, Session Manager and Policy Servers involved in 549 establishing the session are not known a priori. For example, the 550 End Host may be dynamically configured to use one of a pool of 551 Session Managers or the End Host may be mobile and continually 552 changing the Edge Router that it uses to communicate with the 553 rest of the network. 555 - There is a pre-defined trust relationship between the SMS and the 556 SCD PS. 558 - There is a pre-defined trust relationship between the ER and the 559 RCD PS. 561 - There is a pre-defined trust relationship between the RCD and SCD 562 Policy Servers. 564 +--------+ 565 +------+ | | 566 | | 1 +--------------------+ 2 | SCD | 567 | |-------->| Session Management |----->| Policy | 568 | |<--------| Server |<-----| Server | 569 | | 4 +--------------------+ 3 | | 570 | End | +--------+ 571 | | 7 ^ | 572 | Host | | v 8 573 | | +--------+ 574 | | 5 +--------------------+ 6 | | 575 | |-------->| Edge |----->| RCD | 576 | |<--------| Router |<-----| Policy | 577 | | 10 +--------------------+ 9 | Server | 578 +------+ | | 579 +--------+ 581 Figure 4: The Associated Model using Two Policy Servers 582 Framework for session set-up with media authorization 584 6.1 Associated Model Message Flows <> 586 In this model, it is assumed that there is one Policy Server for the 587 Service Control District and a different Policy Server for the 588 Resource Control District. There are pre-defined trust relationships 589 between the SCD PS and SMS, between the RCD PS and ER and between 590 the RCD and SCD Policy Servers. Communications between these 591 entities are then possible as described below: 593 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 594 the Session Manager indicating, among other things, the media 595 streams to be used in the session. As part of this step, the End 596 Host may authenticate itself to the Session Manager. 598 2. The Session Manager, possibly after waiting for negotiation of 599 the media streams to be completed, sends a policy decision 600 request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to 601 determine if the session set-up request should be allowed to 602 proceed. 604 3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 605 Session Manager, possibly after modifying the parameters of the 606 media to be used. Included in this response is a "token" that can 607 subsequently be used by the SCD Policy Server to identify the 608 session and the media it has authorized. 610 4. The Session Manager sends a response to the End Host (e.g. SIP 611 200 or 183) indicating that session set-up is complete or is 612 progressing. Included in this response is a description of the 613 negotiated media along with the token from the SCD Policy Server. 615 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 616 resources necessary to provide the required QoS for the media 617 stream. Included in this request is the token from the SCD Policy 618 Server provided via the Session Manager. 620 6. The Edge Router intercepts the reservation request and sends a 621 policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy 622 Server in order to determine if the resource reservation request 623 should be allowed to proceed. Included in this request is the 624 token from the SCD Policy Server provided by the End Host. 626 7. The RCD Policy Server uses this token to learn which SCD Policy 627 Server authorized the media. It then sends an authorization 628 request (e.g. DIAMETER AA-Request) to that SCD Policy Server in 629 order to determine if the resource reservation request should be 630 allowed to proceed. Included in this request is the token from 631 the SCD Policy Server provided by the End Host. 633 Framework for session set-up with media authorization 635 8. The SCD Policy Server uses this token to correlate the request 636 for resources with the media authorization previously provided to 637 the Session Manager. The SCD Policy Server sends a decision (e.g. 638 DIAMETER AA-Answer) to the RCD Policy Server on whether the 639 requested resources are within the bounds authorized by the SCD 640 Policy Server. 642 9. The RCD Policy Server sends a decision (e.g. COPS-RSVP DEC) to 643 the Edge Router, possibly after modifying the parameters of the 644 resources to be reserved. 646 10. The Edge Router, possibly after waiting for end-to-end 647 negotiation for resources to be completed, sends a response to 648 the End Host (e.g. RSVP RESV) indicating that resource 649 reservation is complete or is progressing 651 6.2 Associated Model Authorization Token <> 653 Since the RCD Policy Server does not know which SMS and SCD PS are 654 involved in session establishment, the token must include: 656 - A correlation identifier. This is information that the SCD Policy 657 Server can use to correlate the resource reservation request with 658 the media authorized during session set up. The SCD Policy Server 659 is the only network entity that needs to interpret the contents 660 of the correlation identifier therefore, in this model, the 661 contents of the correlation identifier are implementation 662 dependent. Since the End Host is assumed to be untrusted, the SCD 663 Policy Server should take measures to ensure that the integrity 664 of the correlation identifier is preserved in transit; the exact 665 mechanisms to be used are also implementation dependent. 667 - The identity of the authorizing entity. This information is used 668 by the RCD Policy Server to determine which SCD Policy Server 669 should be used to verify the contents of the resource reservation 670 request. 672 In some environments, an RCD Policy Server may have no means for 673 determining if the identity refers to a legitimate SCD Policy 674 Server. In order to protect against redirection of authorization 675 requests to a bogus authorizing entity, the token should include: 677 - An authentication signature. This signature is calculated over 678 all other fields of the token using an agreed mechanism. The RCD 679 Policy Server must be able to verify the signature using 680 credentials of the signer to confirm a trust relationship. The 681 mechanism used by the RCD Policy Server is beyond the scope of 682 this document. 684 Framework for session set-up with media authorization 686 Note that the information in this token is the same as that in 687 Section 5.2 for the "One Policy Server" scenario. 689 6.3 Associated Model Protocol Impacts <> 691 The use of a media authorization token in this version of the 692 Associated Model requires the addition of new fields to several 693 protocols: 695 - Resource reservation protocol. A new protocol field or object 696 must be added to the resource reservation protocol to 697 transparently transport the token from the End Host to the Edge 698 Router. The content and internal structure of this object should 699 be opaque to the resource reservation protocol. 701 - Policy management protocol. A new protocol field or object must 702 be added to the policy management protocol to transport the token 703 from the SCD Policy Server to the Session Management Server and 704 from the Edge Router to the RCD Policy Server. The content and 705 internal structure of this object must be specified so that the 706 Policy Servers can distinguish between the elements of the token 707 described in Section 6.2. 709 - Session management protocol. A new protocol field or object must 710 be added to the session management protocol to transparently 711 transport the media authorization token from the Session 712 Management Server to the End Host. The content and internal 713 structure of this object should be opaque to the session 714 management protocol. 716 Note that these impacts are the same as those discussed in Section 717 5.3 for the "One Policy Server" scenario. However the use of two 718 Policy Servers has one additional impact: 720 - Authorization protocol. A new protocol field or object must be 721 added to the authorization protocol to transport the token from 722 the RCD Policy Server to the SCD Policy Server. The content and 723 internal structure of this object must be specified so that the 724 Policy Servers can distinguish between the elements of the token 725 described in Section 6.2. 727 Framework for session set-up with media authorization 729 7. The Non-Associated Model 731 In this scenario, the Session Management Servers and Edge Routers 732 are associated with different Policy Servers, the network entities 733 do not have a priori knowledge of the topology of the network and 734 there are no pre-established trust relationships between entities in 735 the Resource Control District and entities in the Service Control 736 District. The keys aspects of this scenario are the following: 738 - Policy decisions, including media authorization, are made by 739 Policy Servers. 741 - The PS in the Resource Control District is separate from the PS 742 in the Session Control District. 744 - There is a pre-defined trust relationship between the SMS and the 745 SCD PS. 747 - There is a pre-defined trust relationship between the ER and the 748 RCD PS. 750 - There are no pre-defined trust relationships between the ER and 751 SMS or between the RCD and SCD Policy Servers. 753 +--------+ 754 +------+ | | 755 | | 1 +--------------------+ 2 | SCD | 756 | |-------->| Session Management |----->| Policy | 757 | |<--------| Server |<-----| Server | 758 | | 4 +--------------------+ 3 | | 759 | End | +--------+ 760 | Host | 761 | | +--------+ 762 | | 5 +--------------------+ 6 | | 763 | |-------->| Edge |----->| RCD | 764 | |<--------| Router |<-----| Policy | 765 | | 8 +--------------------+ 7 | Server | 766 +------+ | | 767 +--------+ 769 Figure 5: The Non-Associated Model 771 7.1 Non-Associated Model Call Flow 773 In this model it is assumed that the policy servers make independent 774 decisions for their respective districts, obviating the need for 775 Framework for session set-up with media authorization 777 information exchange between policy servers. Communications between 778 network entities in this model is described below: 780 1. The End Host issues a session set-up request (e.g. SIP INVITE) to 781 the Session Manager indicating, among other things, the media 782 streams to be used in the session. As part of this step, the End 783 Host may authenticate itself to the Session Manager. 785 2. The Session Manager, possibly after waiting for negotiation of 786 the media streams to be completed, sends a policy decision 787 request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to 788 determine if the session set-up request should be allowed to 789 proceed. 791 3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 792 Session Manager, possibly after modifying the parameters of the 793 media to be used. Included in this response is a "token" that can 794 subsequently be used by the RCD Policy Server to determine what 795 media has been authorized. 797 4. The Session Manager sends a response to the End Host (e.g. SIP 798 200 or 183) indicating that session set-up is complete or is 799 progressing. Included in this response is a description of the 800 negotiated media along with the token from the SCD Policy Server. 802 5. The End Host issues a request (e.g. RSVP PATH) to reserve the 803 resources necessary to provide the required QoS for the media 804 stream. Included in this request is the token from the SCD Policy 805 Server provided via the Session Manager. 807 6. The Edge Router intercepts the reservation request and sends a 808 policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy 809 Server in order to determine if the resource reservation request 810 should be allowed to proceed. Included in this request is the 811 token from the SCD Policy Server provided by the End Host. 813 7. The RCD Policy Server uses this token to extract information 814 about the media that was authorized by the SCD Policy Server. The 815 RCD Policy Server uses this information in making its decision on 816 whether the resource reservation should be allowed to proceed. 818 The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 819 Edge Router, possibly after modifying the parameters of the 820 resources to be reserved. 822 8. The Edge Router, possibly after waiting for end-to-end 823 negotiation for resources to be completed, sends a response to 824 the End Host (e.g. RSVP RESV) indicating that resource 825 reservation is complete or is progressing 826 Framework for session set-up with media authorization 828 7.2 Non-Associated Model Authorization Token 830 In this model, the token must contain sufficient information to 831 allow the RCD Policy Server to make resource policy decisions 832 autonomously from the SCD Policy Server. The token is created using 833 information about the session received by the SMS. The information 834 in the token must include: 836 - Calling party IP address and port number (e.g. from SDP "c=" 837 parameter). 839 - Called party IP address and port number (e.g. from SDP "c=" 840 parameter). 842 - The characteristics of (each of) the media stream(s) authorized 843 for this session (e.g. codecs, maximum bandwidth from SDP "m=" 844 and/or "b=" parameters). 846 - The lifetime of (each of) the media stream(s) (e.g. from SDP "t=" 847 parameter). 849 - The authorization lifetime (e.g. the token should be valid for 850 only a few seconds after the start time of the session). 852 - The identity of the authorizing entity to allow for validation of 853 the token. 855 - An authentication signature used to prevent tampering with the 856 token and to provide the credentials of the authorizing entity. 857 This signature is calculated over all other fields of the token 858 using an agreed mechanism. The RCD Policy Server must be able to 859 verify the signature using credentials of the signer to confirm a 860 trust relationship. The mechanism used by the RCD Policy Server 861 is beyond the scope of this document. 863 7.3 Non-Associated Model Protocol Impacts 865 The use of a media authorization token in the Non-Associated Model 866 requires the addition of new fields to several protocols: 868 - Resource reservation protocol. A new protocol field or object 869 must be added to the resource reservation protocol to 870 transparently transport the token from the End Host to the Edge 871 Router. The content and internal structure of this object should 872 be opaque to the resource reservation protocol. 874 - Policy management protocol. A new protocol field or object must 875 be added to the policy management protocol to transport the token 876 Framework for session set-up with media authorization 878 from the SCD Policy Server to the Session Management Server and 879 from the Edge Router to the RCD Policy Server. The content and 880 internal structure of this object must be specified so that the 881 Policy Servers can distinguish between the elements of the token 882 described in Section 7.2. 884 - Session management protocol. A new protocol field or object must 885 be added to the session management protocol to transparently 886 transport the media authorization token from the Session 887 Management Server to the End Host. The content and internal 888 structure of this object should be opaque to the session 889 management protocol. 891 8. Conclusions 893 In this document we have defined three models for authorizing media 894 during session establishment: 896 - The Coupled Model which assumes a priori knowledge of network 897 topology and where pre-established trust relationships exist 898 between network entities. 900 - The Associated Model where there are common or trusted policy 901 servers but knowledge of the network topology is not known a 902 priori. 904 - The Non-Associated Model where knowledge of the network topology 905 is not known a priori, where there are different policy servers 906 involved and where a trust relationship does not exist between 907 the policy servers. 909 The Associated Model is applicable to environments where the network 910 elements involved in establishing a session have a pre-determined 911 trust relationship but where their identities must be determined 912 dynamically during session set up. The Non-Associated Model is 913 applicable to environments where there is a complex network topology 914 and/or where trust relationships between domains do not exist. 916 In any given network, one or more of these models may be applicable. 917 Indeed, the model to be used may be chosen dynamically during 918 session establishment based on knowledge of the end points involved 919 in the call. In all cases, however, there is no need for the End 920 Host, the Edge Router or the Session Management Server to understand 921 or interpret the authorization token - to them it is an opaque 922 protocol element that is simply copied from one container protocol 923 to another. 925 Framework for session set-up with media authorization 927 Finally, the framework defined in this document is extensible to any 928 kind of session management protocol coupled to any one of a number 929 of resource reservation and/or policy management protocols. 931 9. Security Considerations 933 The purpose of this draft is to describe a mechanism for media 934 authorization to prevent theft of service. It does not cover other 935 possible security breaches such as IP spoofing. 937 This draft assumes that trust relationships exist between various 938 network entities, as described in each of the models. The means for 939 establishing these relationships are beyond the scope of this 940 document. 942 For the authorization token to be effective, its integrity must be 943 guaranteed as it passes through untrusted network entities such as 944 the End Host. This can be achieved by using digital signatures. 946 References 948 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 949 BCP 9, RFC 2026, October 1996. 951 [2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, 952 August 2000 954 [3] P. Calhoun et al., "DIAMETER Base Protocol", Internet Draft 955 draft-calhoun-diameter-17.txt, September 2000. 957 [4] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January 958 2000. 960 [5] W.Marshall et al. "Integration of Resource Management and SIP", 961 Internet-Draft, draft-ietf-sip-manyfolks-resource-00, November 962 2000. 964 [6] W. Marshall et al., "SIP Extensions for Media Authorization", 965 Internet-Draft, draft-ietf-sip-call-auth-01.txt, February 2001. 967 [7] L. Hamer et al. "Session Authorization for RSVP", Internet- 968 Draft, draft-hkg-rap-rsvp-authsession-00.txt, February 2001. 970 [8] "PacketCable Dynamic Quality of Service Specification", 971 CableLabs, December 1999. 972 http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf 973 Framework for session set-up with media authorization 975 Acknowledgments 977 The authors would like to thank to following people for their useful 978 comments and suggestions related to this draft: Doug Reeves, Sam 979 Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois Audet, 980 Jerry Chow, Bill Marshall and many others. 982 Authors' Addresses 984 Louis-Nicolas Hamer 985 Nortel Networks 986 Ottawa, ON 987 CANADA 988 Email: nhamer@nortelnetworks.com 990 Bill Gage 991 Nortel Networks 992 Ottawa, ON 993 CANADA 994 Email: gageb@nortelnetworks.com 996 Full Copyright Statement 998 Copyright (C) The Internet Society (2001). All Rights Reserved. This 999 document and translations of it may be copied and furnished to 1000 others, and derivative works that comment on or otherwise explain it 1001 or assist in its implementation may be prepared, copied, published 1002 and distributed, in whole or in part, without restriction of any 1003 kind, provided that the above copyright notice and this paragraph 1004 are included on all such copies and derivative works. However, this 1005 document itself may not be modified in any way, such as by removing 1006 the copyright notice or references to the Internet Society or other 1007 Internet organizations, except as needed for the purpose of 1008 developing Internet standards in which case the procedures for 1009 copyrights defined in the Internet Standards process must be 1010 followed, or as required to translate it into. 1012 Expiration Date 1014 This memo is filed as , and 1015 expires August 31, 2001.