[VOIPSEC] Security considerations with provisioning

Discussion:

D'Arcy J.M. Cain

2012-10-18 19:22:57 UTC

I am planning to set up a provisioning server. I have scoured the net
but can't find anything that addresses security on this topic very
well. I understand that the device (SPA-122 in my case) is set up with
a profile rule like this:

https://192.168.207.105:8888/phone-$MA

The critical point here is the $MA which is converted to the MAC
address. The server is expected to send back the configuration.

Now the connection is encrypted since it is a https URI but what stops
someone from guessing MAC addresses and stealing configs? I could just
connect to https://192.168.207.105:8888/phone-001122334455 and get the
config for that device. Am I missing some element that makes this
secure?

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:***@Vex.Net

Beck, Stefan

2012-10-18 21:10:46 UTC

Permalink

Hi D'Arcy,

this is usually vendor-specific and depends on the particular device's capabilities.
I don't know the SPA-122, but there should be some PIN or shared-secret
that you can send "out-of-band" (web-portal, e-mail, mail, ...) to your clients.
It is used to either pre-encrypt the config data on your server, or to encrypt/authenticate the
whole connection. Ideally, this may also be used to transfer device certificates in an encrypted way;
those certificates may then be used for all follow up communication between the device and
your provisioning server in mutually authenticated https sessions.

Some principles around that are described in the TR-069 standard
(http://www.broadband-forum.org/technical/download/TR-069.pdf).
And if all your devices support TR-069, you may think of implementing that one.
(Sidenote: I have no practical experience with TR-069 ;-)

At the very least - which does not require any device's contribution - I would
recommend to:
- use your server's awareness of device status: at any time, allow only those profiles being downloaded,
where the device (--> Mac address) had been delivered to a client, and not yet initially provisioned
- define a time limit, when a Mac address is blocked again (even if not yet provisioned)
- this needs an "out-of-band" mechanism for your clients (e.g. web-portal) to re-activate a
Mac address, in case they put their devices on stock.

Stefan

________________________________________
From: Voipsec [voipsec-***@voipsa.org] on behalf of D'Arcy J.M. Cain [***@Vex.Net]
Sent: Thursday, October 18, 2012 21:22
To: ***@voipsa.org
Subject: [VOIPSEC] Security considerations with provisioning

I am planning to set up a provisioning server. I have scoured the net
but can't find anything that addresses security on this topic very
well. I understand that the device (SPA-122 in my case) is set up with
a profile rule like this:

https://192.168.207.105:8888/phone-$MA

The critical point here is the $MA which is converted to the MAC
address. The server is expected to send back the configuration.

Now the connection is encrypted since it is a https URI but what stops
someone from guessing MAC addresses and stealing configs? I could just
connect to https://192.168.207.105:8888/phone-001122334455 and get the
config for that device. Am I missing some element that makes this
secure?

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:***@Vex.Net

D'Arcy J.M. Cain

2012-10-19 13:51:31 UTC

Permalink

On Thu, 18 Oct 2012 21:10:46 +0000

Post by Beck, Stefan
this is usually vendor-specific and depends on the particular
device's capabilities. I don't know the SPA-122, but there should be
some PIN or shared-secret that you can send
"out-of-band" (web-portal, e-mail, mail, ...) to your clients. It is
used to either pre-encrypt the config data on your server, or to
encrypt/authenticate the whole connection. Ideally, this may also be
used to transfer device certificates in an encrypted way; those
certificates may then be used for all follow up communication between
the device and your provisioning server in mutually authenticated
https sessions.

Encryption is easy. As for a secret key, that may work. I can make
individual profile strings like this:
https://voip.vex.net/config/<key>/$MA

If I do that I may not even need the $MA but it adds an extra layer of
security. Of course, I still need to protect the key but...

Post by Beck, Stefan
- use your server's awareness of device status: at any time, allow
only those profiles being downloaded, where the device (--> Mac
address) had been delivered to a client, and not yet initially
provisioned
- define a time limit, when a Mac address is blocked again (even if not yet provisioned)

Together with this advice it may be OK.

Post by Beck, Stefan
- this needs an "out-of-band" mechanism for your clients (e.g.
web-portal) to re-activate a Mac address, in case they put their
devices on stock.

And in this portal I can generate a new key as well.

Thanks for all the good suggestions.

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:***@Vex.Net

Mark R Lindsey

2012-10-18 21:16:06 UTC

Permalink

Yes, these kinds of servers can be subject to dictionary attacks. It's actually interesting that the badguys have been working harder on SIP-based dictionary attacks; I've always thought provisioning servers to be a more fruitful and efficient vector.

But, you can make it harder to steal the config in a few ways:

(a) Use client certificates, so that the server refuses to send the config to anything other than a Cisco/Linksys device

(b) Encrypt the config using a shared secret

(c) If the SPA-122 supports it, use explicit HTTPS authentication

(d) If your network allows it, only allow downloads from specific IP ranges

One big challenge with (b) and (c) of these is keeping the shared secret out of your customer's hands, and off of the Internet.

Post by D'Arcy J.M. Cain
I am planning to set up a provisioning server. I have scoured the net
but can't find anything that addresses security on this topic very
well. I understand that the device (SPA-122 in my case) is set up with
https://192.168.207.105:8888/phone-$MA
The critical point here is the $MA which is converted to the MAC
address. The server is expected to send back the configuration.
Now the connection is encrypted since it is a https URI but what stops
someone from guessing MAC addresses and stealing configs? I could just
connect to https://192.168.207.105:8888/phone-001122334455 and get the
config for that device. Am I missing some element that makes this
secure?
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
_______________________________________________
Voipsec mailing list
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

D'Arcy J.M. Cain

2012-10-19 13:43:25 UTC

Permalink

On Thu, 18 Oct 2012 17:16:06 -0400

Post by Mark R Lindsey
Yes, these kinds of servers can be subject to dictionary attacks.
It's actually interesting that the badguys have been working harder
on SIP-based dictionary attacks; I've always thought provisioning
servers to be a more fruitful and efficient vector.

It certainly seems like the obvious one to me.

Post by Mark R Lindsey
(a) Use client certificates, so that the server refuses to send the
config to anything other than a Cisco/Linksys device
(b) Encrypt the config using a shared secret
(c) If the SPA-122 supports it, use explicit HTTPS authentication

None of these mitigate the attack that I postulated. Let's say that I
am told to put this string in my profile rule:

https://voip.myvoipprovider.com/cisco/SPA/$MA.cfg

What stops me from putting this instead?

https://voip.myvoipprovider.com/cisco/SPA/001122334455.cfg

Where "001122334455" is the MAC address that I read from someone else's
unit or shipping papers.

Post by Mark R Lindsey
(d) If your network allows it, only allow downloads from specific IP ranges

I can't control which networks people download from.

Post by Mark R Lindsey
One big challenge with (b) and (c) of these is keeping the shared
secret out of your customer's hands, and off of the Internet.

In my case, impossible. The big providers simply lock this information
in the ATA (SPA2102-R1 e.g.) but mom and pop shops like me have to
provide vanilla devices that are drop shipped.

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:***@Vex.Net

Thomas Elsgaard

2012-10-18 21:29:18 UTC

Permalink

Hi D'Arcy

As Stefan writes, it's very much depending on your setup, what i am doing
is:

Each enterprise is assigned to an MPLS-VPN, in each MPLS-VPN network i have
an tftp server running with it's own instance (using virtual network
stacks).

So practically each enterprise has it's own hosted TFTP server, only
providing device configuration for the enterprise in it's own MPLS-VPN

This solution was the most flexible (supports Many different device types)
and most secure i could design, so far it scales fine, and has not given me
any problems.

Thomas

Anatoliy Kounitskiy

2012-10-19 08:35:35 UTC

Permalink

Hi,
Add "SSLVerifyClient require" in the configuration of the web server (the option is valid for Apache). The only way to get the configuration file via https is if you succeed to read the certificate file from the Linksys/cisco firmware.

Best Regards,
Anatoliy

Anatoliy Kounitskiy

2012-10-19 15:19:06 UTC

Permalink

Finally i was able to find the official Cisco document:

https://supportforums.cisco.com/docs/DOC-9852

Post by Anatoliy Kounitskiy
Hi,
Add "SSLVerifyClient require" in the configuration of the web server (the option is valid for Apache). The only way to get the configuration file via https is if you succeed to read the certificate file from the Linksys/cisco firmware.
Best Regards,
Anatoliy