Access System Manager CA as Auth Source

[cgogan13]

Hi, We are looking to implement 802.1x on our 96xx phones using certs/TLS. System Manager (7.1) is our CA. I need to add it as an authentication source in Clearpass. Does anyone have any insights as to what I need to add SMGR as an authentication source? Input screen is looking for the following data:

host name (this one I know )
Connection Security?
port?
Bind DN?
Bind Password?
base DN?

Any ideas out there?

Thanks,

Ciara

 

[jimbojimbo]

System Manager would not be the CA for the phones. The phones would be connected to an open port, perform SCEP on boot (based on info in 46xxsettings.txt file including SCEP server and trusted certificates), then can be connected to a secure port. SCEP server would typically be customer provided such as Microsoft NDES.

I think I did see something from Avaya about supporting SCEP in System Manager for endpoints somewhere in 8.x but don't quote me.

 

[cgogan13]

Hi Jimbo. Our current set-up is that System Manager is our CA for SIP, and all of our Avaya systems. I don't know if it's handing out certs to the individual phones (I don't believe it is). We have the 4 certs the SIP phones need to function on the Utility server so they get them from there, as instructed by the 46xxsettings file. The certs are required for SIP but not for H.323

The network team is trying to implement 802.1x using cert auth, which I believe requires individual certs(?). I'll talk to the systems engineers about our SCEP server and if we can use it for the phones.

In your answer above, you mentioned phones being connected to a open port, then connected to a secure port...is this a physical action that we would need to perform for every phone or would network security take care of allowing the port to be secured once certs have been obtained?

Thanks,

Ciara

 

[kyle555]

Nothing stops you from doing TCP or TLS on either SIP or H323.
Look at H323SIGPROTOCOL
ftp://ftp.avaya.com/incoming/Up1cku9/tsoweb/46xxsettings/07102018/46xxsettings.txt

Now, typically, Avaya with SIP enforces TLS for UC stuff, and lets you get away with TCP for H323, but you could use it there if you wanted. It's just that SIP is the newer stuff and security came into the telephony space around the same time, so we typically associate the two together.

You've also got the ability to strictly download a certificate with the PKCS12 parameter.

## SET PKCS12URL

http://pkc12file_$MACADDR.cer

You could conversely make the phone enroll via SCEP to get a certificate signed by the authority as well:
## SET MYCERTURL

http://certsrvr.trustus.com/mscep/mscep.dll

Here's a fantastic whitepaper that outlines the workflow end to end with a MS CA.

https://downloads.avaya.com/css/P8/documents/100178129

So, here's a few tough questions for you! What are you really trying to accomplish?

You can have the phone SCEP enroll to get a certificate. That can be within the framework of dot1x, or outside of dot1x entirely.
You can dot1x authenticate by any number of methods - like just validating the MAC address. If you trust that noone's spoofing MACs, you can manage a list of MACs of phones you trust to SCEP enroll.
If you do it within dot1x, the phone can't get access to network resources without a cert.
If you do it outside of dot1x, the phone may or may not SCEP enroll, and get on the network, but if you're enforcing mutual TLS on your Session Managers, it'll never register anywhere useful anyway.

Here's your real problem: someone wants to manage every endpoint and is hoping System Manager provides some insight to that. It won't. You probably could, but probably don't want to, have SMGR as a CA for all your endpoints because managing them one at a time would be tedious. It's implementation of the EJBCA isn't exactly suited to that kind of bulk management.

Nothing stops you from using MS as a CA or anything else - even if you have two-way TLS, and even if they're different CAs from SMGR and MS, you can still tell the phones and SMs to trust the MS and SMGR authorities and have the SM offer a SMGR-signed cert to a phone, and have a phone reply with a MS signed cert and have them make happy TLS music together.

The real question is who's going to get, maintain, and keep track of every mac/serial number of a phone you want allowed on your network?
How's a set swap going to work?

 

[cgogan13]

Hi Kyle,

Thanks for the fantastic info.

You hit on the issue/what we're trying to accomplish in your "tough questions" section:

We are currently using MAC addresses to allow Avaya phones on the network. Problem with this is if someone spoofs any Avaya MAC address, they would be able to get on the network so we have been tasked with making 802.1x work (so that spoofing won't work.) Our network NAC agent, Clearpass, recognizes all Avaya MAC addresses, we don't need to administer them on a case-by-case basis, at least we don't need to currently. Are you saying that if we implement identity certs, we would need to manage by MAC address?

Beyond having to implement dot1x, we currently push ca and intermediate certs to the SIP phones for SM/TLS registration. We don't currently push intermediate certs to the phones.

Thanks, Ciara

 

[kyle555]

?
we currently push ca and intermediate certs to the SIP phones for SM/TLS registration. We don't currently push intermediate certs to the phones.

 

[kyle555]

Well, you could use LLDP device type to sort out what is and isn't a phone. I'd have to be pretty hard pressed to spoof an Avaya MAC AND tell LLDP I'm a phone and not a computer.

802.1x, if configured to just permit MACs, would let anyone spoof a MAC and be allowed in. So, if you went to the trouble of maintaining all the MACs of all the phones you have, then your NAC wouldn't blanket allow any Avaya MAC in, just the ones you specifically allowed.

You can do 802.1x with EAP without a certificate with some kind of preshared key, or password, or 'name' like 'your mac address' and have it authenticated by a RADIUS server or whatnot.
Or, you can use EAP-TLS, where the phone's certificate request occurs within the 802.1x exchange (look at the authentication workflow on pg 8 of the whitepaper).

Still, this is what jimbo was saying when the phones need to be on an 'open' port. How are you going to make sure the phones have a settings file before they do this? Most of the settings file is retained by the phone through reboots.

So, you could pre-stage the phones in a secure network segment to get a settings file that will tell them to do 802.1x and with EAP-TLS to SCEP their cert in the exchange. Then you could put the phones at desks and they should remember how to do the cert request via SCEP with something like username=$MYMAC and pw=$MYMAC.

At that point, I could have my laptop, spoof an Avaya phone MAC address, but unless I knew what was in the settings file for MYCERTURL, I wouldn't know the key points of being able to do that cert enrollment in the dot1x exchange.

You still have a chicken and egg situation - how do you provide the trusted information to the phones to know to get on the network while restricting that information from a theoretical bad guy who could conceivably pretend to be a phone?
Maybe part of your provisioning looks like this:
-new phone plugs in at desk
-user requests onboarding
-LAN guy disables .1x, puts port in phone provisioning VLAN
-Phone gets DHCP/46xxsettings.txt that tells it how to EAP-TLS/cert enroll
-LAN guy enables .1x on the port
-Phone does it's magic dance and enrolls

The short answer is you're either accounting for everything ahead of time, or your process to manage devices one at a time is going to be long and painful to do moves and changes. I'd suggest testing it out and figure out from your ops managers what the required time would be for each step to ballpark what impact that would have on your operational costs to do day to day administration.

Here's another way to accomplish what you want: keep track of all your Avaya MAC addresses. Have them SCEP to get a cert. Make SM enforce phones providing identity certs.
It sounds like you don't care if a tech shows up with a new Avaya phone for a swap or an add order. You care if I'm pretending to be an Avaya phone.


Cisco says:

https://www.cisco.com/c/en/us/suppo...ructure-pki/116167-technote-scep-00.html#anc9

Renewal
As the expiration date of an ID certificate approaches, a SCEP client might want to obtain a new certificate. The client generates a CSR and goes through the Enrollment process (as defined previously). [highlight #FCE94F]The current certificate is used in order to sign the SignedData PKCS#7, which in turn proves identity to the CA[/highlight]. Upon reciept of the new certificate, the client immediately deletes the current certificate and replaces it with the new one, whose validity starts immediately.

Wouldn't that be good enough to know that nobody swept in and stole the identity of MAC address Avaya:12:34:56?

That, with a little IDS action and locking down VLANs and ports would make it so that your hypothetical attacker would get the same network access whether you use dot1x or not, and you'd know pretty quick with intrusion detection that "a phone is trying something funny here" and you'd get your turbo security, and you wouldn't need to bend over backwards to swap phones/turn up new ones/etc.

 

[cgogan13]

Kyle, wow! Thanks again for all the detail, much appreciated.

Question regarding your statement below:

 

[cgogan13]

If I make SM enforce phones providing identity certs, can my network still do it's NAC process (which right now is validating the MAC address is Avaya), and have the cert validation be one on the SM side?

Here's another way to accomplish what you want: keep track of all your Avaya MAC addresses. Have them SCEP to get a cert. Make SM enforce phones providing identity certs.
It sounds like you don't care if a tech shows up with a new Avaya phone for a swap or an add order. You care if I'm pretending to be an Avaya phone.


Cisco says:

https://www.cisco.com/c/en/us/support/docs/securit...

CODE -->
Renewal
As the expiration date of an ID certificate approaches, a SCEP client might want to obtain a new certificate. The client generates a CSR and goes through the Enrollment process (as defined previously). The current certificate is used in order to sign the SignedData PKCS#7, which in turn proves identity to the CA. Upon reciept of the new certificate, the client immediately deletes the current certificate and replaces it with the new one, whose validity starts immediately.

Wouldn't that be good enough to know that nobody swept in and stole the identity of MAC address Avaya:12:34:56?

That, with a little IDS action and locking down VLANs and ports would make it so that your hypothetical attacker would get the same network access whether you use dot1x or not, and you'd know pretty quick with intrusion detection that "a phone is trying something funny here" and you'd get your turbo security, and you wouldn't need to bend over backwards to swap phones/turn up new ones/etc.

 

[kyle555]

If I make SM enforce phones providing identity certs, can my network still do it's NAC process (which right now is validating the MAC address is Avaya), and have the cert validation be one on the SM side?"
Yes.
Now, if you decide to let phones go wherever they want on your network, and I can pretend to be a phone, then sure, maybe I could telnet to a printer and put nasty messages on the LCD screen, but your network security policies should be set up in such a way that phones can only talk to things they need to - so, even if I weren't a phone, but in the voice VLAN, I'm not getting any broader network access.


Your security guys might prefer to do the certificate enrollment and exchange within dot1x to decide whether to let devices on the network. And that's nice. Now, it makes a ton of sense on PCs that you stage one at a time with smart cards that allow access to a human's identity certificate. That's totally cool to use dot1x EAPTLS with - it's easy enough - the provisioning happened ahead of time.

With phones that have a far more finite use case in terms of network access and utilization, ACLs, firewalls and stuff to make sure it can only talk to one place is a good start. You're not getting UC on Avaya anything with SIP if you're not TLS. You can be TLS from phone-->SM and from SM-->Presence but TCP from SM-->CM - you'll never get presence working. Avaya requires TLS at just about every layer in their architecture for anything UC. That said, the ability to do mutual TLS and require an identity cert on the endpoint is an option you can enforce.

Watch out for the Polycoms though

My (hypothetical) argument is that if you're going to do it one way or another in dot1x to get network access, or after network access is granted because your SMs require it, then what's the difference? If the SCEP renewal can be tested to be truly secure - as in, per the Cisco doc, the renewal must include proof of the identity certificate from the previous SCEP process, then one way or another, I can't just unplug your phone with your MAC and plug in my PC faking to be your Avaya phone with the same MAC and pickup where that phone left off. And even if I could, I'd still need it's user name and password. And even if I could, I'd need to seriously reverse engineer Avaya's softphone to make it pretend to be a 9600 set.

Either you let phones SCEP from any Avaya MAC, or from specifically MACs you own.
Either you have them SCEP in dot1x negotiation or after they have network access.

The phones still need the SCEP URL and password. The phones still need a settings file to be able to SCEP for dot1x to get network access or to SCEP to get SM access. You gotta figure out whether you'll let your phones get that settings file before and/or after they get plugged in to the switch port they're going to use.

How paranoid do you want to get? I'm sure you just have a project to implement this NAC thing. But if we really wanted to put on a tinfoil hat, you could set up SNMP on the Avaya phones and have that as a validation layer to ensure they're always responding as Avaya phones should. Providing their serial numbers and interface uptimes and extensions they might be logged in with.

Hell, if you really want to make this simple, just SNMP poll the phones and anything that doesn't answer like an Avaya phone should gets blacklisted. You know what somebody would have to do to fake being an Avaya phone by MAC address AND be able to feasibly lie about SNMP polls destined for Avaya phones? It'd take a lot. And considering their firmware is signed by Avaya, with, you guessed it, a CERTIFICATE, you can probably just SNMP poll your way into making sure everything with MAC=AVAYA:xx:yy:zz is really an Avaya phone

 

[cgogan13]

Ok, I've got an identity cert on the test phone now. My dot1x process is prompting me for a Device ID & Password. Device ID is the MAC address. I can't find where to set the password. I found this article, which describes what I'm experiencing but gives no clues as to how to set the password...what am I missing?

https://downloads.avaya.com/elmodocs2/one-X_Deskphone_Edition/R1.5/output/16_300698_4/admn0710.html

802.1X Supplicant Operation
9600 IP Telephones that support Supplicant operation also support Extensible Authentication Protocol (EAP), but only with the MD5-Challenge authentication method as specified in IETF RFC 3748 [8.5-33a].

A Supplicant identity (ID) and password of no more than 12 numeric characters are stored in reprogrammable non-volatile memory. The ID and password are not overwritten by telephone software downloads. [highlight #FCE94F]The default ID is the MAC address of the telephone, converted to ASCII format without colon separators, and the default password is null[/highlight]. Both the ID and password are set to defaults at manufacture. EAP-Response/Identity frames use the ID in the Type-Data field. EAP-Response/MD5-Challenge frames use the password to compute the digest for the Value field, leaving the Name field blank.

When a telephone is installed for the first time and 802.1x is in effect, the dynamic address process prompts the installer to enter the Supplicant identity and password. [highlight #FCE94F]The IP telephone does not accept null value passwords[/highlight]. See “Dynamic Addressing Process” in the Avaya one-X Deskphone Edition for 9600 Series IP Telephones Installation and Maintenance Guide. The IP telephone stores 802.1X credentials when successful authentication is achieved. Post-installation authentication attempts occur using the stored 802.1X credentials, without prompting the user for ID and password entry.

An IP telephone can support several different 802.1X authentication scenarios, depending on the capabilities of the Ethernet data switch to which it is connected. Some switches may authenticate only a single device per switch port. This is known as single-supplicant or port-based operation. These switches typically send multicast 802.1X packets to authenticating devices.

These switches support the following three scenarios:

Standalone telephone (Telephone Only Authenticates) - When the IP telephone is configured for Supplicant Mode (DOT1X=2), the telephone can support authentication from the switch.
Telephone with attached PC (Telephone Only Authenticates) - When the IP telephone is configured for Supplicant Mode (DOT1X=2), the telephone can support authentication from the switch. The attached PC in this scenario gains access to the network without being authenticated.
Telephone with attached PC (PC Only Authenticates) - When the IP telephone is configured for Pass-Through Mode or Pass-Through Mode with Logoff (DOT1X=0 or 1), an attached PC running 802.1X supplicant software can be authenticated by the data switch. The telephone in this scenario gains access to the network without being authenticated.
Some switches support authentication of multiple devices connected through a single switch port. This is known as multi-supplicant or MAC-based operation. These switches typically send unicast 802.1X packets to authenticating devices. These switches support the following two scenarios:

Standalone telephone (Telephone Only Authenticates) - When the IP telephone is configured for Supplicant Mode (DOT1X=2), the telephone can support authentication from the switch. When DOT1X is "0" or "1" the telephone is unable to authenticate with the switch.
Telephone and PC Dual Authentication - Both the IP telephone and the connected PC can support 802.1X authentication from the switch. The IP telephone may be configured for Pass-Through Mode or Pass-Through Mode with Logoff (DOT1X=0 or 1). The attached PC must be running 802.1X supplicant software.

 

[kyle555]

Use the doc I referenced above. The one you're using is really old.

In EAP-TLS authentication method, the phone is authenticated with its obtained
certificate based on its serial number or MAC address. So the user will not be
prompted for 802.1X user/password (as in MD5).

 

[cgogan13]

Thanks Kyle. The cert we are trying to use is a single identity cert, so it doesn't contain the serial # or MAC. Is there a way to set the 802.1x password that the supplicant is looking for? It looks from the doc that you sent, we would have to enter the MAC for every phone into AD if we were to use s unique cert for every phone, so we would rather use a single identity cert.

 

[kyle555]

I strongly doubt it. If you want to use MAC as username/pass, then great. You've used that as the element that validates identity. You can't use the same PKCS12 for every phone because it would no longer confirm the identity of anything!

Look closely through the steps on the MS end of things - it refers to Microsoft: Smart Card or Other Certificate. And creating each MAC address as a user - see page 75. I think that's Literally implying that each cert for each user must be unique. It kind of defeats the purpose to have 1000 phones up using the same cert to authenticate to dot1x.

Now, what you could do is do your dot1x authentication via MAC as username and password. You could blindly accept any MAC with the first 3 octets Avaya. You can then use the same PKCS12 on every phone to communicate with Session Manager. SM can enforce 2 way TLS, but it just uses the identity certificate to do a TLS handshake. After the handshake, the phone still has to provide a username and password. There's no way to get a phone online with an extension with just a certificate.

So, if you're going to authenticate devices based on MAC, and going to stage them offline to provide them the cert required - whether it's 1 cert for all or 1 cert each - then just do your dot1x validating MACs of phones you've manually on-boarded yourself.

I suppose it could be possible to use the same cert on each phone, but if you're doing it in line with the reference doc with Windows infrastructure, you'd have to figure out how to let the same account/identity log in an unlimited amount of times. At that point, dot1x isn't validating anything beyond having the 1 cert - you've still provisioned them yourself offline.