The SIP standards community is quite emphatic that proper authentication
policies should be applied. For example, in RFC 4235 (which defines the
dialog event mechanism), there is the following discussion. However, I
do not know of any SIP system which implements any policy other than
"outsiders can't subscribe".
3.6. Notifier Processing of SUBSCRIBE Requests
The dialog information for a user contains sensitive information.
Therefore, all subscriptions SHOULD be authenticated and then
authorized before approval. All implementors of this package MUST
support the digest authentication mechanism as a baseline. The
authorization policy is at the discretion of the administrator, as
always. However, a few recommendations can be made.
It is RECOMMENDED that, if the policy of user B is that user A is
allowed to call them, dialog subscriptions from user A be allowed.
However, the information provided in the notifications does not
contain any dialog identification information, merely an indication
of whether the user is in at least one call. Specifically, they
should not be able to find out any more information than if they sent
an INVITE. (This concept of a "virtual" dialog is discussed more in
Section 3.7.2, and an example of such a notification body is shown
below).
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:[EMAIL PROTECTED]">
<dialog id="as7d900as8">
<state>confirmed</state>
</dialog>
</dialog-info>
A user agent that registers with the address-of-record X SHOULD
authorize subscriptions that come from any entity that can
authenticate itself as X. Complete information on the dialog state
SHOULD be sent in this case. This authorization behavior allows a
group of devices representing a single user to become aware of each
other's state. This is useful for applications such as
single-line-extension, also known as shared lines.
Note that many implementations of "shared-lines" have a feature
that allows details of calls on a shared address-of-record to be
made private. This is a completely reasonable authorization
policy that could result in notifications that contain only the id
attribute of the dialog element and the state element when
shared-line privacy is requested, and notifications with more
complete information when shared-line privacy is not requested.
But in general, the standards community leaves "policy" issues up to the
users.
In practice, I think there are two problems, one technical and one
"political" or user-focused:
- The technical issue is ensuring that phones require that SUBSCRIBEs
are routed to them from a sipX component that is capable of applying
proper policies, in much the same way that we authorized calls to PSTN
gateways. Exactly how sipXproxy implements this and how credentials are
handled starts getting messy with federated systems, but I'm sure we can
work out something that works, once we have an idea of what we want to
do, which is:--
- The user issue is determining what policies the users will want to
apply and having sipXconfig support those in a usable way.
I think the latter problem is going to be more difficult, and we have to
have the requirements for that in mind before we start fretting about
the implementation method.
Dale
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
