diff options
Diffstat (limited to 'doc/rfc/rfc3521.txt')
| -rw-r--r-- | doc/rfc/rfc3521.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc3521.txt b/doc/rfc/rfc3521.txt new file mode 100644 index 0000000..15da772 --- /dev/null +++ b/doc/rfc/rfc3521.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group L-N. Hamer +Request for Comments: 3521 B. Gage +Category: Informational Nortel Networks + H. Shieh + AT&T Wireless + April 2003 + + + Framework for Session Set-up with Media Authorization + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + Establishing multimedia streams must take into account requirements + for end-to-end QoS, authorization of network resource usage and + accurate accounting for resources used. During session set up, + policies may be enforced to ensure that the media streams being + requested lie within the bounds of the service profile established + for the requesting host. Similarly, when a host requests resources + to provide a certain QoS for a packet flow, policies may be enforced + to ensure that the required resources lie within the bounds of the + resource profile established for the requesting host. + + To prevent fraud and to ensure accurate billing, this document + describes various scenarios and mechanisms that provide the linkage + required to verify that the resources being used to provide a + requested QoS are in-line with the media streams requested (and + authorized) for the session. + + + + + + + + + + + + + + +Hamer, et al. Informational [Page 1] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + +Table of Contents + + 1. Introduction....................................................2 + 2. Conventions used in this document...............................3 + 3. Definition of terms.............................................4 + 4. The Coupled Model...............................................5 + 4.1 Coupled Model Message Flows...............................6 + 4.2 Coupled Model Authorization Token.........................8 + 4.3 Coupled Model Protocol Impacts............................8 + 5. The Associated Model <<using One Policy Server>>................8 + 5.1 Associated Model Message Flows + <<using One Policy Server>>...............................9 + 5.2 Associated Model Authorization Token + <<using One Policy Server>>..............................11 + 5.3 Associated Model Protocol Impacts + <<using One Policy Server>>..............................11 + 5.4 Associated Model Network Impacts + <<using One Policy Server>>..............................12 + 6. The Associated Model <<using Two Policy Servers>>..............12 + 6.1 Associated Model Message Flows + <<using Two Policy Servers>>.............................13 + 6.2 Associated Model Authorization Token + <<using Two Policy Servers>>.............................15 + 6.3 Associated Model Protocol Impacts + <<using Two Policy Servers>>.............................16 + 7. The Non-Associated Model........................................16 + 7.1 Non-Associated Model Message Flow........................17 + 7.2 Non-Associated Model Authorization Token.................19 + 7.3 Non-Associated Model Protocol Impacts....................19 + 8. Conclusions....................................................20 + 9. Security Considerations........................................21 + 10. Normative References...........................................22 + 11. Informative References.........................................23 + 12. Acknowledgments................................................23 + 13. Authors' Addresses.............................................24 + 14. Full Copyright Statement.......................................25 + +1. Introduction + + Various mechanisms have been defined through which end hosts can use + a session management protocol (e.g., SIP [6]) to indicate that QoS + requirements must be met in order to successfully set up a session. + However, a separate protocol (e.g., RSVP [7]) is used to request the + resources required to meet the end-to-end QoS of the media stream. + To prevent fraud and to ensure accurate billing, some linkage is + + + + + + +Hamer, et al. Informational [Page 2] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + required to verify that the resources being used to provide the + requested QoS are in-line with the media streams requested (and + authorized) for the session. + + This document describes such a linkage through use of a "token" that + provides capabilities similar to that of a gate in [12] and of a + ticket in the push model of [10]. The token is generated by a policy + server (or a session management server) and is transparently relayed + through the end host to the edge router where it is used as part of + the policy-controlled flow admission process. + + In some environments, authorization of media streams can exploit the + fact that pre-established relationships exist between elements of the + network (e.g., session management servers, edge routers, policy + servers and end hosts). Pre-established relationships assume that + the different network elements are configured with the identities of + the other network elements and, if necessary, are configured with + security keys, etc. required to establish a trust relationship. In + other 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 these various scenarios and the + mechanisms used for exchanging information between network elements + in order to authorize the use of resources for a service and to + coordinate actions between the session and resource management + entities. Specific extensions to session management protocols (e.g., + SIP [6], H.323), to resource reservation protocols (e.g., RSVP [4], + YESSIR) and to policy management protocols (e.g., COPS-PR [9], COPS- + RSVP [3]) required to realize these scenarios and mechanisms are + beyond the scope of this document. + + For clarity, this document 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 framework could be applied to a multimedia services + scenario using different signalling protocols. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [1]. + + + + + +Hamer, et al. Informational [Page 3] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + +3. Definition of terms + + Figure 1 introduces a generic model for session establishment, QoS + and policy enforcement. + + +-------------------------------------+ +---+ + | SCD - Service Control Domain | | | + | +-----------------------+ +--------+| | I | + | |Session management | |Policy || | n | + | |server | |Server || | t | + | | +---------+ +------+ | | +----+||<->| e | + | | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r | + | | +---------+ +------+ | | +----+|| | - | + | +-----------------------+ +--------+| | c | + | | | o | + +-------------------------------------+ | n | + | n | + +-------------------------------------+ | e | + | RCD - Resource Control Domain | | c | + | | | t | + | | | i | + | +------------+ +-------------+ | | n | + +----------+ | |Edge Router | |Policy Server| | | g | + | End | | | | | | | | | + | Host | | |+----------+| |+----------+ | | | N | + |+--------+| | ||RSVP Agent|| ||PDP | | | | e | + ||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t | + ||Client || | |+----------+| | | | | w | + |+--------+| | || PEP || | | | | o | + ||SIP User|| | |+----------+| | | | | r | + ||Agent || | +------------+ +-------------+ | | k | + |+--------+| | | | | + +----------+ +-------------------------------------+ +---+ + + Figure 1: Generic media authorization network model + + 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). + + ER - Edge Router: The Edge Router is a network element connecting the + end host to the rest of the Resource Control Domain. The Edge Router + contains a PEP to enforce policies related to resource usage in the + Resource Control Domain by the End Host. It also contains a + signalling agent (e.g., for RSVP) for handling resource reservation + requests from the End Host. + + + + +Hamer, et al. Informational [Page 4] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + 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 Resource 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. + + RCD - Resource Control Domain: The Resource Control Domain is a + logical grouping of elements that provide connectivity along the + packet forwarding paths to and from an End Host. The RCD contains ER + and PS entities whose responsibilities include management of + resources along the packet forwarding paths. Note that there may be + one or more RCDs within an autonomous 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. The Session Management Server resides + in the SCD along with a PS. Note that there may be one or more SCDs + within an autonomous domain. + + 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. + +4. The Coupled Model + + In some environments, a pre-established trust relationship exists + between elements of the network (e.g., session management servers, + edge routers, policy servers and end hosts). We refer to this as the + "coupled model", indicating the tight relationship between entities + that is presumed. The key aspects of this scenario are the + following: + + + + + +Hamer, et al. Informational [Page 5] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + - Policy decisions, including media authorization, are made by a + single Policy Server. + + - The Edge Router, Session Management Servers and Policy Server + involved in establishing the session are known a priori. For + example, the End Host may be configured to use a Session + Management Server associated with the Edge Router to which the EH + is connected. + + - There are pre-defined trust relationships between the SMS and the + PS and between the ER and the PS. + + +--------+ + +------+ | | + | | 1 +--------------------+ 2 | | + | |-------->| Session Management |----->| | + | |<--------| Server |<-----| | + | | 4 +--------------------+ 3 | | + | End | | Policy | + | Host | | Server | + | | | | + | | 5 +--------------------+ 6 | | + | |-------->| Edge |----->| | + | |<--------| Router |<-----| | + | | 8 +--------------------+ 7 | | + +------+ | | + +--------+ + + Figure 2: The Coupled Model + +4.1 Coupled Model Message Flows + + In this model, it is assumed that there is one Policy Server serving + both the Service Control and Resource Control Domains and that there + are pre-defined trust relationships between the PS and SMS and + between the PS and ER. Communications between these entities are + then possible as described below. Only the originating side flows + are described for simplicity. The same concepts apply to the + terminating side. + + 1. The End Host issues a session set-up request (e.g., SIP INVITE) to + the Session Management Server indicating, among other things, the + media streams to be used in the session. As part of this step, + the End Host may authenticate itself to the Session Management + Server. + + + + + + +Hamer, et al. Informational [Page 6] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + 2. The Session Management Server, possibly after waiting for + negotiation of the media streams to be completed, sends a policy + decision request (e.g., COPS REQ) to the Policy Server in order to + determine if the session set-up request should be allowed to + proceed. + + 3. The Policy Server sends a decision (e.g., COPS DEC) to the Session + Management Server, possibly after modifying the parameters of the + media to be used. Included in this response is a "token" that can + subsequently be used by the Policy Server to identify the session + and the media it has authorized. + + 4. The Session Management Server sends a response to the End Host + (e.g., SIP 200 or 183) indicating that session set-up is complete + or is progressing. Included in this response is a description of + the negotiated media along with the token from the Policy Server. + + 5. The End Host issues a request (e.g., RSVP PATH) to reserve the + resources necessary to provide the required QoS for the media + stream. Included in this request is the token from the Policy + Server provided via the Session Management Server. + + 6. The Edge Router intercepts the reservation request and sends a + policy decision request (e.g., COPS REQ) to the Policy Server in + order to determine if the resource reservation request should be + allowed to proceed. Included in this request is the token from + the Policy Server provided by the End Host. The Policy Server + uses this token to correlate the request for resources with the + media authorization previously provided to the Session Management + Server. + + 7. The Policy Server sends a decision (e.g., COPS DEC) to the Edge + Router, possibly after modifying the parameters of the resources + to be reserved. + + 8. The Edge Router, possibly after waiting for end-to-end negotiation + for resources to be completed, sends a response to the End Host + (e.g., RSVP RESV) indicating that resource reservation is complete + or is progressing. + + + + + + + + + + + + +Hamer, et al. Informational [Page 7] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + +4.2 Coupled Model Authorization Token + + In the Coupled Model, the Policy Server is the only network entity + that needs to interpret the contents of the token. Therefore, in + this model, the contents of the token are implementation dependent. + Since the End Host is assumed to be untrusted, the Policy Server + SHOULD take measures to ensure that the integrity of the token is + preserved in transit; the exact mechanisms to be used are also + implementation dependent. + +4.3 Coupled Model Protocol Impacts + + The use of a media authorization token in the Coupled Model requires + the addition of new fields to several protocols: + + - Resource reservation protocol. A new protocol field or object + MUST be added to the resource reservation protocol to + transparently transport the token from the End Host to the Edge + Router. The content and internal structure (if any) of this + object SHOULD be opaque to the resource reservation protocol. For + example, this is achieved in RSVP with the Policy Data object + defined in [8]. + + - Policy management protocol. A new protocol field or object MUST + be added to the policy management protocol to transparently + transport the token from the Policy Server to the Session + Management Server and from the Edge Router to the Policy Server. + The content and internal structure (if any) of this object SHOULD + be opaque to the policy management protocol. For example, this is + achieved in COPS-RSVP with the Policy Data object defined in [8]. + + - Session management protocol. A new protocol field or object MUST + be added to the session management protocol to transparently + transport the media authorization token from the Session + Management Server to the End Host. The content and internal + structure (if any) of this object SHOULD be opaque to the session + management protocol (e.g., SIP [6]). + +5. The Associated Model <<using One Policy Server>> + + 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: + + + + + + +Hamer, et al. Informational [Page 8] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + - Policy decisions, including media authorization, are made by the + same Policy Server for both the Session Management Server and the + Edge Router. However, the Policy Server may change on a per- + transaction basis, i.e., on a per policy request basis. + + - The Edge Router, Session Management Server and Policy Server + involved in establishing the session are not known a priori. For + example, the End Host may be dynamically configured to use one of + a pool of Session Management Servers and each of the Session + Management Servers may be statically configured to use one of a + pool of Policy Servers. + + In another example, the End Host may be mobile and continually + changing the Edge Router that its point of attachment uses to + communicate with the rest of the network. + + - There are pre-defined trust relationships between the SMS and the + PS and between the ER and the PS. + + +---------------------+ +---------+ + | SMS 'n' |<-->| PS 'm' | + +---------------------+ +--------+ | + +------+ : : : | | | + | | 1 +--------------------+ 2 | | | + | |-------->| Session Management |----->| | | + | |<--------| Server 1 |<-----| | | + | | 4 +--------------------+ 3 | | | + | End | | Policy | | + | Host | +--------------------+ | Server | | + | | | ER 'n' | | 1 | | + | | 5 +-+------------------+ | | | | + | |-------->| Edge |-+ 6 | | | + | |<--------| Router |----->| | | + | | 8 +--------------------+ 7 | | | + +------+ <-----| |-+ + +--------+ + + Figure 3: The Associated Model using One Policy Server + +5.1 Associated Model Message Flows <<using One Policy Server>> + + In this model, it is assumed that a Policy Server can make decisions + for both the Service Control and Resource Control Domains and that + there are pre-defined trust relationships between the PS and SMS and + between the PS and ER. Communications between these entities are + then possible as described below. Only the originating side flows + are described for simplicity. The same concepts apply to the + terminating side. + + + +Hamer, et al. Informational [Page 9] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + 1. The End Host issues a session set-up request (e.g., SIP INVITE) to + the Session Management Server indicating, among other things, the + media streams to be used in the session. As part of this step, + the End Host may authenticate itself to the Session Management + Server. + + 2. The Session Management Server, possibly after waiting for + negotiation of the media streams to be completed, sends a policy + decision request (e.g., COPS REQ) to the Policy Server in order to + determine if the session set-up request should be allowed to + proceed. + + 3. The Policy Server sends a decision (e.g., COPS DEC) to the Session + Management Server, possibly after modifying the parameters of the + media to be used. Included in this response is a "token" that can + subsequently be used by the Policy Server to identify the session + and the media it has authorized. + + 4. The Session Management Server sends a response to the End Host + (e.g., SIP 200 or 183) indicating that session set-up is complete + or is progressing. Included in this response is a description of + the negotiated media along with the token from the Policy Server. + + 5. The End Host issues a request (e.g., RSVP PATH) to reserve the + resources necessary to provide the required QoS for the media + stream. Included in this request is the token from the Policy + Server provided via the Session Management Server. + + 6. The Edge Router intercepts the reservation request and inspects + the token to learn which Policy Server authorized the media. It + then sends a policy decision request to that Policy Server in + order to determine if the resource reservation request should be + allowed to proceed. Included in this request is the token from + the Policy Server provided by the End Host. The Policy Server + uses this token to correlate the request for resources with the + media authorization previously provided to the Session Management + Server. + + 7. The Policy Server sends a decision to the Edge Router, possibly + after modifying the parameters of the resources to be reserved. + + 8. The Edge Router, possibly after waiting for end-to-end negotiation + for resources to be completed, sends a response to the End Host + (e.g., RSVP RESV) indicating that resource reservation is complete + or is progressing. + + + + + + +Hamer, et al. Informational [Page 10] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + +5.2 Associated Model Authorization Token <<using One Policy Server>> + + Since the ER does not know which SMS and PS are involved in session + establishment, the token MUST include: + + - A correlation identifier. This is information that the Policy + Server can use to correlate the resource reservation request with + the media authorized during session set up. The Policy Server is + the only network entity that needs to interpret the contents of + the correlation identifier therefore, in this model, the contents + of the correlation identifier are implementation dependent. Since + the End Host is assumed to be untrusted, the Policy Server SHOULD + take measures to ensure that the integrity of the correlation + identifier is preserved in transit; the exact mechanisms to be + used are also implementation dependent. + + - The identity of the authorizing entity. This information is used + by the Edge Router to determine which Policy Server should be used + to solicit resource policy decisions. + + In some environments, an Edge Router may have no means for + determining if the identity refers to a legitimate Policy Server + within its domain. In order to protect against redirection of + authorization requests to a bogus authorizing entity, the token + SHOULD also include: + + - Authentication data. This authentication data is calculated over + all other fields of the token using an agreed mechanism. The + mechanism used by the Edge Router is beyond the scope of this + document. + + The detailed semantics of an authorization token are defined in [4]. + +5.3 Associated Model Protocol Impacts <<using One Policy Server>> + + The use of a media authorization token in this version of the + Associated Model requires the addition of new fields to several + protocols: + + - Resource reservation protocol. A new protocol field or object + MUST be added to the resource reservation protocol to + transparently transport the token from the End Host to the Edge + Router. The content and internal structure of this object MUST be + specified so that the Edge Router can distinguish between the + elements of the token described in Section 5.2. For example, this + is achieved in RSVP with the Policy Data object defined in [8]. + + + + + +Hamer, et al. Informational [Page 11] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + - Policy management protocol. A new protocol field or object MUST + be added to the policy management protocol to transparently + transport the token -- or at least the correlation identifier -- + from the Edge Router to the Policy Server. The content and + internal structure of this object SHOULD be opaque to the policy + management protocol. For example, this is achieved in COPS-RSVP + with the Policy Data object defined in [8]. + + - Session management protocol. A new protocol field or object MUST + be added to the session management protocol to transparently + transport the media authorization token from the Session + Management Server to the End Host. The content and internal + structure of this object SHOULD be opaque to the session + management protocol (e.g., SIP [6]). + +5.4 Associated Model Network Impacts <<using One Policy Server>> + + The use of a media authorization token in this version of the + Associated Model requires that the Edge Router inspect the token to + learn which Policy Server authorized the media. In some + environments, it may not be possible for the Edge Router to perform + this function; in these cases, an Associated Model using Two Policy + Servers (section 6) is required. + + This version of the Associated Model also requires that the Edge + Router interact with multiple Policy Servers. Policy decisions are + made by the same Policy Server for both the Session Management Server + and the Edge Router, however the Policy Server may change on per- + transaction basis. Note that the COPS framework does not currently + allow PEPs to change PDP on a per-transaction basis. To use this + model, a new framework must be defined for policy decision + outsourcing. This model also implies that the Policy Servers are + able to interact and/or make decisions for the Edge Router in a + consistent manner (e.g., as though there is only a single RCD Policy + Server). How this is accomplished is beyond the scope of this + document. + +6. The Associated Model <<using Two Policy Servers>> + + 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 media authorization, are made by + Policy Servers. + + + + +Hamer, et al. Informational [Page 12] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + - There is a PS in the Resource Control Domain that is separate from + the PS in the Service Control Domain. + + - The Edge Router, Session Management Server and Policy Servers + involved in establishing the session are not known a priori. For + example, the End Host may be dynamically configured to use one of + a pool of Session Management Servers or the End Host may be mobile + and continually changing the Edge Router that it uses to + communicate with the rest of the network. + + - There is a pre-defined trust relationship between the SMS and the + SCD PS. + + - There is a pre-defined trust relationship between the ER and the + RCD PS. + + - There is a pre-defined trust relationship between the RCD and SCD + Policy Servers. + + +--------------------+ +--------+ + +------+ | SMS `n' | | | + | | 1 +-+------------------+ | | SCD | + | |-------->| Session Management |-+ 2 | Policy | + | |<--------| Server |----->| Server | + | | 4 +--------------------+<-----| | + | End | 3 +--------+ + | | 7 ^ | + | Host | +--------------------+ | v 8 + | | | ER 'n' | +--------+ + | | 5 +-+------------------+ | | | + | |-------->| Edge |-+ 6 | RCD | + | |<--------| Router |----->| Policy | + | | 10 +--------------------+<--- -| Server | + +------+ 9 | | + +--------+ + + Figure 4: The Associated Model using Two Policy Servers + +6.1 Associated Model Message Flows <<using Two Policy Servers>> + + In this model, it is assumed that there is one Policy Server for the + Service Control Domain and a different Policy Server for the Resource + Control Domain. There are pre-defined trust relationships between + the SCD PS and SMS, between the RCD PS and ER and between the RCD and + SCD Policy Servers. Communications between these entities are then + possible as described below. Only the originating side flows are + described for simplicity. The same concepts apply to the terminating + side. + + + +Hamer, et al. Informational [Page 13] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + 1. The End Host issues a session set-up request (e.g., SIP INVITE) + to the Session Management Server indicating, among other things, + the media streams to be used in the session. As part of this + step, the End Host may authenticate itself to the Session + Management Server. + + 2. The Session Management Server, possibly after waiting for + negotiation of the media streams to be completed, sends a policy + decision request (e.g., COPS REQ) to the SCD Policy Server in + order to determine if the session set-up request should be + allowed to proceed. + + 3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the + Session Management Server, possibly after modifying the + parameters of the media to be used. Included in this response is + a "token" that can subsequently be used by the SCD Policy Server + to identify the session and the media it has authorized. + + 4. The Session Management Server sends a response to the End Host + (e.g., SIP 200 or 183) indicating that session set-up is complete + or is progressing. Included in this response is a description of + the negotiated media along with the token from the SCD Policy + Server. + + 5. The End Host issues a request (e.g., RSVP PATH) to reserve the + resources necessary to provide the required QoS for the media + stream. Included in this request is the token from the SCD + Policy Server provided via the Session Management Server. + + 6. The Edge Router intercepts the reservation request and sends a + policy decision request (e.g., COPS REQ) to the RCD Policy Server + in order to determine if the resource reservation request should + be allowed to proceed. Included in this request is the token + from the SCD Policy Server provided by the End Host. + + 7. The RCD Policy Server uses this token to learn which SCD Policy + Server authorized the media. It then sends an authorization + request [11] to that SCD Policy Server in order to determine if + the resource reservation request should be allowed to proceed. + Included in this request is the token from the SCD Policy Server + provided by the End Host. + + 8. The SCD Policy Server uses this token to correlate the request + for resources with the media authorization previously provided to + the Session Management Server. The SCD Policy Server sends a + decision [11] to the RCD Policy Server on whether the requested + resources are within the bounds authorized by the SCD Policy + Server. + + + +Hamer, et al. Informational [Page 14] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + 9. The RCD Policy Server sends a decision (e.g., COPS DEC) to the + Edge Router, possibly after modifying the parameters of the + resources to be reserved. + + 10. The Edge Router, possibly after waiting for end-to-end + negotiation for resources to be completed, sends a response to + the End Host (e.g., RSVP RESV) indicating that resource + reservation is complete or is progressing + +6.2 Associated Model Authorization Token <<using Two Policy Servers>> + + Since the RCD Policy Server does not know which SMS and SCD PS are + involved in session establishment, the token MUST include: + + - A correlation identifier. This is information that the SCD Policy + Server can use to correlate the resource reservation request with + the media authorized during session set up. The SCD Policy Server + is the only network entity that needs to interpret the contents of + the correlation identifier therefore, in this model, the contents + of the correlation identifier are implementation dependent. Since + the End Host is assumed to be untrusted, the SCD Policy Server + SHOULD take measures to ensure that the integrity of the + correlation identifier is preserved in transit; the exact + mechanisms to be used are also implementation dependent. + + - The identity of the authorizing entity. This information is used + by the RCD Policy Server to determine which SCD Policy Server + should be used to verify the contents of the resource reservation + request. + + In some environments, an RCD Policy Server may have no means for + determining if the identity refers to a legitimate SCD Policy Server. + In order to protect against redirection of authorization requests to + a bogus authorizing entity, the token SHOULD include: + + - Authentication data. This authentication data is calculated over + all other fields of the token using an agreed mechanism. The + mechanism used by the RCD Policy Server is beyond the scope of + this document. + + Note that the information in this token is the same as that in + Section 5.2 for the "One Policy Server" scenario. + + The detailed semantics of an authorization token are defined in [4]. + + + + + + + +Hamer, et al. Informational [Page 15] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + +6.3 Associated Model Protocol Impacts <<using Two Policy Servers>> + + The use of a media authorization token in this version of the + Associated Model requires the addition of new fields to several + protocols: + + - Resource reservation protocol. A new protocol field or object + MUST be added to the resource reservation protocol to + transparently transport the token from the End Host to the Edge + Router. The content and internal structure of this object SHOULD + be opaque to the resource reservation protocol. For example, this + is achieved in RSVP with the Policy Data object defined in [8]. + + - Policy management protocol. A new protocol field or object MUST + be added to the policy management protocol to transport the token + from the SCD Policy Server to the Session Management Server and + from the Edge Router to the RCD Policy Server. The content and + internal structure of this object MUST be specified so that the + Policy Servers can distinguish between the elements of the token + described in Section 6.2. For example, this is achieved in COPS- + RSVP with the Policy Data object defined in [8]. + + - Session management protocol. A new protocol field or object MUST + be added to the session management protocol to transparently + transport the media authorization token from the Session + Management Server to the End Host. The content and internal + structure of this object SHOULD be opaque to the session + management protocol (e.g., SIP [6]). + + Note that these impacts are the same as those discussed in Section + 5.3 for the "One Policy Server" scenario. However the use of two + Policy Servers has one additional impact: + + - Authorization protocol. A new protocol field or object MUST be + added to the authorization protocol to transport the token from + the RCD Policy Server to the SCD Policy Server. The content and + internal structure of this object MUST be specified so that the + Policy Servers can distinguish between the elements of the token + described in Section 6.2. + +7. 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 are + no pre-established trust relationships between entities in the + Resource Control Domain and entities in the Service Control Domain. + The key aspects of this scenario are the following: + + + +Hamer, et al. Informational [Page 16] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + - Policy decisions, including media authorization, are made by + Policy Servers. + + - The PS in the Resource Control Domain is separate from the PS in + the Service Control Domain. + + - There is a pre-defined trust relationship between the SMS and the + SCD PS. + + - There is a pre-defined trust relationship between the ER and the + RCD PS. + + - There are no pre-defined trust relationships between the ER and + SMS or between the RCD and SCD Policy Servers. + + +--------+ + +------+ | | + | | 1 +--------------------+ 2 | SCD | + | |-------->| Session Management |----->| Policy | + | |<--------| Server |<-----| Server | + | | 4 +--------------------+ 3 | | + | End | +--------+ + | Host | + | | +--------+ + | | 5 +--------------------+ 6 | | + | |-------->| Edge |----->| RCD | + | |<--------| Router |<-----| Policy | + | | 8 +--------------------+ 7 | Server | + +------+ | | + +--------+ + + Figure 5: The Non-Associated Model + +7.1 Non-Associated Model Message Flow + + In this model it is assumed that the policy servers make independent + decisions for their respective domains, obviating the need for + information exchange between policy servers. This model also enables + session authorization when communication between policy servers is + not possible for various reasons. It may also be used as a means to + speed up session setup and still ensure proper authorization is + performed. + + This model does not preclude the possibility that the policy servers + may communicate at other times for other purposes (e.g., exchange of + accounting information). + + + + + +Hamer, et al. Informational [Page 17] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + Communications between network entities in this model is described + below. Only the originating side flows are described for simplicity. + The same concepts apply to the terminating side. + + 1. The End Host issues a session set-up request (e.g., SIP INVITE) to + the Session Management Server indicating, among other things, the + media streams to be used in the session. As part of this step, + the End Host may authenticate itself to the Session Management + Server. + + 2. The Session Management Server, possibly after waiting for + negotiation of the media streams to be completed, sends a policy + decision request (e.g., COPS REQ) to the SCD Policy Server in + order to determine if the session set-up request should be allowed + to proceed. + + 3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the + Session Management Server, possibly after modifying the parameters + of the media to be used. Included in this response is a "token" + that can subsequently be used by the RCD Policy Server to + determine what media has been authorized. + + 4. The Session Management Server sends a response to the End Host + (e.g., SIP 200 or 183) indicating that session set-up is complete + or is progressing. Included in this response is a description of + the negotiated media along with the token from the SCD Policy + Server. + + 5. The End Host issues a request (e.g., RSVP PATH) to reserve the + resources necessary to provide the required QoS for the media + stream. Included in this request is the token from the SCD Policy + Server provided via the Session Management Server. + + 6. The Edge Router intercepts the reservation request and sends a + policy decision request (e.g., COPS REQ) to the RCD Policy Server + in order to determine if the resource reservation request should + be allowed to proceed. Included in this request is the token from + the SCD Policy Server provided by the End Host. + + 7. The RCD Policy Server uses this token to extract information about + the media that was authorized by the SCD Policy Server. The RCD + Policy Server uses this information in making its decision on + whether the resource reservation should be allowed to proceed. + + The Policy Server sends a decision (e.g., COPS DEC) to the Edge + Router, possibly after modifying the parameters of the resources + to be reserved. + + + + +Hamer, et al. Informational [Page 18] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + 8. The Edge Router, possibly after waiting for end-to-end negotiation + for resources to be completed, sends a response to the End Host + (e.g., RSVP RESV) indicating that resource reservation is complete + or is progressing + +7.2 Non-Associated Model Authorization Token + + In this model, the token MUST contain sufficient information to allow + the RCD Policy Server to make resource policy decisions autonomously + from the SCD Policy Server. The token is created using information + about the session received by the SMS. The information in the token + MUST include: + + - Calling party name or IP address (e.g., from SDP "c=" parameter). + + - Called party name or IP address (e.g., from SDP "c=" parameter). + + - The characteristics of (each of) the media stream(s) authorized + for this session (e.g., codecs, maximum bandwidth from SDP "m=" + and/or "b=" parameters). + + - The authorization lifetime. To protect against replay attacks, + the token should be valid for only a few seconds after the start + time of the session. + + - The identity of the authorizing entity to allow for validation of + the token. + + - Authentication data used to prevent tampering with the token. + This authentication data is calculated over all other fields of + the token using an agreed mechanism. The mechanism used by the + RCD Policy Server is beyond the scope of this document. + + Furthermore, the token MAY include: + + - The lifetime of (each of) the media stream(s) (e.g., from SDP "t=" + parameter). This field may be useful in pre-paid scenarios in + order to limit the lifetime of the session. + + - The Calling and called party port numbers (e.g., from the "m=" + parameter). + + The detailed semantics of an authorization token are defined in [4]. + +7.3 Non-Associated Model Protocol Impacts + + The use of a media authorization token in the Non-Associated Model + requires the addition of new fields to several protocols: + + + +Hamer, et al. Informational [Page 19] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + - Resource reservation protocol. A new protocol field or object + MUST be added to the resource reservation protocol to + transparently transport the token from the End Host to the Edge + Router. The content and internal structure of this object SHOULD + be opaque to the resource reservation protocol. For example, this + is achieved in RSVP with the Policy Data object defined in [8]. + + - Policy management protocol. A new protocol field or object MUST + be added to the policy management protocol to transport the token + from the SCD Policy Server to the Session Management Server and + from the Edge Router to the RCD Policy Server. The content and + internal structure of this object MUST be specified so that the + Policy Servers can distinguish between the elements of the token + described in Section 7.2. For example, this is achieved in COPS- + RSVP with the Policy Data object defined in [8]. + + - Session management protocol. A new protocol field or object MUST + be added to the session management protocol to transparently + transport the media authorization token from the Session + Management Server to the End Host. The content and internal + structure of this object SHOULD be opaque to the session + management protocol (e.g., SIP [6]). + +8. Conclusions + + This document defines three models for session set-up with media + authorization: + + - The Coupled Model which assumes a priori knowledge of network + topology and where pre-established trust relationships exist + between network entities. + + - The Associated Model where there are common or trusted policy + servers but knowledge of the network topology is not known a + priori. + + - The Non-Associated Model where knowledge of the network topology + is not known a priori, where there are different policy servers + involved and where a trust relationship does not exist between the + policy servers. + + The Associated Model is applicable to environments where the network + elements involved in establishing a session have a pre-determined + trust relationship but where their identities must be determined + dynamically during session set up. The Non-Associated Model is + applicable to environments where there is a complex network topology + and/or where trust relationships between domains do not exist (e.g., + when they are different business entities). + + + +Hamer, et al. Informational [Page 20] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + In any given network, one or more of these models may be applicable. + Indeed, the model to be used may be chosen dynamically during session + establishment based on knowledge of the end points involved in the + call. In all cases, however, there is no need for the End Host or + the Session Management Server to understand or interpret the + authorization token - to them it is an opaque protocol element that + is simply copied from one container protocol to another. + + Finally, the framework defined in this document is extensible to any + kind of session management protocol coupled to any one of a number of + resource reservation and/or policy management protocols. + +9. Security Considerations + + The purpose of this document is to describe a mechanism for media + authorization to prevent theft of service. + + For the authorization token to be effective, its integrity MUST be + guaranteed as it passes through untrusted network entities such as + the End Host. This can be achieved by using authentication data. + There is no requirement for encryption of the token since it does not + contain confidential information that may be used by malicious users. + + This document assumes that trust relationships exist between various + network entities, as described in each of the models. The means for + establishing these relationships are beyond the scope of this + document. + + The different interfaces between the network entities described in + this document have different natures requiring different security + characteristics: + + - The edge router and RCD policy server MUST have a trust + relationship. If necessary, this relationship can be enforced + through a formal security association [14]. + + - The network policies exchanged over the interface between edge + router and RCD policy server SHOULD be integrity protected. This + can be accomplished using integrity mechanisms built into the + policy control protocol (e.g., the Integrity object in COPS [2]) + or through generic IP security mechanisms [14]. + + - The SCD and RCD policy servers MUST have a trust relationship in + the associated model. If necessary, this relationship can be + enforced through a formal security association [14]. + + + + + + +Hamer, et al. Informational [Page 21] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + - The information exchanged over the interface between policy + servers SHOULD be integrity protected. This can be accomplished + using integrity mechanisms built into the policy exchange protocol + [2] or through generic IP security mechanisms [14]. + + - The end host SHOULD be authenticated by the RCD to protect against + identity theft. The network resource request/responses should be + protected against corruption and spoofing. Thus, the interface + between host and edge router SHOULD provide integrity and + authentication of messages. For example, [13] provides integrity + and authentication of RSVP messages. + + - The end host SHOULD be authenticated by the SCD to protect against + identity theft. The session setup request/response should be + protected against corruption and spoofing. Thus, the interface + between host and SMS SHOULD provide integrity and authentication + of messages. + + - The SMS and the SCD policy server MUST have a a trust + relationship. If necessary, this relationship can be enforced + through a formal security association [14]. + + - The network policies exchanged over the interface between the SMS + and SCD policy server SHOULD be integrity protected. This can be + accomplished using integrity mechanisms built into the policy + control protocol (e.g., the Integrity object in COPS [2]) or + through generic IP security mechanisms [14]. + +10. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. + Sastry, "The COPS (Common Open Policy Service) Protocol", RFC + 2748, January 2000. + + [3] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. + Sastry, "COPS usage for RSVP", RFC 2749, January 2000. + + [4] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session + Authorization Policy Element", RFC 3520, April 2003. + + [5] Handley, M. and V. Jacobson, "SDP: session description + protocol," RFC 2327, April 1998. + + + + + + +Hamer, et al. Informational [Page 22] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + + [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, + "Resource ReSerVation protocol (RSVP) -- version 1 functional + specification," RFC 2205, September 1997. + + [8] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, + January 2000. + + [9] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., + Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS + Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. + +11. Informative References + + [10] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, + G., de Bruijn, B., de Laat, C., Holdrege, M. and P. Spence, "AAA + Authorization Framework", RFC 2904, August 2000. + + [11] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D. + Spence, "Generic AAA Architecture", RFC 2903, August 2000. + + [12] "PacketCable Dynamic Quality of Service Specification", + CableLabs, December 1999. + + [13] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic + Authentication", RFC 2747, January 2000. + + [14] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + +12. Acknowledgments + + The authors would like to thank to following people for their useful + comments and suggestions related to this document: Kwok Ho Chan, Doug + Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois + Audet, Bill Marshall, Diana Rawlins and many others. + + + + + + + + + + + + +Hamer, et al. Informational [Page 23] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + +13. Authors' Addresses + + Louis-Nicolas Hamer + Nortel Networks + PO Box 3511 Station C + Ottawa, ON + CANADA K1Y 4H7 + + Phone: +1 613.768.3409 + EMail: nhamer@nortelnetworks.com + + + Bill Gage + Nortel Networks + PO Box 3511 Station C + Ottawa, ON + CANADA K1Y 4H7 + + Phone: +1 613.763.4400 + EMail: gageb@nortelnetworks.com + + + Hugh Shieh + AT&T Wireless + 7277 164th Avenue NE + Redmond, WA + USA 98073-9761 + + Phone: +1 425.580.6898 + EMail: hugh.shieh@attws.com + + + + + + + + + + + + + + + + + + + + + +Hamer, et al. Informational [Page 24] + +RFC 3521 Session Set-up with Media Authorization April 2003 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 organizations, 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 languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hamer, et al. Informational [Page 25] + |