Subject: RE: [Sipping] Comments on config framework draft - security issues

From: "Daniel G. Petrie" <[email-masked]>
Date: Sat, 23 Oct 2004 05:32:08 -0400

Hisham Khartabil wrote:

> 
> Section 3.6
> -----------
> 
> - "If content indirection is used for delivering the
>    profiles, the notifier does not need to authenticate the subscription
>    as the profile content is not transported in the SUBSCRIBE or NOTIFY
>    transaction messages."
> 
> So what? the body of the NOTIFY still contains valuable information. I think it is a bad idea to suggest that authentication is not needed. I would say authentication is always needed.

What is there that authentication is going to protect?  Dialog information
and the profile URI are not protected by authentication. These require
TLS and S/MIME

> 
> - "If the user or device is not known to the profile delivery server,
>    the implementer MAY accept the subscription or reject it.  It is
>    recommended that the implementer accept the subscription."
> 
> I think this is a very bad recommendation. This a a potential DoS attack on the server. The server should reject any subscriptions from unknown users or devices (opposite to the current recommendation)

There are a few important use cases that require the subscriptions 
from unknown user agents to be accepted.

1) A new user agent is plugged into an enterprise environment.  The
subscription server accepts the subscription and provides a default
device profile that gives the device the ability to call the help
desk (UA administrator) and emergency services.

2) A new user agent is plugged into an enterprise environment.  The
user then tells the admin that the UA is plugged in and requests that
it be assigned to the user (i.e. provisions profile delivery server to
make the UA a known UA).  The profile delivery server then sends a 
NOTIFY in the dialog of the subscription to provide the UA with its 
device profile.  The UA is then provisioned without requiring any
user action on the user agent.

> 
> - "If the profile delivery server does not accept the subscription from
>    an unknown user or device, the administer or user must manually
>    provoke the user agent to reSUBSCRIBE."
> 
> So what? a UA can automatically and regularly retry the subscription if it wants.

You do not want a bunch of new UAs in an enterprise polling with a 
SUBSCRIBE every minute to check if the profile delivery server now
has a profile.  That is a bigger DoS problem than accepting the
subscription.

> 
> 
> Section 4.2
> ------------
> 
> - "However the profile server SHOULD
>    accept (with 2xx response) SUBSCRIBE requests from any user agent as
>    explained in Section 3.5."
> 
> I repeat my concerns here. This is a potential DoS attack.
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP