SIP Working Group W. Marshall Internet Draft AT&T Document: [--] {++} F. Andreasen Category: Informational Cisco D. Evans D. R. Evans Consulting May, 2002 SIP Extensions for Media Authorization Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [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.+} 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. Abstract This document describes the need for QoS and media authorization and defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS belong to that administrative domain or federation of domains. Table of Contents 1. Scope of [-Applicability...............................................2-] {+Applicability..........................................2+} 2. Conventions used in this [-document....................................2-] {+document...............................2+} 3. Background and [-Motivation............................................2-] {+Motivation.......................................3+} 4. [-Overview.............................................................3-] {+Overview........................................................4+} 5. Changes to SIP to Support Media [-Authorization........................4 5.1 SIP Header Extension.............................................4 5.2 SIP Procedures...................................................4 5.2.1 User Agent Client (UAC)......................................5 5.2.2 User Agent Server (UAS)......................................5-] {+Authorization...................4+} SIP Working Group Informational - Expires [-11/02/02-] {+11/22/02+} 1 SIP Extensions for Media Authorization May 2002 {+5.1 SIP Header Extension........................................4 5.2 SIP Procedures..............................................5 5.2.1 User Agent Client (UAC).................................5 5.2.2 User Agent Server (UAS).................................6+} 5.2.3 Originating Proxy [-(OP).......................................5-] {+(OP)..................................6+} 5.2.4 Destination Proxy [-(DP).......................................6-] {+(DP)..................................7+} 6. [-Examples.............................................................6-] {+Examples........................................................7+} 6.1 Requesting Bandwidth via RSVP [-messaging..........................6-] {+messaging.....................7+} 6.1.1 User Agent Client [-Side.......................................6-] {+Side..................................7+} 6.1.2 User Agent Server [-Side.......................................8-] {+Side.................................10+} 7. Advantages of the Proposed [-Approach.................................10-] {+Approach............................12+} 8. Security [-Considerations.............................................10-] {+Considerations........................................12+} 9. IANA [-Considerations.................................................11-] {+Considerations............................................13+} 10. Notice Regarding Intellectual Property [-Rights......................11-] {+Rights.................13+} 11. Normative [-References...............................................11-] {+References..........................................13+} 12. Informative [-References.............................................11-] {+References........................................14+} 13. [-Contributors.......................................................11-] {+Contributors..................................................14+} 14. [-Acknowledgments....................................................12-] {+Acknowledgments...............................................14+} 15. Authors' [-Addresses.................................................12-] {+Addresses............................................15+} 1. Scope of Applicability This document defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS belong to that administrative domain or federation of domains. Furthermore, the mechanism is generally incompatible with [-end- to-end-] {+end-to-end+} encryption of message bodies that describe media sessions. This is in contrast with general Internet principles which separate data transport from applications, and the solution described in this document is thus not applicable to the Internet at large. Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant {+informational+} publication of this mechanism. An example deployment would be a closed network which emulates a traditional circuit switched telephone network. {+This document specifies a private header facilitating use in these specialized configurations.+} 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 RFC 2119 [2]. {+SIP Working Group Informational - Expires 11/22/02 2 SIP Extensions for Media Authorization May 2002+} 3. Background and Motivation Current IP telephony systems assume a perfect world in which there is either unlimited amount of bandwidth or network layer Quality of Service (QoS) is provided without any kind of policy control. However the reality is that end-to-end bandwidth is not unlimited and uncontrolled access to QoS in general is unlikely. The primary reason for this is that QoS provides preferential treatment of one flow at the expense of another. Consequently, it is important to have policy control over whether a given flow should have access to QoS. This will not only enable fairness in general, but can also prevent denial of service attacks. [-SIP Working Group Informational - Expires 11/02/02 2 SIP Extensions for Media Authorization May 2002-] In this document, we are concerned with providing QoS for media streams established via the Session Initiation Protocol (SIP) [3]. We assume an architecture that integrates call signaling with media authorization as illustrated in the Figure below. The solid lines (A and B) show interfaces whereas the dotted line (C) illustrates the QoS enabled media flow: +---------+ | Proxy | +--------->| | | +---------+ | ^ A)| B) | | { } | | | v v +------+ +------+ C) | Edge | | UA |........|router|...... +------+ +------+ Figure 1 - Basic Architecture In this architecture, we assume [-an untrusted-] {+a+} SIP UA connected to a QoS enabled network with an edge router acting as a Policy Enforcement Point (PEP) [6]. We furthermore assume that a SIP [-UA,-] {+UA+} that wishes to obtain [-QoS,-] {+QoS+} initiates sessions through a proxy which can interface with the QoS policy control for the data network being used. We will refer to such a proxy as a QoS enabled proxy. We assume that the SIP UA needs to present an authorization token to the network in order to obtain Quality of Service (C). The SIP UA obtains this authorization token via SIP (A) from the QoS enabled proxy by means of an extension SIP header defined in this document. The proxy in turn communicates either directly with the edge router or with a Policy Decision Point (PDP - not shown) [6] in order to obtain a suitable authorization token for the UA. {+SIP Working Group Informational - Expires 11/22/02 3 SIP Extensions for Media Authorization May 2002+} Examples of access data networks where such a QoS enabled proxy could be used include DOCSIS based cable networks and 3rd generation (3G) wireless networks. 4. Overview A [-session,-] {+session+} that needs to obtain QoS for the media streams in accordance with our basic architecture described above [-is performed as follows.-] {+goes through the following steps.+} The SIP UA sends an INVITE to the QoS enabled proxy which for each resulting dialog includes [-a-] {+one or more+} media authorization [-token-] {+tokens+} in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the [-SIP Working Group Informational - Expires 11/02/02 3 SIP Extensions for Media Authorization May 2002-] dialog. When the UA requests QoS, it includes the media authorization [-token-] {+tokens+} with the resource reservation. A SIP UA may also receive an INVITE from its QoS enabled proxy which includes [-a-] {+one or more+} media authorization [-token.-] {+tokens.+} In that case, when the UA requests QoS, it includes the media authorization [-token-] {+tokens+} with the resource reservation. {+The resource reservation mechanism is not within SIP and is not described within the scope of this document.+} 5. Changes to SIP to Support Media Authorization This document defines a private SIP header extension to support a media authorization scheme. In this architecture a QoS enabled SIP proxy supplies the UA with [-an-] {+one or more+} authorization [-token-] {+tokens+} which [-is-] {+are+} to be used in QoS requests. The extension defined allows network QoS resources to be authorized by the QoS enabled SIP proxy. 5.1 SIP Header Extension A new P-Media-Authorization general header field is defined. The [-Media- Auth-] {+P- Media-Authorization+} header field contains [-a-] {+one or more+} media authorization [-token-] {+tokens+} which [-is-] {+are+} to be included in subsequent resource reservations for the media flows associated with the [-session.-] {+session (, that is, passed to an independent resource reservation mechanism which is not specified here).+} The media authorization [-token is-] {+tokens are+} used for authorizing QoS for the media stream(s). The P-Media-Authorization header field is described by the following ABNF [4]: P-Media-Authorization = "P-Media-Authorization" HCOLON P-Media-Authorization-Token *(COMMA P-Media-Authorization-Token) P-Media-Authorization-Token = 1*HEXDIG {+SIP Working Group Informational - Expires 11/22/02 4 SIP Extensions for Media Authorization May 2002+} Table 1 below is an extension of tables 2 and 3 in [3] for the new header field defined [-here:-] {+here. For informational purposes, this table also includes relevant entries for standards track extension methods published at the time this document was published. The INFO, PRACK, UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in [11], [9], [12], and [10].+} Where proxy ACK BYE CAN INV OPT REG P-Media-Authorization {+R ad o - - o - - P-Media-Authorization 2xx ad - - - o - - P-Media-Authorization 101-199 ad - - - o - - Where proxy INF PRA UPD SUB NOT P-Media-Authorization R+} ad - {+o o -+} - {+P-Media-Authorization 2xx ad+} - o {+o+} - - Table 1: Summary of header fields. The P-Media-Authorization header field can be used [-with-] {+only in SIP requests or responses that can carry a SIP offer or answer. This naturally keeps+} the [-INVITE method as well as any response to it. Extension methods MAY define usage-] {+scope+} of [-the-] {+this+} header field [-as well.-] {+narrow.+} 5.2 SIP Procedures This section defines [-the-] SIP [3] procedures for usage in media authorization compatible systems from the point of view of authorizing QoS. [-SIP Working Group Informational - Expires 11/02/02 4 SIP Extensions for Media Authorization May 2002-] 5.2.1 User Agent Client (UAC) The initial SIP INVITE message, mid-call messages that result in network QoS resource changes, and mid-call changes in call destination should be authorized. These SIP messages are sent through the QoS enabled proxies to receive this authorization. In order to authorize QoS, the QoS enabled SIP proxy MAY need to inspect message bodies that describe the media streams, e.g. SDP, and hence {+it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that+} such message bodies [-SHOULD NOT-] {+not+} be encrypted end-to-end. The P-Media-Authorization-Token, which is contained in the P-Media- Authorization header, is included for each dialog in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog sent by the QoS enabled SIP proxy to the UAC. The UAC [-SHOULD-] {+should+} use all the [-P-Media-Authorization-Token(s)-] {+P-Media-Authorization-Tokens+} from the most recent request/response that contained the [-P-Media-Authorization-] {+P-Media- Authorization+} header when requesting QoS for the associated media stream(s). This applies both to [-the-] initial and subsequent refresh {+SIP Working Group Informational - Expires 11/22/02 5 SIP Extensions for Media Authorization May 2002+} reservation [-messages. The UAC converts-] {+messages (for example, in an RSVP-based reservation system). A reservation function within+} the {+UAC should convert each+} string of hex digits into binary, and [-utilizes the-] {+utilize each+} result as a Policy-Element as defined in RFC 2750 [5] [-(including Length and P- Type). This Policy-Element-] {+(excluding Length, but including P-Type which is included in each token). These Policy- Elements+} would typically contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources. 5.2.2 User Agent Server (UAS) The User Agent Server receives the P-Media-Authorization-Token in an INVITE (or other) message from the QoS enabled SIP proxy. If the response contains a message body that describes media streams for which the UA desires QoS, [-said-] {+it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that this+} message body [-SHOULD NOT-] {+not+} be [-end-to-end encrypted.-] {+encrypted end-to-end.+} The [-UAS SHOULD-] {+UAC should+} use all the [-P-Media-Authorization-Token(s)-] {+P-Media-Authorization-Tokens+} from the most recent request/response that contained the [-P-Media-Authorization-] {+P-Media- Authorization+} header when requesting QoS for the associated media stream(s). This applies both to [-the-] initial and subsequent refresh reservation [-messages. The UAS converts-] {+messages (for example, in an RSVP-based reservation system). A reservation function within+} the {+UAS should convert each+} string of hex digits into binary, and [-utilizes the-] {+utilize each+} result as a Policy-Element as defined in RFC 2750 [5] [-(including Length and P- Type). This Policy-Element-] {+(excluding Length, but including P-Type which is included in each token). These Policy- Elements+} would typically contain the authorizing entity and credentials, and be used in an RSVP request for media data stream {+QoS+} resources. 5.2.3 Originating Proxy (OP) When the originating QoS enabled proxy (OP) receives an INVITE (or other) message from the UAC, the proxy authenticates the caller, and verifies that the caller is authorized to receive QoS. In cooperation with an originating Policy Decision Point (PDP-o), the OP obtains and/or generates [-a-] {+one or more+} media authorization [-token that contains-] {+tokens. These contain+} sufficient information for the UAC to get the authorized QoS for the media streams. [-The-] {+Each+} media authorization token is formatted as a [-Policy- Element,-] {+Policy-Element,+} as defined in RFC 2750 [-[5],-] {+[5] (excluding Length, but including P-Type which is included in each token),+} and then converted to a string of [-SIP Working Group Informational - Expires 11/02/02 5 SIP Extensions for Media Authorization May 2002-] hex digits to form a [-P-Media-Authorization-Token.-] {+P- Media-Authorization-Token.+} The [-proxy MAY-] {+proxy's resource management function may+} inspect message bodies that describe the media streams, e.g. SDP, in both requests and responses in order to decide what QoS to authorize. For each dialog that results from the INVITE (or other) message received from the UAC, the originating proxy [-MUST-] {+must+} add a [-P-Media-Authorization-] {+P-Media- Authorization+} header with the P-Media-Authorization-Token in all {+SIP Working Group Informational - Expires 11/22/02 6 SIP Extensions for Media Authorization May 2002+} unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response the proxy sends to the UAC, if that response may result in network QoS changes. A response with an SDP may result in such changes. 5.2.4 Destination Proxy (DP) The Destination QoS Enabled Proxy (DP) verifies that the called party is authorized to receive QoS. In cooperation with a terminating Policy Decision Point (PDP-t), the DP obtains and/or generates a media authorization token that contains sufficient information for the UAS to get the authorized QoS for the media streams. The media authorization token is formatted as a [-Policy- Element,-] {+Policy-Element,+} as defined in RFC 2750 [-[5],-] {+[5] (excluding Length, but including P-Type which is included in each token),+} and then converted to a string of hex digits to form a [-P-Media-Authorization-Token.-] {+P-Media- Authorization-Token.+} The [-proxy MAY-] {+proxy's resource management function may+} inspect message bodies that describe the media streams, e.g. SDP, in both requests and responses in order to decide what QoS to authorize. The Destination Proxy [-MUST-] {+must+} add the P-Media-Authorization header with the P-Media-Authorization-Token in the INVITE (or other) request that it sends to the UAS, if that message may result in network QoS changes. A message with an SDP body may result in such changes. 6. Examples 6.1 Requesting Bandwidth via RSVP messaging Below we provide an example for how the P-Media-Authorization header field can be used in conjunction with the Resource Reservation Protocol (RSVP) [7]. The example assumes that [-resource management is integrated with SIP signaling and therefore utilizes-] {+an offer arrives in+} the [-183 Session Progress-] {+initial INVITE and an answer arrives in a reliable+} provisional [-response,-] {+response [9],+} which contains an SDP description of the media flow. 6.1.1 User Agent Client Side Figure 2 presents a high-level overview of a basic call flow with media authorization from the viewpoint of the UAC. Some policy interactions have been omitted for brevity. When a user goes off-hook and dials a telephone number, the UAC collects the dialed digits and sends the initial (1)INVITE message to the originating SIP proxy. [-SIP Working Group Informational - Expires 11/02/02 6 SIP Extensions for Media Authorization May 2002-] The originating SIP proxy (OP) authenticates the user/UAC and forwards the (2)INVITE message to the proper SIP proxy. {+SIP Working Group Informational - Expires 11/22/02 7 SIP Extensions for Media Authorization May 2002+} Assuming the call is not forwarded, the terminating end-point sends a [-(3)183-] {+(3)18x+} response to the initial INVITE via OP. Included in this response is an indication of the negotiated bandwidth requirement for the connection (in the form of an SDP description [8]). When OP receives the [-(3)183,-] {+(3)18x,+} it has sufficient information regarding the end-points, bandwidth and characteristics of the media exchange. It initiates a Policy-Setup message to PDP-o, (4)AuthProfile. The PDP-o stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to the OP, (5)AuthToken. {+SIP Working Group Informational - Expires 11/22/02 8 SIP Extensions for Media Authorization May 2002+} UAC ER-o PDP-o OP [-|(1)Invite-] {+|(1)INVITE+} | | | Client Authentication |------------------------------------------->| and Call [-Authorization-] {+Authoriz.+} | | | | [-(2)Invite-] {+(2)INVITE+} | | | |--------------> | | | | [-(3)180/3-] {+(3)18x+} | | |(4)AuthProfile |<-------------- | | |<--------------| | | |(5)AuthToken | | | |-------------->| Auth. Token put into | | [-|(6)180/3-] {+| (6)18x+} | P-Media-Authorization |<-------------------------------------------| header extension. {+|---(7)PRACK-------------------------------->| | |--(8)PRACK----> | |<-(9)200 (PRACK) |<--(10)200 (PRACK)--------------------------| | | | |+} |Copies the RSVP policy object | |from the P-Media-Authorization | [-|(7)RSVP-PATH-] {+|(11)RSVP-PATH+} | | |----------->| [-(8)REQ-] {+(12)REQ+} | | | |-------------->| Using the Auth-Token and Authorized | | [-(9)DEC-] {+(13)DEC+} | Profile that is set by the SIP Proxy | |<--------------| the PDP makes the decision | | | [-|(10)RSVP-PATH-] {+|(14)RSVP-PATH+} | |------------------------------------------------> | | | [-|(11)RSVP-PATH-] {+|(15)RSVP-PATH+} |<-------------------------------------------------------------- |Copies the RSVP policy object | |from the P-Media-Authorization | [-|(12)RSVP-RESV-] {+|(16)RSVP-RESV+} | | |----------->| [-(13)REQ-] {+(17)REQ+} | | | |-------------->| Using the Auth-Token and Authorized | | [-(14)DEC-] {+(18)DEC+} | Profile that is set by the SIP Proxy | |<--------------| the PDP makes the decision | | | [-|(15)RSVP-RESV-] {+|(19)RSVP-RESV+} | |---------------------------------------------------> | | | [-|(16)RSVP-RESV-] {+|(20)RSVP-RESV+} |<---------------------------------------------------------------- | | | | Figure 2 - Media Authorization with RSVP (UAC) [-SIP Working Group Informational - Expires 11/02/02 7 SIP Extensions for Media Authorization May 2002-] The OP includes the authorization token in the P-Media-Authorization header extension of the [-(6)183-] {+(6)18x+} message. Upon receipt of the [-(6)183-] {+(6)18x+} message, the UAC stores the media authorization token from the P-Media-Authorization header. {+Also, the UAC acknowledges the 18x message by sending a (7)PRACK message which is responded to with (10) 200. SIP Working Group Informational - Expires 11/22/02 9 SIP Extensions for Media Authorization May 2002+} Before sending any media, the UAC requests QoS by sending an [-(7)RSVP-PATH-] {+(11)RSVP-PATH+} message which includes the previously stored [-P-Media-Authorization-Token-] {+P-Media- Authorization-Token+} as a Policy-Element. ER-o, upon [-reception-] {+receipt+} of the [-(7)RSVP-PATH-] {+(11)RSVP-PATH+} message checks the authorization through a PDP-o COPS message exchange, [-(8)REQ.-] {+(12)REQ.+} PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install" Decision, [-(9)DEC.-] {+(13)DEC.+} ER-o checks the admissibility for the request and if admission succeeds, it forwards the [-(10)RSVP-PATH-] {+(14)RSVP-PATH+} message. Once UAC receives the [-(11)RSVP-PATH-] {+(15)RSVP-PATH+} message from UAS it sends the [-(12)RSVP-RESV-] {+(16)RSVP-RESV+} message to reserve the network resources. ER-o, upon receiving the [-(12)RSVP-RESV-] {+(16)RSVP-RESV+} message checks the authorization through a PDP-o COPS message exchange, [-(13)REQ.-] {+(17)REQ.+} PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful PDP-o returns an "install" Decision, [-(14)DEC.-] {+(18)DEC.+} ER-o checks the admissibility for the request and if admission succeeds, it forwards the [-(15)RSVP-RESV-] {+(19)RSVP-RESV+} message. Upon receiving the [-(16)RSVP-RESV-] {+(20)RSVP-RESV+} message, network resources have been reserved in both directions. 6.1.2 User Agent Server Side Figure 3 presents a high-level overview of a call flow with media authorization from the viewpoint of the UAS. Some policy interactions have been omitted for brevity. Since the destination SIP proxy (DP) has sufficient information regarding the endpoints, bandwidth and characteristics of the media exchange, it initiates a Policy-Setup message to the terminating Policy Decision Point (PDP-t) on receipt of the (1)INVITE. SIP Working Group Informational - Expires [-11/02/02 8-] {+11/22/02 10+} SIP Extensions for Media Authorization May 2002 UAS ER-t PDP-t DP | | | | (1)Invite | | | |<-------------- | | | | Proxy Authentication | | | (2)AuthProfile| and Call [-Authorization-] {+Authoriz.+} | | |<--------------| | | | (3)AuthToken | | | |-------------->| Auth. Token put into | | | (4)Invite | P-Media-Authorization |<------------------------------------------| header extension | [-(5)180/3-] {+(5)18x+} | | | |------------------------------------------>| [-(6)180/3-] {+(6)18x+} |Copies the RSVP policy object |--------------> |from the P-Media-Authorization | |(7)RSVP-PATH | | |---------->| (8)REQ | | | |-------------->| Using the Auth-Token and Authorized | | (9)DEC | Profile that is set by the SIP Proxy | |<--------------| the PDP makes the decision | | | |(10)RSVP-PATH | |--------------------------------------------------> | | | |(11)RSVP-PATH |<-------------------------------------------------------------- |Copies the RSVP policy object | |from the P-Media-Authorization | | (12)RSVP-RESV | | |---------->| | | | | (13)REQ | | | |-------------->| Using the Auth-Token and Authorized | | (14)DEC | Profile that is set by the SIP Proxy | |<--------------| the PDP makes the decision | | | |(15)RSVP-RESV | |---------------------------------------------------> | | | |(16)RSVP-RESV |<--------------------------------------------------------------- | | | {+|<-(17)PRACK--------- |<--(18)PRACK ------------------------------| |---(19)200 (PRACK) ----------------------->| | | | |--(20)200 (PRACK)--> | | |+} | Figure 3 - Media Authorization with RSVP (UAS) PDP-t stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to DP. The token is placed in the (4)INVITE message and forwarded to the UAS. Assuming that the call is not forwarded, the UAS sends a [-(5)183-] {+(5)18x+} response to the initial INVITE message, which is forwarded back to UAC. At the same time, the UAS sends [-an-] {+a+} (7)RSVP-PATH message which {+SIP Working Group Informational - Expires 11/22/02 11 SIP Extensions for Media Authorization May 2002+} includes the previously stored P-Media-Authorization-Token as a Policy-Element. ER-t, upon receiving the (7)RSVP-PATH message checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the [-SIP Working Group Informational - Expires 11/02/02 9 SIP Extensions for Media Authorization May 2002-] authorization token it returned to DP. If authorization is successful PDP-t returns an "install" Decision, (9)DEC. ER-t checks the admissibility for the call and if admission succeeds, it forwards the (10)RSVP-PATH message. Once the UAS receives the (11)RSVP-PATH message, it sends [-(12)RSVP-RESV-] {+(12)RSVP- RESV+} message to reserve the network resources. ER-t, upon reception of the (12)RSVP-RESV message, checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the authorization token that it returned to DP. If authorization is successful PDP-t returns an "install" Decision, (14)DEC. ER-t checks the admissibility for the call and if admission succeeds, it forwards the (15)RSVP-RESV message. Upon receiving the (16)RSVP-RESV message, network resources have been reserved in both directions. {+For completeness, we show the (17)PRACK message for the (5) 18x response and the resulting (19) 200 response acknowledging the PRACK.+} 7. Advantages of the Proposed Approach The use of media authorization makes it possible to control the usage of network resources. This in turn makes IP Telephony more robust against denial of service attacks and various kinds of service frauds. By using the authorization capability, the number of flows, and the amount of network resources reserved can be controlled thereby making the IP Telephony system dependable in the presence of scarce resources. 8. Security Considerations In order to control access to QoS, a QoS enabled proxy [-may want to-] {+should+} authenticate the UA before providing it with a media authorization token. Both the method and policy associated with such authentication [-is-] {+are+} outside the scope of this document, however it could for example be done by using standard SIP authentication mechanisms as described in [3]. {+SIP Working Group Informational - Expires 11/22/02 12 SIP Extensions for Media Authorization May 2002+} Media authorization tokens sent in the P-Media-Authorization header from a QoS enabled proxy to a UA MUST be protected from eavesdropping and tampering. This can for example be done through a mechanism such as IPSec or TLS. However, this will only provide [-hop-by-hop-] {+hop- by-hop+} security. If there is one or more intermediaries, e.g. proxies, between the UA and the QoS enabled proxy, these intermediaries will have access to the [-P-Media- Authorization-] {+P-Media-Authorization+} header field value thereby compromising confidentiality and integrity. This will enable both theft-of-service and denial-of-service attacks against the UA. Consequently, the P-Media-Authorization header field MUST NOT be available to any untrusted intermediary in {+the+} clear or without integrity protection. There is currently no mechanism defined in SIP that would satisfy these requirements. Until such a mechanism exists, proxies MUST NOT send P-Media-Authorization headers through untrusted [-intermediaries. SIP Working Group Informational - Expires 11/02/02 10-] {+intermediaries, which might reveal or modify the contents of this header. (Note that S/MIME-based encryption in+} SIP [-Extensions for Media Authorization May 2002-] {+is not available to proxy servers, as proxies are not allowed to add message bodies.)+} QoS enabled proxies may need to inspect message bodies describing media streams, e.g. SDP. Consequently, such message bodies [-SHOULD NOT-] {+should not+} be encrypted. This will in turn prevent end-to-end confidentiality of said message bodies which lowers the overall security possible. 9. IANA Considerations This document defines a new private SIP header for media authorization which is "P-Media-Authorization". {+As recommended by the policy of the Transport Area, this header should be registered by the IANA in the SIP header registry, using the RFC number of this document as its reference.+} 10. Notice Regarding Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 11. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, February 2002. {+SIP Working Group Informational - Expires 11/22/02 13 SIP Extensions for Media Authorization May 2002+} [4] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [5] Herzog, S., RSVP Extensions for Policy Control, RFC 2750, January 2000. 12. Informative References [6] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [7] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification ", RFC 2205, September 1997. [8] Handley, M., Jacobson, V., "SDP: Session Description Protocol", RFC 2327, April 1998. {+[9] Rosenberg, J., Schulzrinne, H., "Reliability of Provisional Responses in SIP", Internet Draft , February 2002. (work in progress). [10] Roach, A., "SIP-Specific Event Notification", draft-ietf-sip- events-05 (work in progress), March 2002. [11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [12] Rosenberg, J., "The Session Initiation Protocol UPDATE Method", draft-ietf-sip-update-02 (work in progress), May 2002.+} 13. Co