Dale Worley wrote: > 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 >
For xecs-1606, I am proposing to write an auth-plugin that will authenticate any dialog-event SUBSCRIBEs addressed to our domain. This means that we lock out all users from external domains (i.e. users we have no credentials for), unless of course they send the SUBSCRIBE straight to the phone, in which case there is nothing we can do. Regarding federated systems, I spoke with bob briefly about it, and he mentioned one way to do this would be to establish a TLS connection to the trusted domains. All dialog event requests coming from these connections will not require local authentication. However, it is not really feasible to do this right now, as we don't yet support TLS. So, for now, all external users are locked out. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
