Internet DRAFT - draft-hamer-sip-session-auth
draft-hamer-sip-session-auth
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
<draft-hamer-sip-session-auth-00.txt>, 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:<authType>
where authType = "Associated" // Defined in Section 7
| "NonAssociated" // Defined in Section 8
| "Coupled" // Defined in [3]
- Authorization token
a=authToken:<token>
- Authorization lifetime:
a=authTime:<start time> <stop time>
- Identity of the authorizing entity:
a=authIdentity:<URI of the authorizing entity>
Hamer,Gage Expires May 2001 [Page 20]
Internet Draft Session setup with media authorization
- Authorization signature:
a=authSign:<digital signature of the authorizing entity>
where the fields covered by the digital signature are defined by
the <authType>
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 <draft-hamer-sip-session-auth-00.txt>, and
expires May 9, 2001.
Hamer,Gage Expires May 2001 [Page 23]
