Cisco SPA with DHCP Options 66 problem

[desmond.hui]

Dear All,

I have a problem of my Cisco SPA phone for auto provisioning.

If i manually get into the provisioning page and paste "[--uid user --pwd password] http://<IP address>/dms/def/spa$PSN.cfg" into Profile Rule. Everything work perfectly. 

However we would like to do it in zero-touch provision, i add the "[--uid user --pwd password] http://<IP address>/dms/def/spa$PSN.cfg" to DHCP Options 66. The SPA Phone seems cannot get the Options 66 Parameter. It only shows "/spa$PSN.cfg" in the Profiles Rule.

I am sure the DHCP server working perfectly. 

Can anyone help on this? 

Regards,

Desmond

[Philip D'Ath]

I don't know the answer.

Below is what I use.  I have all the devices that can't do https provisioning fetch an http page.  This then does whatever is needed to configure them to do https secure provisioning using a certificate, and then they continue on using https.

Perhaps you might need to use a two step approach as well.

This is what I typically use on an IOS device doing the DHCP.

ip dhcp pool phone
   ...
  option 66 ascii http://aps.ifm.net.nz

[Dan Lukes · Accepted solution]

You can't use custom password during initial (zero touch) provisioning. DHCP can't be used to deliver key to device this way.

OK. What options you have ?

You my use SPC kind of configuration file, compiled with --target option. It encrypt the file using password derived from particular device MAC. Thus you need no password delivered to device - device can calculate required password from their MAC. It offer just basic level of security - rogue user, like me, know the algorithm used for password generation so he can calculate password and decrypt the file.

You can use HTTPS with mutual certificate authentication to deliver either XML or SPC form of configuration. Every phone have unique client certificate, so you can be sure the request has been issued by well known device. It offer high level of security.

There are some other possibilities also, but you disclosed not so much information about the goal you wish to hit, thus I can't enumerate.

Just note than DHCP will respond to anyone, moreover, the response may be broadcasted (thus delivered to anyone even without request). If you deliver critical data via DHCP, you can consider them publicly available. Resulting security is no security.

[desmond.hui]

Dear Dan,

Thanks for your great reply. 

I make the situation more clear.

We would like to use the https zero touch provisioning to our Broadsoft DMS. 

We want to use DHCP OPTION 66 to send the https URL with credential to Profile Rule to get the configuration file.

Now, i have 2 problems not able to solve. 

1. The DHCP OPTIONS 66 with the credential, in Polycom deployment, we only need to have https://user:password@DMS_IP/dms/def for all the IP Phone, i want to do the same way as this in Cisco SPA.

2. I don't know how to make the https work with the Broadsoft DMS, i already have the 3rd party certificate on the Broadsoft DMS and the Polycom Phone are working good with the DMS on https. 

Regards,

Desmon

[Dan Lukes]

You didn't disclosed the phone model and firmware version.

Just note the option 66 is the standard DHCP option dedicated to IP of TFTP server only. I'm unsure all models have non-standard extension of it allowing you to specify text URL instead of four-byte IP address only.

You should consider to use option 160 instead. It is option dedicated by Cisco for full URL text value.

The DHCP OPTIONS 66 with the credential, in Polycom deployment, we only need to have https://user:password@DMS_IP/dms/def for all the IP Phone, i want to do the same way as this in Cisco SPA.

It's not about encryption. It's just classic HTTP authentication. The same may work with SPA (but I didn't verified it, so try it by self). I'm unsure you can use option 66 for it. May be the option 160 will be mandatory here.

Note anyone can ask DHCP server claiming any identity he wish. So anyone can ask DHCP server for any password, then HTTPS server for particular provisioning file. So there's little or no security against rogue user.

I'm unsure what kind of rogue activity you wish to avoid, but this method provide little or no protection against rogue user. Note it has offered no security even with Polycom.

I don't know how to make the https work with the Broadsoft DMS, i already have the 3rd party certificate on the Broadsoft DMS and the Polycom Phone are working good with the DMS on https.

I'm not familiar with Polycoms, but I assume the third party certificate you mentioned has been issued by certificate authority trusted by virgin Polycom device (running particular firmware version). Configuration provided by untrusted server can't be accepted (it's the matter of security provided by this method).

Cisco SPA phone use the same approach. You must use certificate issued by CA considered trusted by particular model and firmware.

Unfortunately, I have no experience with Broadsoft DMS so I don't know how to reconfigure certificate used. Consider to ask on Broadsoft community or contact Broadsoft's support.