SIP Working Group L-N. Hamer Internet Draft B.Gage Document: draft-hamer-sip-session-auth-00.txt Nortel Networks November 9, 2000 Session setup with media authorization Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html The distribution of this memo is unlimited. This memo is filed as , and expires May 9, 2001. Please send comments to the authors. 1. Abstract Current proposals dealing with authorization of media streams for multimedia services like IP telephony and video assume a pre- established relationship between elements of the network (e.g. session managers, edge routers, policy servers and end hosts). In some environments, however, such pre-established relationships may not exist either due to the complexity of creating these associations a priori (e.g. in a network with many elements), or due to the different business entities involved (e.g. service provider and access provider), or due to the dynamic nature of these associations (e.g. in a mobile environment). In this document, we describe scenarios where there is no pre- established relationship between entities and describe mechanisms for exchanging information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the session and bearer control planes. Hamer,Gage Expires May 2001 [Page 1] Internet Draft Session setup with media authorization 2. Content Status of this Memo................................................1 1. Abstract........................................................1 2. Content.........................................................2 3. Introduction....................................................3 4. General Framework for Media Authorization.......................4 5. Definition of terms.............................................5 6. The Coupled Model...............................................7 7. The Associated Model...........................................11 7.1 Associated Model Authorization Ticket.........................11 7.2 Associated Model Call Flow....................................11 8. The Non-Associated Model.......................................14 8.1 Non-Associated Model Authorization Ticket.....................14 8.2 Establishing Trust............................................15 8.3 Non-Associated Model Call Flow................................16 9. Protocol Impacts...............................................20 9.1 SDP extensions................................................20 10. Conclusion....................................................21 11. Security Considerations.......................................21 12. References....................................................22 13. Acknowledgments...............................................23 14. Author's Addresses............................................23 Full Copyright Statement..........................................23 Expiration Date...................................................23 Hamer,Gage Expires May 2001 [Page 2] Internet Draft Session setup with media authorization 3. Introduction Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. There are several proposals that attempt to deal with these issues. "Interdomain IP Communications with QoS, Authorization and Usage Reporting" [1] discusses two options for QoS support for IP telephony: QoS Enabled and QoS Assured. The paper also describes how to introduce local policy decisions into call setup and presents two different models: the pull model and the push model. "SIP Extensions for Media Authorization" [3] describes the need for authorizing use of network resources and offers a mechanism that can be used for admission control. The PacketCable group defines similar mechanisms to deliver QoS for an IP call [9]. All of these proposals assume that a pre-established relationship exists between elements of the network (e.g. session managers, edge routers, policy servers and end hosts). In particular, they assume: - The same policy server makes decisions related to both service authorization and resource utilisation. This may not be possible if the service provider and access provider are different business entities or if the network is complex enough to warrant deployment of multiple policy servers. - The end host is connected to a known point in the network that defines the edge router and/or policy server for that host. This may not be true in a network with mobile hosts and/or mobile routers. In addition, the administrative burden of defining these associations may make this unfeasible in a fixed network with many hosts. - The session manager(s) and policy server(s) know of each others existence and have a pre-defined trust relationship. This may not be true if the service provider and access provider are different business entities or if the network is complex enough to warrant deployment of multiple managers and servers or if the network includes mobile hosts and/or mobile routers. This document describes mechanisms for exchanging information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the session and bearer control planes. In particular, it includes scenarios where there are no pre-established relationships between network entities. Media authorization makes use of a "ticket" that provides capabilities similar to that of a token in [3] and of a gate in [9]. The ticket is generated by the session manager (or a policy server) Hamer,Gage Expires May 2001 [Page 3] Internet Draft Session setup with media authorization and relayed through the end host to the edge router where it is used as part of the policy-controlled flow admission process. The ticket contains information describing the media stream authorized by the session manager along with the credentials of the session manager that can be used to validate the ticket. 4. General Framework for Media Authorization Current proposals describing how to perform media authorization assume a pre-established relationship between network entities. In this draft, we will describe alternative ways of providing media authorization when there is no pre-established relationship between network entities and the internal network topology of a domain is not known a priori. We believe this assumption is more general and removes unnecessary constraints imposed by the existing solutions. Session control mechanisms deal with session initiation and setup between parties. A session management server must authenticate the involved parties, authorize the session and specify the QoS permitted. There are multiple kinds of sessions that can be established, using any one of several different signalling protocols. For example, either SIP or H.323 protocol can be used to establish a voice and/or video session. Resource reservation mechanisms deal with providing end-to-end QoS, which is critical in order to provide quality multimedia services. Resource reservation signalling conveys the QoS needs of the applications to the access network. Elements of the access network use the QoS attributes signalled by the applications to determine the network resources that need to be allocated for use by the end host. One of the widely accepted resource reservation signalling protocols used between the end host and the edge router is RSVP. Between the edge router and other network elements, other mechanisms (e.g. DiffServ) may be used to ensure the flow gets the proper QoS treatment. For clarity, this draft will illustrate the media authorization concepts using SIP for session signalling, RSVP for resource reservation and COPS for interaction with the policy servers. Note, however, that the proposed framework could be applied to a multimedia services scenario using different signalling protocols. Hamer,Gage Expires May 2001 [Page 4] Internet Draft Session setup with media authorization 5. Definition of terms Figure 1 introduces a generic model for session establishment, QoS and policy. +-------------------------------------+ +---+ | SCD - Service Control Domain | | | | +-----------------------+ +--------+| | | | |Session management | |Policy || | | | |server | |Server || | | | | +---------+ +------+ | | +----+||<->| | | | |SIP Proxy| |PEP |<-|-|->|PDP ||| | | | | +---------+ +------+ | | +----+|| | | | +-----------------------+ +--------+| | | | | | | +-------------------------------------+ | I | | N | +-------------------------------------+ | T | | BCD - Bearer Control Domain | | E | | | | R | | | | N | | +------------+ +-------------+ | | E | +----------+ | |Edge Router | |Policy Server| | | T | | End | | | | | | | | | | Host | | |+----------+| |+----------+ | | | | |+--------+| | ||RSVP Agent|| ||PDP | | | | | ||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| | ||Client || | |+----------+| | | | | | |+--------+| | || PEP || | | | | | ||SIP User|| | |+----------+| | | | | | ||Agent || | +------------+ +-------------+ | | | |+--------+| | | | | +----------+ +-------------------------------------+ +---+ Figure 1: Generic media authorization network model BCD - Bearer Control Domain: The Bearer Control Domain is a logical grouping of elements that provide connectivity along the packet forwarding paths to and from an End Host. The BCD contains ER and PS entities whose responsibilities include management of resources along the packet forwarding paths. EH - End Host: The End Host is a device used by a subscriber to access network services. The End Host includes a client for requesting network services (e.g. through SIP) and a client for requesting network resources (e.g. through RSVP). Hamer,Gage Expires May 2001 [Page 5] Internet Draft Session setup with media authorization ER - Edge Router: The Edge Router is a network element connecting the end host to the rest of the Bearer Control Domain. The Edge Router contains a PEP to enforce policies related to resource usage in the BCD by the End Host. It also contains a signalling agent (e.g. for RSVP) for handling resource reservation requests from the End Host. PDP - Policy Decision Point: The PDP is a logical entity located in the Policy Server that is responsible for authorizing or denying access to services and/or resources. PEP - Policy Enforcement Point: The PEP is a logical entity that enforces policy decisions made by the PDP. Note that other PEPs may reside in other network elements not shown in the model of Figure 1, however they will not be discussed in this document. PS - Policy Server: The Policy Server is a network element that includes a PDP. Note that there may be a PS in the Service Control Domain to control use of services and there may be a separate PS in the Bearer Control Domain to control use of resources along the packet forwarding path. Note also that network topology may require multiple Policy Servers within either domain, however they provide consistent policy decisions to offer the appearance of a single PDP in each domain. SCD - Service Control Domain: The Service Control Domain is a logical grouping of elements that offer applications and content to subscribers of their services. In this document, session management is considered a service, therefore the Session Management Server resides in the SCD along with a PS. SMS - Session Management Server: The Session Management Server is a network element providing session management services (e.g. telephony call control). The Session Management Server contains a PEP to enforce policies related to use of services by the End Host. It also contains a signalling agent or proxy (e.g. for SIP) for handling service requests from the End Host. For clarification, we use the following conventions for describing messages throughout the entire document: XXXo = messages from the originating (calling) party to terminating (called) party. XXXt = messages from the terminating (called) party to the originating (calling) party. Hamer,Gage Expires May 2001 [Page 6] Internet Draft Session setup with media authorization 6. The Coupled Model Current proposals dealing with authorization of media streams for multimedia services assume a pre-established relationship between elements of the network (e.g. session managers, edge routers, policy servers and end hosts). We refer to this as the "coupled model", indicating the tight relationship between entities that is presumed. +-------+ +------+ | | | | 1 +-------------------+ 2 | | | |-------->| Session manager |----->| | | |<--------| |<-----| | | | 4 +-------------------+ 3 | | | End | | Policy| | Host | | Server| | | | | | | 5 +-------------------+ 6 | | | |-------->| Edge |----->| | | |<--------| Router |<-----| | | | 8 +-------------------+ 7 | | +------+ | | +-------+ Figure 2: The Coupled Model This model is used in "SIP Extensions for Media Authorization" [3]. In this model, it is assumed that there is one Policy Server serving both the Service Control and Bearer Control domains and that there is a pre-defined relationship between the PS and SMS and between the PS and ER. Communications between these entities are then possible as shown in the call flows presented in Figure 3, taken from [3]. Hamer,Gage Expires May 2001 [Page 7] Internet Draft Session setup with media authorization EH SMS PS ER INTERNET | | | | | |1 Invite | | | | |------------->|2 Invite | | | | |------------------------------------------------>| | | | | 3 183| | |<------------------------------------------------| | |4 Auth. Profile| | | | |-------------->| | | | |5 Auth. Token | | | |6 183 |<--------------| | | |<-------------| | | | |7 Prack | | | | |--------------------------------------------------------------->| | | | 8 200 OK (of Prack)| |<---------------------------------------------------------------| |9 RSVP PATHo | | | | |--------------------------------------------->| | | | | 10 COPS REQ | | | | |<--------------| | | | |11 COPS DEC | | | | |-------------->|12 RSVP PATHo | | | | |---------------->| | | | | 13 RSVP RESVo| | | | |<----------------| | | | 14 COPS REQ| | | | |<--------------| | | | |15 COPS DEC | | | | |-------------->| | | | |16 COPS RPT | | | | |<--------------| | | | | 17 RSVP RESVo | | |<---------------------------------------------| | |18 COMET | | | | |--------------------------------------------------------------->| | | | 19 200 OK (of COMET) | |<---------------------------------------------------------------| | | | | 20 180 RING| | |<------------------------------------------------| | 21 180 RING| | | | |<-------------| | | | |22 PRACK | | | | |--------------------------------------------------------------->| | | | 23 200 OK (of Prack)| |<---------------------------------------------------------------| | | | | 24 200 OK| | 25 200 OK |<------------------------------------------------| |<-------------| | | | | 26 ACK | | | | |--------------------------------------------------------------->| Figure 3: Message flows in the Coupled Model [3] Hamer,Gage Expires May 2001 [Page 8] Internet Draft Session setup with media authorization The detailed, step by step description of this call flow can be found in [3]. The salient points of this exchange are the following: - When the SMS receives the 183 message, it can determine the end- points, bandwidth and characteristics of the media exchange from the SDP parameters. - The SMS will then convey this information to the PS, which will store this information. - The PS then generates a token that references this information within the Policy Server's local storage and returns the token to the SMS. - The SMS will then forward this token in the 183 message to the end host. - The end host must include this token as-is in the bearer path setup message; in this example an RSVP PATH message is used to reserve resources along the bearer path. - This RSVP PATH message is intercepted by the PEP located in the ER. The PEP encapsulates the RSVP PATH message in a COPS message and sends it to the PS. - The PS extracts the token from the COPS-RSVP message and uses it to retrieve the information previously stored during its exchange with the SMS. The PS can then verify that the resources requested in the RSVP PATH message are compatible with what was authorized by the SMS. As indicated earlier, there are a number of issues with this model: - The same policy server makes decisions related to both service authorization and resource utilisation. This is only possible if the service provider and access provider are one and the same business entity and if the network is simple enough to warrant deployment of a single policy server. - The end host is connected to a known point in the network that defines the edge router and policy server for that host. This is only possible in a network with fixed hosts and fixed routers where the administrative burden of defining these associations make this a feasible undertaking. - The session manager and policy server know of each others existence and have a pre-defined trust relationship. This is only possible if the service provider and access provider are one and Hamer,Gage Expires May 2001 [Page 9] Internet Draft Session setup with media authorization the same business entity or if the network is simple enough to allow a priori creation of bilateral trust relationships. This model is valid in those environments where the issues listed above are of no consequence, but it is not a universal solution. Sections 7 and 8 describe other scenarios that relax the close coupling requirements. Hamer,Gage Expires May 2001 [Page 10] Internet Draft Session setup with media authorization 7. The Associated Model In this scenario, there are multiple instances of the Session Management Servers, Edge Routers and Policy Servers. This leads to a network of sufficient complexity that it precludes distributing knowledge of network topology to all network entities. The key aspects of this scenario are the following: - Policy decisions, including authorization, are made by a Policy Server as in [3]. - In contrast to [3], the multiple edge routers, session and policy servers in the network mean that the combination of network entities involved in establishing the session is not known a priori. - There is a pre-defined, trusted relationship between the SMS and the PS and between the ER and the PS. 7.1 Associated Model Authorization Ticket Since the ER does not know which SMS and PS are involved in session establishment, the token described in [3] must be extended to include the identity of the authorizing entity. The information in the resulting ticket must include: - Authorization token, as in [3], used to reference session state information maintained by the authorizing PS. - Identity of the authorizing entity to allow for validation of the ticket. - An authorization signature used to prevent tampering with the ticket (e.g. to prevent redirection of authorization requests to a bogus authorizing entity). The signature is typically a one-way hash calculated over the other fields of the ticket using a key associated with the authenticator. The key may be either a public/private key if public key encryption is used (e.g. PKI) or a private key if shared private key encryption is used (e.g. Kerberos). 7.2 Associated Model Call Flow Figure 4 contains the associated model call flow with the authorization ticket concept. Either the SMS or the PS can act as the authenticator; this example shows the PS acting in that role. Hamer,Gage Expires May 2001 [Page 11] Internet Draft Session setup with media authorization EH SMS PS ER INTERNET | | | | | |1 Invite | | | | |------------->|2 Invite | | | | |------------------------------------------------>| | | | | 3 183| | |<------------------------------------------------| | |4 Auth. Profile| | | | |-------------->| | | | |5 Auth. Ticket | | | |6 183 |<--------------| | | |<-------------| | | | |7 Prack | | | | |--------------------------------------------------------------->| | | | 8 200 OK (of Prack)| |<---------------------------------------------------------------| |9 RSVP PATHo | | | | |--------------------------------------------->| | | | | 10 COPS REQ | | | | |<--------------| | | | |11 COPS DEC | | | | |-------------->|12 RSVP PATHo | | | | |---------------->| | | | | 13 RSVP RESVo| | | | |<----------------| | | | 14 COPS REQ| | | | |<--------------| | | | |15 COPS DEC | | | | |-------------->| | | | |16 COPS RPT | | | | |<--------------| | | | | 17 RSVP RESVo | | |<---------------------------------------------| | |18 COMET | | | | |--------------------------------------------------------------->| | | | 19 200 OK (of COMET) | |<---------------------------------------------------------------| | | | | 20 180 RING| | |<------------------------------------------------| | 21 180 RING| | | | |<-------------| | | | |22 PRACK | | | | |--------------------------------------------------------------->| | | | 23 200 OK (of Prack)| |<---------------------------------------------------------------| | | | | 24 200 OK| | 25 200 OK |<------------------------------------------------| |<-------------| | | | | 26 ACK | | | | |--------------------------------------------------------------->| Figure 4: Associated Model Call Flow with Authorization Ticket Hamer,Gage Expires May 2001 [Page 12] Internet Draft Session setup with media authorization The detailed, step by step description of this call flow can be found in [3]. The salient points of this exchange are the following: 1- The End Host sends an INVITE to the called party using the SMS. 2- The SMS forwards the INVITE to the called party. 3- The called party responds with a 183 session in progress. 4- When the SMS receives the 183 message, it can determine the end- points, bandwidth and characteristics of the media exchange from the SDP parameters. The SMS will then convey this information to the PS for validation of the set up attempt. 5- If the PS deems the set up attempt to be valid, it will store the media information for this call. It then returns a signed ticket to the SMS that includes the identity of the PS plus a reference to the session media information within the Policy Server's local storage. 6- The SMS will then forward this ticket in the 183 message to the end host. 9- The end host must include this ticket as-is in the bearer path setup message; in this example an RSVP PATH message is used to reserve resources along the bearer path. 10- This RSVP PATH message is intercepted by the PEP located in the ER. The PEP extracts the identity of the PS from the ticket, encapsulates the RSVP PATH message in a COPS message and sends it to the specified PS. 11- The PS extracts the ticket from the COPS-RSVP message and uses it to retrieve the information previously stored during its exchange with the SMS. The PS can then verify that the resources requested in the RSVP PATH message are compatible with what was authorized by the SMS. Note that steps 9 to 17 must be repeated in the reverse direction since RSVP reserves resources in one direction only. Separate RSVP transactions will be required for every media stream flowing in either direction. As indicated earlier, this solution permits a common PS to validate and authorize the media request without requiring a priori knowledge of the network entities involved in session establishment. Hamer,Gage Expires May 2001 [Page 13] Internet Draft Session setup with media authorization 8. The Non-Associated Model In this scenario, the Session Management Servers and Edge Routers are associated with different Policy Servers, the network entities do not have a priori knowledge of the topology of the network and there is no pre-established trust relationship between entities in the Bearer Control Domain and entities in the Service Control Domain. The keys aspects of this scenario are the following: - Policy decisions, including authorization, are made by Policy Servers as in [3]. - In contrast to [3] and to the scenario in Section 7, the PS in the Bearer Control Domain is separate from the PS in the Session Control Domain. - There is a pre-defined, trusted relationship between the SMS and the SCD PS. - There is a pre-defined, trusted relationship between the ER and the BCD PS. - There are no pre-defined, trusted relationships between the ER and SMS or between the BCD and SCD Policy Servers. 8.1 Non-Associated Model Authorization Ticket The immediate impact of this model is that the contents of the ticket must be changed - the ticket can no longer refer to information held in local storage at the PS and must be secured against counterfeiting and replay attacks. The ticket is created using information about the session received by the SMS. The information in the ticket must include: - Calling party IP address and port number (e.g. from SDP "c=" parameter). - Called party IP address and port number (e.g. from SDP "c=" parameter). - Call identifier (e.g. from SIP "CALL-ID" parameter). - The characteristics of (each of) the media stream(s) authorized for this call (e.g. codecs, maximum bandwidth from SDP "m=" and/or "b=" parameters). - Lifetime of (each of) the media stream(s) (e.g. from SDP "t=" parameter). Hamer,Gage Expires May 2001 [Page 14] Internet Draft Session setup with media authorization - Authorization lifetime; the ticket should be valid for only a few seconds after the start time of the session. - Identity of the authorizing entity to allow for validation of the ticket. - Authorization signature used to prevent tampering with the ticket and to provide the credentials of the authorizing entity. The signature is typically a one-way hash calculated over the other fields of the ticket using a key associated with the authenticator. The key may be either a public/private key if public key encryption is used (e.g. PKI) or a private key if shared private key encryption is used (e.g. Kerberos). 8.2 Establishing Trust Because there is no pre-established trust relationship between the entities of the two domains, this relationship must be established dynamically. In this scenario, we assume there is a third party that can be trusted by all elements of the bearer control and service control domains. This third party's main role is to act as a Key Exchange Server (KES). If public key encryption is used (e.g. PKI), the SCD and BCD entities know the public key of the KES and the KES knows the public keys of the relevant SCD and BCD entities. If shared private key encryption is used (e.g. Kerberos), the SCD and BCD entities each know (one of) the private key(s) of the KES and the KES knows (one of) the private key(s) of the relevant SCD and BCD entities. Figure 5 presents the network diagram for this model. Hamer,Gage Expires May 2001 [Page 15] Internet Draft Session setup with media authorization +-------------------------------------+ +-----+ | SCD - Service Control Domain | |+---+| | +-----------------------+ +--------+| || || | |Session management | |Policy || || || | |server | |Server || || || | | +---------+ +------+ | | +----+|| || K || | | |SIP Proxy| |PEP |<-|-|->|PDP |<---->| E || | | +---------+ +------+ | | +----+|| || S || | +-----------------------+ +--------+| || || | |<->|| || +-------------------------------------+ || || +->| || +-------------------------------------+ | || || | BCD - Bearer Control Domain | | |+---+| | | | | | | | | | | | +------------+ +-------------+ | | | | +----------+ | |Edge Router | |Policy Server| | | | I | | End | | | | | | | | | N | | Host | | |+----------+| |+----------+ | | | | T | |+--------+| | ||RSVP Agent|| ||PDP |<---|-+ | E | ||RSVP ||<->| |+----------+|<-->|+----------+ | | | R | ||Client || | |+----------+| | | |<->| N | |+--------+| | || PEP || | | | | E | ||SIP User|| | |+----------+| | | | | T | ||Agent || | +------------+ +-------------+ | | | |+--------+| | | | | +----------+ +-------------------------------------+ +-----+ Figure 5: Network Model with Key Exchange Server. In the PKI terminology, the KES is referred to as a Certificate Authority. In Kerberos terminology, the KES is referred to as a Key Distribution Centre. 8.3 Non-Associated Model Call Flow Figure 6 contains the detailed non-associated model call flow with the authorization ticket concept. Either the SMS or the SP PS can act as the authenticator for the service control domain; this example shows the SMS acting in that role. Hamer,Gage Expires May 2001 [Page 16] Internet Draft Session setup with media authorization EH SMS KES PS ER INTERNET | | | | | | |1 Invite | | | | | |---------->|2 Invite | | | | | |---------------------------------------------------->| | | | | | 3 183| |4 183 |<----------------------------------------------------| |<----------| | | | | |5 Prack | | | | | |---------------------------------------------------------------->| | | | | 6 200 OK (of Prack)| |<----------------------------------------------------------------| |7 PATHo | | | | | |-------------------------------------------------->| | | | | | 8 COPS REQ | | | | |9 Get key |<-------------| | | | |<-----------| | | | | |10 Return key | | | | |----------->| | | | | | |11 COPS DEC | | | | | |------------->|12 PATHo | | | | | |------------>| | | | | |13 RESVo | | | | | |<------------| | | | | 14 COPS REQ| | | | | |<-------------| | | | | |15 COPS DEC | | | | | |------------->| | | | | |16 COPS RPT | | | | | |<-------------| | | | | | 17 RESVo | | |<--------------------------------------------------| | |18 COMET | | | | | |---------------------------------------------------------------->| | | | | 19 200 OK (of COMET) | |<----------------------------------------------------------------| | | | | | 20 180 RING| | |<----------------------------------------------------| |21 180 RING| | | | | |<----------| | | | | |22 PRACK | | | | | |---------------------------------------------------------------->| | | | | 23 200 OK (of Prack)| |<----------------------------------------------------------------| | | | | | 24 200 OK| |25 200 OK |<----------------------------------------------------| |<----------| | | | | |26 ACK | | | | | |---------------------------------------------------------------->| Figure 6: Non-Associated Model Call Flow with Authorization Ticket Hamer,Gage Expires May 2001 [Page 17] Internet Draft Session setup with media authorization The following is a summary of the call flow: 1- The End Host sends an INVITE to the called party using the SMS. 2- The SMS forwards the INVITE to the called party. 3- The called party responds with a 183 session in progress. 4- When the SMS receives the 183 message, it can determine the end- points, bandwidth and characteristics of the media exchange from the SDP parameters. The SMS can then generate a ticket with this information, sign the ticket with its (shared) private key, insert the signed ticket into the 183 message and forward the 183 message to the end host. 5, 6- The PRACK and 200 OK (of PRACK) are used for reliability purpose as described in [10]. 7- The End Host can then start the resource reservation process by sending a RSVP PATH message with the signed ticket included. 8- When the RSVP PATH message reaches the ER, the PEP at the ER encapsulates the PATH in a COPS-RSVP message and forwards it to the BCD PS. 9,10- The BCD PS will receive the COPS-RSVP PATH message and will inspect the ticket. From the ticket, the PS will get the SMS identity and query the KES for the public or shared private key of this SMS. Note that the key distributed by the KES will usually have a finite lifetime specified by the KES. The BCD PS can cache the public or shared private key for further use and thus skip the interaction with the KES if other session establishments involving this SMS are received by the BCD PS before the key expires. 11- The BCD PS verifies the authenticity of the ticket by using either the KES public key (e.g. for PKI) or the KES shared private key (e.g. for Kerberos). It then compares the resources requested in the RSVP path message with the authorized media in the ticket to ensure it is equivalent or of a lower authorized level. The BCD PS can then forward its policy decision to the PEP at the ER. 12- The PEP performs its admission control functions and, if the flow is admitted, it then forwards the RSVP Path message to the terminating party. 13 to 26-The remaining steps are similar to the call flows described in [3]. Hamer,Gage Expires May 2001 [Page 18] Internet Draft Session setup with media authorization Note that steps 7 to 17 must be repeated in the reverse direction since RSVP reserves resources in one direction only. Separate RSVP transactions will be required for every media stream flowing in either direction. As specified earlier, this solution allows the ticket to be sent from the SMS to the BCD PS without the SMS knowing the topology of the network. Furthermore, by using a trusted third party as a KES, we can dynamically establish (indirectly) a trust relationship between the SMS and BCD PS, eliminating the management burden of pre-establishing trust relationships. Hamer,Gage Expires May 2001 [Page 19] Internet Draft Session setup with media authorization 9. Protocol Impacts The introduction of the media authorization ticket concept requires the addition of new fields to several protocols: - Resource reservation protocol. New elements must be added to the resource reservation protocol to transparently transport the ticket from the End Host to the Edge Router. Extensions to RSVP to support a media authorization ticket object will be defined in a separate document. - Policy management protocol. New elements must be added to the policy management protocol to transparently transport the ticket from the Edge Router to the AP Policy Server. Extensions to COPS- RSVP to support a media authorization ticket object will be defined in a separate document. - Session management protocol. New elements must be added to the session management protocol to transparently transport the media authorization ticket from the Session Management Server to the End Host. Extensions to SIP/SDP to support ticketing are defined in the following section. 9.1 SDP extensions In [3], the authorization token is defined as part of the SIP header. However, since each media stream is set up independently in the bearer plane (e.g. each media stream will require a separate RSVP transaction), separate authorization must be provided for each media stream. The SDP part of a SIP message provides the media description and is the natural place for adding media authorization ticket support. The proposed authorization extensions to the Session Description Protocol (SDP)[11] are the following: - Authorization type: a=authType: where authType = "Associated" // Defined in Section 7 | "NonAssociated" // Defined in Section 8 | "Coupled" // Defined in [3] - Authorization token a=authToken: - Authorization lifetime: a=authTime: - Identity of the authorizing entity: a=authIdentity: Hamer,Gage Expires May 2001 [Page 20] Internet Draft Session setup with media authorization - Authorization signature: a=authSign: where the fields covered by the digital signature are defined by the 10. Conclusion In this draft we have defined three models for authorizing media during session establishment: - The Coupled Model reflects work currently described in [3]. This model assumes knowledge of network topology and pre-established trust relationships that may not be valid in all scenarios. We therefore defined two additional models: - The Associated Model in which common policy servers and trust relationships exist but knowledge of the network topology is not known a priori, and - The Non-Associated Model where knowledge of the network topology is not known a priori, where there are different policy servers involved and where trust relationships do not exist a priori. The Associated Model is applicable to environments where the network elements involved in establishing a session must be determined dynamically during session set up. The Non-Associated Model, which is the most generic, is applicable to environments where there is a complex network topology and/or where there are different business entities involved. In any given network, one or more of these models may be applicable. Indeed, the model to be used may be chosen dynamically by the SMS during session establishment based on knowledge of the end points involved in the call. Finally, the solutions defined in this draft can be extended to environments using protocols other than SIP and RSVP. The framework is extensible to any kind of session management protocol coupled to any one of a number of resource reservation protocols. 11. Security Considerations The purpose of this draft is to describe a mechanism for media authorization to prevent theft of service. It does not cover other possible security breaches such as IP spoofing. Hamer,Gage Expires May 2001 [Page 21] Internet Draft Session setup with media authorization 12. References [1] H. Sinnreich, S. Donovan, D. Rawlins, "Interdomain IP Communications with QoS, Authorization and Usage Reporting", Internet-Draft, draft-sinnreich-interdomain-sip-qos-01.txt, February 2000. [2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, August 2000 [3] W. Marshall et al., "SIP Extensions for Media Authorization", Internet-Draft, draft-dcsgroup-sip-call-auth-02.txt, June 2000. Also draft-ietf-sip-call-auth-00.txt, November 2000. [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [5] W.Marshall et al. " Integration of Resource Management and SIP", Internet-Draft, draft-manyfolks-sip-resource-01.txt, June 2000. [6] Handley, Schulzrinne, Scholler, Rosenberg. " SIP: Session Initiation Protocol", Internet-Draft, draft-ietf-sip- rfc2543bis- 01.txt, August 2000. [7] H. Sinnreich, S. Donovan, D. Rawlins, S. Thomas, S. Donovan. " AAA Usage for IP Telephony with QoS ", Internet-Draft, draft- sinnreich-aaa-interdomain-sip-qos-osp-00.txt, July 2000. [8] S. Yadav et al. " Identity Representation for RSVP ", Internet- Draft, draft-ietf-rap-rsvp-newidentity-01.txt, June 2000. [9] PacketCable. " PacketCable dynamic quality of service specification ", Cable Labs, December 1999. http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf [10] J.Rosenberg, H.Schulzrinne. "Reliability of Provisional Responses in SIP" , Internet-Draft, draft-ietf-sip-100rel- 02.txt, December 2000. [11] M. Handley, V. Jacobson. "SDP: Session Description Protocol", RFC 2327, April 1998. Hamer,Gage Expires May 2001 [Page 22] Internet Draft Session setup with media authorization 13. Acknowledgments The authors would like to thank to following people for their useful comments and suggestions related to this draft: Doug Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois Audet and many others. 14. Author's Addresses Louis-Nicolas Hamer Nortel Networks Ottawa, ON CANADA Email: nhamer@nortelnetworks.com Bill Gage Nortel Networks Ottawa, ON CANADA Email: gageb@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Expiration Date This memo is filed as , and expires May 9, 2001. Hamer,Gage Expires May 2001 [Page 23]