Another mechanism for authentication is S/MIME. Its usage with SIP
is described fully in RFC 3261 [1]. It provides an end-to-end
authentication mechanism that can be used for a PA to establish the
identity of the subscriber.
6.6.2. Authorization
Once authenticated, the PA makes an authorization decision. A PA
MUST NOT accept a subscription unless authorization has been provided
by the presentity. The means by which authorization are provided are
outside the scope of this document. Authorization may have been
provided ahead of time through access lists, perhaps specified in a
web page. Authorization may have been provided by means of uploading
of some kind of standardized access control list document. Back end
authorization servers, such as a DIAMETER [12] server, can also be
used. It is also useful to be able to query the user for
authorization following the receipt of a subscription request for
which no authorization information has been provided. The
"watcherinfo" event template package for SIP [8] defines a means by
which a presentity can become aware that a user has attempted to
subscribe to it, so that it can then provide an authorization
decision.
Authorization decisions can be very complex. Ultimately, all
authorization decisions can be mapped into one of three states:
rejected, successful, and pending. Any subscription for which the
client is authorized to receive information about some subset of
presence state at some points in time is a successful subscription.
Any subscription for which the client will never receive any
information about any subset of the presence state is a rejected
subscription. Any subscription for which it is not yet known whether
it is successful or rejected is pending. Generally, a pending
subscription occurs when the server cannot obtain authorization at
the time of the subscription, but may be able to do so at a later
time, perhaps when the presentity becomes available.
The appropriate response codes for conveying a successful, rejected,
or pending subscription (200, 403 or 603, and 202, respectively) are
described in RFC 3265 [2].
If the resource is not in a meaningful state, RFC 3265 [2] allows the
body of the initial NOTIFY to be empty. In the case of presence,
that NOTIFY MAY contain a presence document. This document would
indicate whatever presence state the subscriber has been authorized
to see; it is interpreted by the subscriber as the current presence
state of the presentity. For pending subscriptions, the state of the
presentity SHOULD include some kind of textual note that indicates a
pending status.
Polite blocking, as described in [13], is possible by generating a
200 OK to the subscription even though it has been rejected (or
marked pending). Of course, an immediate NOTIFY will still be sent.
The contents of the presence document in such a NOTIFY are at the
discretion of the implementor, but SHOULD be constructed in such a
way as to not reveal to the subscriber that their request has
actually been blocked. Typically, this is done by indicating
"offline" or equivalent status for a single contact address.
6.7. Notifier Generation of NOTIFY Requests
RFC 3265 details the formatting and structure of NOTIFY messages.
However, packages are mandated to provide detailed information on
when to send a NOTIFY, how to compute the state of the resource, how
to generate neutral or fake state information, and whether state
information is complete or partial. This section describes those
details for the presence event package.
A PA MAY send a NOTIFY at any time. Typically, it will send one when
the state of the presentity changes. The NOTIFY request MAY contain
a body indicating the state of the presentity. The times at which
the NOTIFY is sent for a particular subscriber, and the contents of
the body within that notification, are subject to any rules specified
by the authorization policy that governs the subscription. This
protocol in no way limits the scope of such policies. As a baseline,
a reasonable policy is to generate notifications when the state of
any of the presence tuples changes. These notifications would
contain the complete and current presence state of the presentity as
known to the presence agent. Future extensions can be defined that
allow a subscriber to request that the notifications contain changes
in presence information only, rather than complete state.
In the case of a pending subscription, when final authorization is
determined, a NOTIFY can be sent. If the result of the authorization
decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
presence document with the current state of the presentity. If the
subscription is rejected, a NOTIFY MAY be sent. As described in RFC
3265 [2], the Subscription-State header field indicates the state of
the subscription.
The body of the NOTIFY MUST be sent using one of the types listed in
the Accept header field in the most recent SUBSCRIBE request, or
using the type "application/pidf+xml" if no Accept header field was
present.
The means by which the PA learns the state of the presentity are also
outside the scope of this recommendation. Registrations can provide
a component of the presentity state. However, the means by which a
PA uses registrations to construct a presence document are an
implementation choice. If a PUA wishes to explicitly inform the
presence agent of its presence state, it should explicitly publish
the presence document (or its piece of it) rather than attempting to
manipulate their registrations to achieve the desired result.
For reasons of privacy, it will frequently be necessary to encrypt
the contents of the notifications. This can be accomplished using
S/MIME. The encryption can be performed using the key of the
subscriber as identified in the From field of the SUBSCRIBE request.
Similarly, integrity of the notifications is important to
subscribers. As such, the contents of the notifications MAY provide
authentication and message integrity using S/MIME. Since the NOTIFY
is generated by the presence server, which may not have access to the
key of the user represented by the presentity, it will frequently be
the case that the NOTIFY is signed by a third party. It is
RECOMMENDED that the signature be by an authority over the domain of
the presentity. In other words, for a user pres:user@example.com,
the signator of the NOTIFY SHOULD be the authority for example.com.
6.8. Subscriber Processing of NOTIFY Requests
RFC 3265 [2] leaves it to event packages to describe the process
followed by the subscriber upon receipt of a NOTIFY request,
including any logic required to form a coherent resource state.
In this specification, each NOTIFY contains either no presence
document, or a document representing the complete and coherent state
of the presentity. Within a dialog, the presence document in the
NOTIFY request with the highest CSeq header field value is the
current one. When no document is present in that NOTIFY, the
presence document present in the NOTIFY with the next highest CSeq
value is used. Extensions which specify the use of partial state for
presentities will need to dictate how coherent state is achieved.
6.9. Handling of Forked Requests
RFC 3265 [2] requires each package to describe handling of forked
SUBSCRIBE requests.
This specification only allows a single dialog to be constructed as a
result of emitting an initial SUBSCRIBE request. This guarantees
that only a single PA is generating notifications for a particular
subscription to a particular presentity. The result of this is that
a presentity can have multiple PAs active, but these should be
homogeneous, so that each can generate the same set of notifications
for the presentity. Supporting heterogeneous PAs, each of which
generates notifications for a subset of the presence data, is complex
and difficult to manage. Doing so would require the subscriber to
act as the aggregator for presence data. This aggregation function
can only reasonably be performed by agents representing the
presentity. Therefore, if aggregation is needed, it MUST be done in
a PA representing the presentity.
Section 4.4.9 of RFC 3265 [2] describes the processing that is
required to guarantee the creation of a single dialog in response to
a SUBSCRIBE request.
6.10. Rate of Notifications
RFC 3265 [2] requires each package to specify the maximum rate at
which notifications can be sent.
A PA SHOULD NOT generate notifications for a single presentity at a
rate of more than once every five seconds.
6.11. State Agents
RFC 3265 [2] requires each package to consider the role of state
agents in the package, and if they are used, to specify how
authentication and authorization are done.
State agents are core to this package. Whenever the PA is not
co-located with the PUA for the presentity, the PA is acting as a
state agent. It collects presence state from the PUA, and aggregates
it into a presence document. Because there can be multiple PUA, a
centralized state agent is needed to perform this aggregation. That
is why state agents are fundamental to presence. Indeed, they have a
specific term that describes them - a presence server.
6.11.1. Aggregation, Authentication, and Authorization
The means by which aggregation is done in the state agent is purely a
matter of policy. The policy will typically combine the desires of
the presentity along with the desires of the provider. This document
in no way restricts the set of policies which may be applied.
However, there is clearly a need for the state agent to have access
to the state of the presentity. This state is manipulated by the
PUA. One way in which the state agent can obtain this state is to
subscribe to it. As a result, if there were 5 PUA manipulating
presence state for a single presentity, the state agent would
generate 5 subscriptions, one to each PUA. For this mechanism to be
effective, all PUA SHOULD be capable of acting as a PA for the state
that they manipulate, and that they authorize subscriptions that can
be authenticated as coming from the domain of the presentity.
The usage of state agents does not significantly alter the way in
which authentication is done by the PA. Any of the SIP
authentication mechanisms can be used by a state agent. However,
digest authentication will require the state agent to be aware of the
shared secret between the presentity and the subscriber. This will
require some means to securely transfer the shared secrets from the
presentity to the state agent.
The usage of state agents does, however, have a significant impact on
authorization. As stated in Section 6.6, a PA is required to
authorize all subscriptions. If no explicit authorization policy has
been defined, the PA will need to query the user for authorization.
In a presence edge server (where the PUA is co-located with the PUA),
this is trivially accomplished. However, when state agents are used
(i.e., a presence server), a means is needed to alert the user that
an authorization decision is required. This is the reason for the
watcherinfo event template-package [8]. All state agents SHOULD
support the watcherinfo template-package.
6.11.2. Migration
On occasion, it makes sense for the PA function to migrate from one
server to another. For example, for reasons of scale, the PA
function may reside in the presence server when the PUA is not
running, but when the PUA connects to the network, the PA migrates
subscriptions to it in order to reduce state in the network. The
mechanism for accomplishing the migration is described in Section
3.3.5 of RFC 3265 [2]. However, packages need to define under what
conditions such a migration would take place.
A PA MAY choose to migrate subscriptions at any time, through
configuration, or through dynamic means. The REGISTER request
provides one dynamic means for a presence server to discover that the
function can migrate to a PUA. Specifically, if a PUA wishes to
indicate support for the PA function, it SHOULD use the callee
capabilities specification [9] to indicate that it supports the
SUBSCRIBE request method and the presence event package. The
combination of these two define a PA. Of course, a presence server
can always attempt a migration without these explicit hints. If it
fails with either a 405 or 489 response code, the server knows that
the PUA does not support the PA function. In this case, the server
itself will need to act as a PA for that subscription request. Once
such a failure has occurred, the server SHOULD NOT attempt further
migrations to that PUA for the duration of its registration.
However, to avoid the extra traffic generated by these failed
requests, a presence server SHOULD support the callee capabilities
extension.
Furthermore, indication of support for the SUBSCRIBE request and the
presence event package is not sufficient for migration of
subscriptions. A PA SHOULD NOT migrate the subscription if it is
composing aggregated presence documents received from multiple PUA.
7. Learning Presence State
Presence information can be obtained by the PA in many ways. No
specific mechanism is mandated by this specification. This section
overviews some of the options, for informational purposes only.
7.1. Co-location
When the PA function is co-located with the PUA, presence is known
directly by the PA.
7.2. REGISTER
A UA uses the SIP REGISTER method to inform the SIP network of its
current communications addresses (i.e., Contact addresses). Multiple
UA can independently register Contact addresses for the same
address-of-record. This registration state represents an important
piece of the overall presence information for a presentity. It is an
indication of basic reachability for communications.
Usage of REGISTER information to construct presence is only possible
if the PA has access to the registration database, and can be
informed of changes to that database. One way to accomplish that is
to co-locate the PA with the registrar.
The means by which registration state is converted into presence
state is a matter of local policy, and beyond the scope of this
specification. However, some general guidelines can be provided.
The address-of-record in the registration (the To header field)
identifies the presentity. Each registered Contact header field
identifies a point of communications for that presentity, which can
be modeled using a tuple. Note that the contact address in the tuple
need not be the same as the registered contact address. Using an
address-of-record instead allows subsequent communications from a
watcher to pass through proxies. This is useful for policy
processing on behalf of the presentity and the provider.
A PUA that uses registrations to manipulate presence state SHOULD
make use of the SIP callee capabilities extension [9]. This allows
the PUA to provide the PA with richer information about itself. For
example, the presence of the methods parameter listing the method
"MESSAGE" indicates support for instant messaging.
The q values from the Contact header field [1] can be used to
establish relative priorities amongst the various communications
addresses in the Contact header fields.
The usage of registrations to obtain presence information increases
the requirements for authenticity and integrity of registrations.
Therefore, REGISTER requests used by presence user agents MUST be
authenticated.
7.3. Uploading Presence Documents
If a means exists to upload presence documents from PUA to the PA,
the PA can act as an aggregator and redistributor of those documents.
The PA, in this case, would take the presence documents received from
each PUA for the same presentity, and merge the tuples across all of
those PUA into a single presence document. Typically, this
aggregation would be accomplished through administrator or user
defined policies about how the aggregation should be done.
The specific means by which a presence document is uploaded to a
presence agent are outside the scope of this specification. When a
PUA wishes to have direct manipulation of the presence that is
distributed to subscribers, direct uploading of presence documents is
RECOMMENDED.
8. Example Message Flow
This message flow illustrates how the presence server can be
responsible for sending notifications for a presentity. This flow
assumes that the watcher has previously been authorized to subscribe
to this resource at the server.
In this flow, the PUA informs the server about the updated presence
information through some non-SIP means.
When the value of the Content-Length header field is "..." this means
that the value should be whatever the computed length of the body is.
Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| F3 NOTIFY | |
|<------------------| |
| F4 200 OK | |
|------------------>| |
| | |
| | Update presence |
| |<------------------ |
| | |
| F5 NOTIFY | |
|<------------------| |
| F6 200 OK | |
|------------------>| |
Message Details
F1 SUBSCRIBE watcher->example.com server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
To: <sip:resource@example.com>
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600
Content-Length: 0
F2 200 OK example.com server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:resource@example.com>;tag=ffd2
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Expires: 600
Contact: sip:server.example.com
Content-Length: 0
F3 NOTIFY example.com server-> watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
Event: presence
Subscription-State: active;expires=599
Max-Forwards: 70
CSeq: 8775 NOTIFY
Contact: sip:server.example.com
Content-Type: application/pidf+xml
Content-Length: ...
[PIDF Document]
F4 200 OK watcher-> example.com server
SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8775 NOTIFY
Content-Length: 0
F5 NOTIFY example.com server -> watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Event: presence
Subscription-State: active;expires=543
Max-Forwards: 70
Contact: sip:server.example.com
Content-Type: application/pidf+xml
Content-Length: ...
[New PIDF Document]
F6 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Content-Length: 0
9. Security Considerations
There are numerous security considerations for presence. RFC 2779
[13] outlines many of them, and they are discussed above. This
section considers them issue by issue.
9.1. Confidentiality
Confidentiality encompasses many aspects of a presence system:
o Subscribers may not want to reveal the fact that they have
subscribed to certain users
o Users may not want to reveal that they have accepted
subscriptions from certain users
o Notifications (and fetch results) may contain sensitive data
which should not be revealed to anyone but the subscriber
Confidentiality is provided through a combination of hop-by-hop
encryption and end-to-end encryption. The hop-by-hop mechanisms
provide scalable confidentiality services, disable attacks involving
traffic analysis, and hide all aspects of presence messages.
However, they operate based on transitivity of trust, and they cause
message content to be revealed to proxies. The end-to-end mechanisms
do not require transitivity of trust, and reveal information only to
the desired recipient. However, end-to-end encryption cannot hide
all information, and is susceptible to traffic analysis. Strong
end-to-end authentication and encryption can be done using public
keys, and end-to-end encryption can be done using private keys [14].
Both hop-by-hop and end-to-end mechanisms will likely be needed for
complete privacy services.
SIP allows any hop by hop encryption scheme, but TLS is mandatory to
implement for servers. Therefore, it is RECOMMENDED that TLS [7] be
used between elements to provide this function. The details for
usage of TLS for server-to-server and client-to-server security are
detailed in Section 26.3.2 of RFC 3261 [1].
SIP encryption, using S/MIME, MAY be used end-to-end for the
transmission of both SUBSCRIBE and NOTIFY requests.
9.2. Message Integrity and Authenticity
It is important for the message recipient to ensure that the message
contents are actually what was sent by the originator, and that the
recipient of the message be able to determine who the originator
really is. This applies to both requests and responses of SUBSCRIBE
and NOTIFY. NOTIFY requests are particularly important. Without
authentication and integrity, presence documents could be forged or
modified, fooling the watcher into believing incorrect presence
information.
RFC 3261 provides many mechanisms to provide these features. In
order for the PA to authenticate the watcher, it MAY use HTTP Digest
(Section 22 of RFC 3261). As a result, all watchers MUST support
HTTP Digest. This is a redundant requirement, however, since all SIP
user agents are mandated to support it by RFC 3261. To provide
authenticity and integrity services, a watcher MAY use the SIPS
scheme when subscribing to the presentity. To support this, all PA
MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1
of RFC 3261).
Furthermore, SMIME MAY be used for integrity and authenticity of
SUBSCRIBE and NOTIFY requests. This is described in Section 23 of