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

From: [email-masked]
Date: Tue, 2 Nov 2004 11:55:29 +0200

> -----Original Message-----
> From: ext Daniel G. Petrie [mailto:[email-masked]]
> Sent: 23.October.2004 12:32
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
> Subject: RE: [Sipping] Comments on config framework draft - security
> issues
> 
> 
> 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

The link in the NOTIFY body that points to the indirected content needs protecting. I know that HTTPS can be used to protect the content itself, but at least you need to mention and recommend that.

> 
> > 
> > - "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.

Ok, fair enough.

> 
> 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.

This is a continuation from 1. In 1, a user is enabled to talk to administrator (help desk). The user who is requesting to be provisioned needs to be authenticated (I can plug and claim to be whoever), so further steps are needed.

I would recommend including this use case in the draft and suggesting that after the administrator configures the user in, the administrator terminates the subscription with a reason "deactivated". This results in an immediate new subscription that can be challenged (this is a SHOULD strength in RFC 3265).

deactivated: The subscription has been terminated, but the subscriber
      SHOULD retry immediately with a new subscription.  One primary use
      of such a status code is to allow migration of subscriptions
      between nodes.  The "retry-after" parameter has no semantics for
      "deactivated".

> 
> > 
> > - "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.

No you don't want that, but my point was that you cannot prevent it by stating that a user must manually provoke ...

Regards,
Hisham

> 
> > 
> > 
> > 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