Mutual Auth TLS 2

[JSurfer]

Greetings,

Just reading up on Mutual Auth TLS for Remote Workers via an SBC and wanted to see if anyone has a link to a good application note or document they recommend that shows how to implement with SMgr/SBC. I already have TLS implemented with reverse proxies, but would like to take the extra step and lock it down more.

It seems like SCEP is the suggested method if dealing with a lot of users. But it seems with that method you provide all the end users a password to get their certificate? Would this be the same password or unique for each user? Can SMgr generate certificates for individual users for the PKCS12URL method? I know that may be more tedious for many users, but does that allow more control than SCEP (if its not a unique password per user)?

 

[kyle555]

Providing an identity certificate is one thing.

Enrolling via SCEP or whatever other mechanism to actually get an identity certificate is something else.

Once upon a time, my laptop had an identity cert from the company CA issued to "people". Literally. One cert for everyone who's a "person".

Nowadays the cert is issued to my distinguished name - CN=kyle555,CN=Users,DC=tek-tips,DC=com and we have some protection software that we enter a PIN into that lets the cert be used for things.

So, for kicks, I exported my company's root CA certificate from the "Trusted Root CAs" in my PC and added it to a Server Profile on the SBC and required peer verification and trusted my company's CA.

I told One-X Communicator to use my identity cert and it popped the app that wanted my PIN to access my cert and it worked fine.

SCEP's good for hardware endpoints, even though to use SMGR's CA you'll need an entity created for every phone with their serial number or mac address. But for end users on PCs or mobiles, it's not like there's a SCEP client built in to Avaya's softclients to enroll. And that kind of makes sense in the context that an application, like voice and UC, should interop with best security practices but it's not there to be a managed PKI infrastructure for you.

All said and told, you could add a root CA cert to your SBC for mutual TLS and as long as the clients have a cert chained up to that CA, you can do mutual TLS.

If you're only dealing with Windows clients, then a group policy pushing an identity cert into the personal store is enough. If you've got mobile devices to manage, then some MDM like a Mobile Iron or IBM MaaS360 would let you install an identity cert on each mobile device and probably manage the enrollment to a CA they manage on your behalf - kinda like System Manager's CA but on steroids. Again, the difference being that Avaya's a phone system that happens to implement tight security with a minimal provisioning layer while the MDM solutions provide nothing but a best-in-class security provisioning layer around mobile devices.

Short story long, do your endpoint certs somewhere else. Install the identity certs on the endpoints and tell the SBC to trust the CA. Even without 2 way TLS, you've still got all sorts of things on the SBC like URI Groups in Subscriber Flows to reject anything that isn't exactly 7 digits@yourdomain.com and from User-Agent: Avaya One-X*. Further, DOS protections to reject >X registrations/min from a particular IP will weed out the garbage traffic from the public internet.

My role managing these SBCs doesn't permit me the luxury of dictating a client cert on all endpoints. As more and more solutions go cloud, a client certificate isn't acceptable as a requirement. I agree that it's the best way to shut down anyone you don't trust, but you're also opening up your service to an untrusted network. You should still have all the protections in place for DOS attacks and allowing only certain user-agents and URI schemes to pass through the SBC just in case I ever get a job at your company and get an identity certificate .

 

[JSurfer]

Thanks for the info Kyle555! I do have Subscriber flows restricted by User Agent. I will have to look at configuring the URI Groups, that is a good idea.

For the DOS protections, are you referring to the Domain Dos profile or under Dos/DDoS? It didn't look like much could be configured under Dos/DDos to restrict registration attempts. I see under "call walking" you can edit "Destinations" per minute. Is this what you are refering to about configuring that or somewhere else?

We are on 8.0 for SBC btw if that matters.

 

[jimbojimbo]

I've seen some notes about SMGR 8.1.3 providing SCEP but not sure if it is in concrete yet. For Equinox Clients it is relatively straight forward if using Microsoft AD and CA. You can setup all users for auto-enrollment which gets them a user cert. You do however need to make it exportable. Alternatively you can provide users a certificate manually or via the AADS/HTTP server (use this method for hardphones). You should NEVER use the same password. If the password gets out into the wild you would have to revoke every user certificate.

Mutual TLS is great however keep in mind you will need to "stage" the hard phones first since they will need trusted certificates initially loaded onto the device.

 

[kyle555]

reOS, when you setup a server profile, the last tab has a box to tick for DOS protection. It opens up another tab that lets you pick how many users to support and it then it makes up some numbers in the background about how many registers or invites or whatever it'll allow within a time period based on the number of remote users and or trunks you put.

 

[JSurfer]

JimboJimbo: Thanks for the info! After researching this, I will go with a third party SCEP server for mass deploy and I will use the staging process. For testing I am trying to use the "PKCS12 SETTINGS" section and the "SET PKCS12URL" parameter, but the phone (SIP 7.1.9) is not even reaching out with the setting I have entered. Is there some other parameter required to make it use that one? I have tried the following for testing.

SET PKCS12URL

http://xxx.xxx.xxx.xxx/mypkcscertificatename_$MACADDR.p12

and also tried
SET PKCS12URL

http://xxx.xxx.xxx.xxx:80/mypkcscertificatename_$MACADDR.p12

SET TRUSTCERTS

http://xxx.xxx.xxx.xxx/MyCACertificate.pem

parameter is working fine. It grabs that certificate without issue. I have wireshark on the http server and never see a Get request for the pkcs certificate. Just the following

Requested GET /96x1Supgrade.txt
Requested GET /46xxsettings.txt
Requested GET /MyCACertificate.pem
Requested GET /S96x1_SALBR7_1_9_0r8_V4r83.tar

Cleared the phone and verified the parameter has ## removed. Thinking I might try a different firmware.


Kyle5555: Ah ok, I see where you are talking about now. Thanks! Ever seen the issue above with pkcs parameter?

 

[kyle555]

I've never tried, but I'd follow the settings file.

If you've got a pkc12file_0024D7E42E98.cer on your HTTP server to satisfy the example below and can download it yourself from a browser, then I'd suspect the phone. If the parameter was expected, I'd at least expect to see a 404 in your http server log if the file didn't exist.

###################### PKCS12 SETTINGS #####################
##
## PKCS12URL specifies the URL to be used to download a PKCS #12 file
## containing an identity certificate and its private key.
## 0 to 255 ASCII characters, zero or one URL. The value can be a string that contains either
## "$SERIALNO" (which will be replaced by the telephone's serial number) or "$MACADDR"
## (which will be replaced by the telephone's MAC address), but it may contain other characters as well.
## If $MACADDR is added to the URL then the PKCS12 filename on the file server shall include MAC address
## without colons (i.e., 6 pairs of ASCII hexadecimal characters AABBCCDDEEFF with hex characters A-F
## encoded as upper-case characters). For example, if Ethernet MAC address of a specific phone
## is: 00-24-D7-E4-2E-98 and the PKCS12URL is: pkc12file_$MACADDR.cer, then the filename of the
## PKCS12 file for this phone on the file server shall be: pkc12file_0024D7E42E98.cer.
## PKCS12 file download is preferred over SCEP if PKCS12URL is defined.

 

[JSurfer]

Turned out to be a firmware issue on the phone. Even though the phone was getting the 7.1.9 tar file as shown above it never updated from 7.0.4. I noticed this right before I decided to try a different 7.1 firmware. When I switched to 7.1.8, the application actually updated this time and then recognized the PKCS12 URL parameter (requires 7.1 and above).

Now getting certificate rejected after it prompts for the PKCS12 Cert password on the phone and I manually type it in (even though I supplied the password in the 46xxsettings also). I verified the password for the PKCS12 certificate is correct by installing it on a Windows machine. I even copied and pasted the password that allowed me to install it on the windows machine to the 46xxsettings file. But same result, so now troubleshooting that when I have time.

 

[kyle555]

Where did you get the cert?

 

[JSurfer]

I generated it on SMGR (EJBCA) for testing.

Same PKCS12 cert works fine with AAfD and One-X communicator.

Just getting "identity certificate rejected" on hard phone with password in 46xxsettings and also after manually entering password at prompt.

 

[JSurfer]

Helps when you set the date/time. Was staring me in the face. I had not configured the date/time source yet, so of course the cert was going to be invalid. Setting the date/time to something current solved the issue for that problem.