PC behind IP phone EAP-TLS

[munish.dhiman1]

Dear All, 

Could you please let me know. What is the recommended combination of implementation authentication when PCs connected IP Phones? What is the logic behind using one as compare to the other? or drawbacks using one.  As per my recommendation 4th option seems less complex and easy to maintain, however customer is requesting option 3rd or Cisco best practice recommendation.

1.IP-Phone (EAP-TLS) & PC (EAP-TLS)

2. IP-Phone (MAB) & PC (EAP-TLS)

3. IP-Phone (EAP-TLS) & PC (MSCHAPV2)

4. IP-Phone (MAB) & PC (MSCHAPV2)

Regards,

MD

[Mike.Cifelli]

I think the IP-Phone decision will be determined whether or not your phones support eap-tls. MAB is very simple and easy to manage and there are ways to lock this down quite a bit. But MAB is still less secure than running eap-tls. Something to consider is that eap-tls is/should always be desired IMO. PEAP(mschapv2) uses passwords and is in theory considered as a legacy combo. However, running any combo that includes eap-tls is going to require an internal pki and management of certificates. Other items I think you need to consider that may better assist with determining what sec protocols you are going to use is what supplicant you intend on using. In my experience if you are looking for only comp auth via cert, using the native supplicant is straightforward and can be managed/configured via GPOs.
Regardless of what combo you use you will want to run with auth host-mode multi-domain which allows one data host and one voice host on the dot1x authz port. I am curious to hear what others have to say about this. If doable my choice would be option 1. HTH!

[Colby LeMaire]

I would agree with @Mike.Cifelli that EAP-TLS is the preferred and most-secure option.  But the choice is dependent on a number of factors such as having an internal PKI system and a centralized way to manage the supplicant configurations and certificate issuance.  For Windows environments, the easiest way is to use a Microsoft CA server and use GPOs to push supplicant configurations and issue certificates.  For Cisco IP phones, you can use CUCM to push the supplicant configurations and certificates.  That would require CUCM to have an intermediate CA certificate installed so CUCM can issue certificates itself.

[Colby LeMaire · Accepted solution]

The other thing I forgot to say is that you don't have to do it all at once.  It is common for customers to start doing 802.1x with their Windows clients first since that is the easiest to do.  The phones can be authenticated with MAB initially and then rollout certificates and 802.1x to the phones over time.  This phased approach is important because the solution has to be supportable.  802.1x and ISE are very complex and you really don't want all end-client issues being escalated to Tier 2/3.  You want to rollout the solution slowly and provide training to the Service Desk/Tier 1 folks so they can handle the majority of the low-level issues.  As they get comfortable, move to the next phase.

[Nadav]

Pretty much every Cisco deskphone from the past decade will support EAP-TLS. Likewise any PC (Windows 7+) will support EAP-TLS. Certificates are a more robust form of 802.1x authentication and easier to manage securely in a large enterprise. 

If possible, go for EAP-TLS.

FYI:

For Windows PC's you can perform either client authentication or mutual authentication.

For Cisco IP phones using EAP-TLS the authentication is that of the client only (if someone has seen differently for ISE as the Authentication Server, I'd be happy to hear it). The CUCMs and TFTPs are authenticated via a different vector if you're in a mixed mode cluster by signing the CTL. The CTL allows the phone to authenticate various servers within the cluster.