Internet Engineering Task Force SIPPING WG
Internet Draft D. Trossen
Nokia Research
H. Schulzrinne
Columbia University
draft-trossen-sipping-ondemand-01.txt 24. August 2004
Expires: Feb. 2005
Ad-hoc Access Authorization for SIP Event Subscriptions
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (c) The Internet Society (2003). All rights reserved.
Abstract
A target or presentity may want to temporarily allow limited access
to its location or presence information to a third party. We will
describe in this document use cases and solutions (focusing on the
delivery of geospatial information and presence). We will further
outline the relation to ongoing SIMPLE and GEOPRIV work.
Trossen, Schulzrinne Expires February 2005 [1]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
Table of Contents
1. Introduction....................................................3
2. Terminology.....................................................3
3. Use Cases.......................................................4
3.1. Enhanced Location Services....................................5
3.2. Context-aware News Service....................................5
3.3. Service Discovery in Visitor Environment......................5
3.4. Match Making Service..........................................5
3.5. Context-aware Gaming..........................................5
4. Design Alternatives and Relation to SIMPLE and GEOPRIV Work.....6
4.1. Data Push.....................................................6
4.2. Policy Conveyance via Rule Holder or directly to SIP Event
Server.............................................................7
4.3. Policy Conveyance from Rule Maker to Subscriber...............7
5. Protocol for Policy Conveyance Within Subscriptions.............8
5.1. Conveyance of Authorization Policy towards Subscriber.........8
5.2. Subscriber Generation of SUBSCRIBE Requests...................8
5.3. Notifier Processing of SUBSCRIBE Requests.....................9
6. Open Issues.....................................................9
7. Security Considerations.........................................9
8. Acknowledgements...............................................10
9. References.....................................................10
10. Authors' Addresses............................................10
Trossen, Schulzrinne Expires February 2005 [2]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
1. Introduction
Access authorization for SIP event subscriptions is crucial due to
the highly private nature of information revealed in the resulting
notifications, e.g., all presence subscriptions must be authorized
by the presentity. Work is currently ongoing within the SIMPLE and
GEOPRIV working groups to define, manage and convey authorization
policies for resource information such as geospatial information [1]
and presence [8].
The policy documents envisioned in [1] are based on a three-step
process. In the first step, the target or presentity composes a set
of rules. In the model noted, these rules are encoded as a sequence
of XML elements, each element representing a rule allowing
comparison by user identity, time of day and other factors. These
rules are, as a second step, uploaded to the presence agent
(PA) or location server (LS). Since they have similar roles, we
refer to this entity as a PA/LS. The protocol for uploading might be
XCAP [9], among other choices. In the final step, the rules are
applied when subscriptions arrive and when a notification is
generated for a particular watcher.
It is important to note that policy documents may allow anonymous
access, i.e., access that does not depend on the querier or
subscriber to identify itself. In this document however, we are only
concerned with identity-dependent access, i.e., where access depends
on the identity of the entity requesting the information.
Most of the discussions for authorization have assumed long-term
relationships between the entities requesting information and the
target or presentity. However, there is a class of applications
where the presentity or target wishes to grant temporary and limited
access to its data to services. In this, the service might require a
single or more than one sample of the location or presence
information to perform its function. These services might transform
the presence or location data into more useful renditions or use it
to provide services that have little to do with presence or
location. Section 3 discusses some examples of these services.
Several design alternatives are possible to tackle the above
outlined problem of temporarily granting access to presence or
location information. Section 4 discusses these design alternatives
and their relation to the currently ongoing work in the SIMPLE and
GEOPRIV working groups. While there exist solutions for most of
these design alternatives, we present in Section 5 a particular
solution for one of the design alternatives.
2. Terminology
Resource: A resource in the scope of this document is an object to
which a certain state information is associated, called æresource
dataÆ in the remainder of the document. Examples are presence as
a resource belonging to the presentity. The resource data is the
Trossen, Schulzrinne Expires February 2005 [3]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
current presence information (subject to the particular
disclosure policy of the presentity). Resources can also be
associated to devices, such as printers, in which the resource
data represents, for instance, the current state of the printer.
In the context of the SIP event framework, the resource state is
abstracted with SIP events and hosted at particular SIP event
servers.
Resource owner: An entity that has authorization power over the
particular resource data. Examples are presentities in SIP
presence or rule makers as introduced in [1].
Information generator: An entity that determines or gathers resource
data for a particular resource. Examples are publishers in SIP
presence or location generators in GEOPRIV [1].
3. Use Cases
With the defined terminology of Section 2, consider that a
subscriber S desires access to a particular resource D (or
particular parts of the resource), such as presence or geospatial
location information, at a particular SIP event server. In this, the
desire for access is somehow conveyed from the subscriber towards
the resource owner A. The desired access can be time-limited or
limited in notifications (such as time window based, one-time or N-
time notifications).
The following additional constraints might occur:
* The identity of the subscriber might not be known to the
resource owner before the desire for access is conveyed towards
the resource owner.
* The type of access, i.e., the resource as such as well as the
resource data, might not be known to the resource owner before
the desire for access is conveyed towards the resource owner.
* The conveyance of the desire to access the resource data and the
actual access might lie within a rather short time window.
The problem to be solved is to enable an authorized access to the
desired resource by the subscriber at the SIP event server. It is
worth mentioning that such authorized access is not restricted to
currently discussed presence items only rather than to any kind of
(future) presence items or SIP events in general.
Further note that it is beyond the scope of this document as to how
the subscriber conveys the desire for access to the resource owner.
A variety of methods, such as within an HTTP or SOAP transaction
between subscriber and resource owner (see also the following use
cases), are possible for such conveyance.
In the following, use cases are presented as examples for such
temporary access to resource information.
Trossen, Schulzrinne Expires February 2005 [4]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
3.1. Enhanced Location Services
Consider the provisioning of location-based services from a service
provider (the subscriber S) to a user (the resource owner A).
As an example, Alice would like a mapping service S to create a map
that plots her trajectory for a limited time period, For this, S
needs access to location data, but only for a limited time.
3.2. Context-aware News Service
Alice subscribes to a news service that delivers news items adapted
to her current activity, mood and location. In order to perform the
adaptation, the news provider S needs to access particular presence
items for the time of the news delivery (which can be rather
temporary in cases where the content was found during surfing the
Internet).
3.3. Service Discovery in Visitor Environment
Alice would like to discover services in a visitor environment
(i.e., Alice and the discovery system most likely do not have an
existing trust relationship), the service selection depending on her
location, activity, currently used communication devices and other
information. In order to perform the appropriate (context-aware)
filtering of available services, the discovery agent requires access
to AliceÆs information, such as presence or location.
3.4. Match Making Service
Alice temporarily subscribes to a match making service (e.g., within
an amusement park or bar) that alerts its customers if two or more
compatible individuals are in close proximity. In order to perform
the desired match making, the match making service provider might
require access to certain user information, such as location within
the point of interest (if the place is larger) or current activity.
3.5. Context-aware Gaming
Mobile games combine players moving about in the real world with
computer-mediated interaction. Such games require rich presence
information, including sensor data representing activities (such as
æstandingÆ or æwalkingÆ) and current location. All players have to
be able to subscribe to the location of, say, their teammates. Such
games could be established between a-priori unknown parties (ad-hoc
gaming in point-of-interest for instance) but could also require a-
priori unknown set of information from either player.
Hence, upon starting the game, each player requires access
authorization for this particular set of information from each of
the other players for the duration of the game (if the duration of
the game is unknown, the authorization can be renewed before
expiring).
Trossen, Schulzrinne Expires February 2005 [5]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
4. Design Alternatives and Relation to SIMPLE and GEOPRIV Work
As said in the introduction, different design alternatives exist to
tackle the problem of temporarily granting access to presence or
location information. This section outlines these design
alternatives in the context of ongoing SIMPLE and GEOPRIV work in
the area of access authorization for SIP events.
The following picture outlines the relation of the different design
alternatives to this ongoing work. For this, we use the GEOPRIV
architecture as introduced in [1]. However, for the sake of
generality the entities are named independent of the particular
resource data, i.e., the information generator equals the location
generator in [1], while the SIP event server equals the location
server and the SIP event subscriber the location recipient in [1].
The SIP event subscriber in this figure is similar to the service
provider in the use cases.
+---------------------------------------------+
+----+---+ +----------+ |
| Rule | (2) | Rule | |(4)
| Maker +----------->| Holder | |
++-+---+-+ +----+-----+ |
| | /|\ |(2) |
(3)| | | | |
V | |(1) V V
+--------+----+ +----------+ (4) +----------+
| Information | (3) | SIP Event|<----------|SIP Event |
| Generator +-------->| Server +---------->|Subscriber|
+-------------+ +----------+ +-----+----+
| /|\
+-----------------------------------------------+
(1)
Figure 1: Design Alternatives And Their Relation to Ongoing Work
Figure 1 shows four different alternatives to tackle the problem of
temporarily granting access to the desired information. These
alternatives are discussed in the following.
4.1. Data Push
In data push mode (alternative (1) in the figure), resource owners
do not allow subscriptions at all. Rather, the rule maker simply
delivers the desired resource information (after having the
information obtained from the information generator), e.g., presence
or location data, via, e.g., SIP MESSAGE, to the service provider.
This mode offers the presentity/target (P/T) complete control over
data delivery, but otherwise has little to recommend it. It requires
that the P/T establish an authentication relationship with the
service provider so that the service provider can know who is
submitting data. The P/T has to guess how often the service provider
needs updated data. Finally, this method is not very bandwidth
Trossen, Schulzrinne Expires February 2005 [6]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
efficient for mobile P/Ts as, e.g., they may need to obtain location
data from a location generator and then transport the data again
over the same air interface, possibly in multiple copies to multiple
service providers.
4.2. Policy Conveyance via Rule Holder or directly to SIP Event Server
In case (2) of the figure above, the rule maker defines the
appropriate authorization policy and conveys it to the rule holder
using, e.g., XCAP operations [4] for upload. The authorization
policy is then pushed to or pulled by the SIP event server, e.g.,
using the XCAP event package [5]. Incoming subscriptions then use
the available authorization policy information to grant or deny the
subscription.
In case (3) of the figure above, the rule maker is publishing the
authorization policy directly to the SIP event server via the
information generator. The conveyance from the information generator
to the SIP event server usually happens during the publication of
the particular information itself to the SIP event server.
In case of a temporary access, both schemes require additional steps
in order to cope with the temporary character of the desired access:
(1) Create a new identity for the subscriber S or ask S for the
identity it wants to use in the subscription to the data. (A may
only know S as a web page, so it cannot necessarily guess the
user identity.) There does not appear to be a standard protocol
for this step.
(2) Create a policy rule that allows appropriate access for the
particular resource information by this identity.
(3) Create a user-password entry so that S can authenticate itself,
e.g., via Digest authentication. The password can be created by
S or A, but in either case needs to be exchanged securely.
(4) Remove the rule when S no longer needs access, to avoid
inflating the policy information at the SIP event server and
rule holder.
This approach clearly works, as it corresponds to the normal mode of
managing subscribers. However, it incurs significant complexity and
is particularly inefficient in mobile environments.
4.3. Policy Conveyance from Rule Maker to Subscriber
Alternative (4) in the figure above outlines the policy conveyance
from the rule maker directly to the subscriber, then to be used in
the particular subscription. As a simple solution, the rule maker
could send the subscriber a subscription URI that includes the
authorization policy, such as
sip:alice:Z@example.com
Trossen, Schulzrinne Expires February 2005 [7]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
where Z is the encrypted authorization policy and alice@example.com
is the rule makerÆs URI. The subscriber will use the provided
subscriber URI in its subscription. This approach only works if the
policy is relatively simple, e.g., a selection of standard data
profiles combined with a time limitation.
5. Protocol for Policy Conveyance Within Subscriptions
The design alternative in Section 4.3 outlined the conveyance of the
(temporary) access authorization policy from the rule maker directly
to the subscriber. The suggested usage of a subscription URI that
includes the (encrypted) policy bears the problem of allowing only
simple policies. To overcome this problem, this section outlines a
protocol for conveying the particular policy as part of the
SUBSCRIBE message body itself.
The protocol operation is divided into three steps, explained in the
following.
5.1. Conveyance of Authorization Policy towards Subscriber
The first step is concerned with generating and conveying an
authorization policy towards the subscriber for the particular
information.
For that, the rule maker, according to Figure 1, generates such
authorization rules for the particular pieces of resource
information that are desired to be accessed by the subscriber. The
rule maker signs the authorization rules description for
authenticity and conveys the signed authorization information
towards the subscriber.
It is beyond the scope of this document how the rule maker obtained
knowledge as to which information the subscriber desires to
subscribe to (usually, certain service interactions with the
subscriber will convey such knowledge beforehand, such as web page
interactions). Further, the protocol that is used to convey the
signed authorization policy from the rule maker to the subscriber is
beyond the scope of this document. Candidates for such operation are
HTTP or SOAP.
AUTHOR NOTE: Details of protocol operation, such as for signing, and
exact referencing of the XCAP application usages are still missing.
5.2. Subscriber Generation of SUBSCRIBE Requests
After the subscriber in Figure 1 received the signed authorization
policy for the subscription, it will include this authorization
policy in future subscriptions according to the provided
authorization policy.
For that, the subscriber will include the signed policy in the
message body of the subscription, in addition to event package
Trossen, Schulzrinne Expires February 2005 [8]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
specific information, such as presence document information,
according to RFC 3265 [7] (i.e., using multi-part bodies).
AUTHOR NOTE: Details of protocol operation, such as inclusion of
policy in message bodies, are still missing.
5.3. Notifier Processing of SUBSCRIBE Requests
The notifier will process incoming SUBSCRIBE requests according to
RFC 3265 [7]. If the inclusion of the signed authorization policy in
the message body is indicated, the signed policy information is
extracted from the body.
The extracted policy information is then forwarded to the rule
holder (see Figure 1).
The rule holder verifies the signature of the received authorization
policy. If the verification has been successful, the authorization
policy is deemed valid. The success or failure of the verification
is signaled to the notifier, which in turn grants or denies the
submission appropriately.
AUTHOR NOTE: Details of using protocol between notifier and rule
holder is missing. Is this in scope of the document?
6. Open Issues
* Verification Step: Is the protocol between notifier and rule
holder for verification purpose within scope of the document?
What are candidates for this protocol?
* Usage of authorization policy: After the authorization policy
was verified by the rule holder, is the answer simply conveyed
back to the notifier or is the policy used otherwise. One could
see the authorization policy as implicitly defined (and
verified) and the rule holder could add the policy to its
current policy document. Or we use it for THIS subscription only
and discard the policy at the rule holder after verification.
7. Security Considerations
A solution for the problem described in this document shall allow
for granting access in ad-hoc authorization scenarios as described
in Section 3.2. In this, any solution should allow for
* defining all relevant resource information in the authorization,
* tying the access to a particular querier, if so desired by the
resource owner,
* preventing re-usage of the authorization through the querier or
third parties,
* preventing disclosure of the authorization to third parties
* tying the access to a particular (relative or absolute) time
window, if so desired by the resource owner, and
* verifying the identity of the resource owner.
Trossen, Schulzrinne Expires February 2005 [9]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
These security considerations have been identified and are addressed
through the mechanism presented in Section 5.
8. Acknowledgements
The authors would like to thank Dana Pavel for her input.
9. References
[1] J. Cuellar et al., "Geopriv Requirements", RFC 3693, Internet
Engineering Task Force, February 2004.
[2] H. Sugano, S. Fujimoto, et al., "Presence information data
format (PIDF)", Internet draft, Internet Engineering Task
Force, (work in progress), May 2003.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels", RFC 2119, Internet Engineering Task Force, March 1997.
[4] J. Rosenberg, "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Internet Draft, Internet
Engineering Task Force, (work in progress), May 2003.
[5] J. Rosenberg, "A Session Initiation Protocol (SIP) Event
Package for Modification Events for the Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Managed
Documents", Internet Draft, Internet Engineering Task Force,
(work in progress), May 2003.
[6] H. Schulzrinne (ed.), "RPID -- Rich Presence Information Data
Format", Internet Draft, Internet Engineering Task Force, (work
in progress), July 2003.
[7] A. Roach, "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, Internet Engineering Task Force, June
2002.
[8] J. Rosenberg, ôA Presence Event Package for the Session
Initiation Protocol (SIP)ö, Internet Draft, Internet
Engineering Task Force, (work in progress), July 2003.
[9] J. Rosenberg ôThe Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)ö, Internet Draft, Internet
Engineering Task Force, (work in progress), February 2004.
10. Authors' Addresses
Dirk Trossen
Nokia Research
5 Wayside Road
Burlington, MA 02474 USA
Email: dirk.trossen@nokia.com
Trossen, Schulzrinne Expires February 2005 [10]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027 USA
Email: schulzrinne@cs.columbia.edu
Trossen, Schulzrinne Expires February 2005 [11]
Internet Draft Ad-hoc Authorization for SIP SUBSCRIBE August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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.
Trossen, Schulzrinne Expires February 2005 [12]