cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
423
Views
10
Helpful
4
Replies
Beginner

Using ISE Profile (Cisco Phone) - 802.1x - Initial bootup

Hi all,

I'm using ISE with a 3850 switch running 802.1x. Our 802.1x setup requires the phone to have a CAPF certificate and authenticates via EAP-TLS. There's a chicken/egg scenario with a new phone setup. I know we could plug the phone into a lab port without 802.1x, but we deploy a lot of phones so we want it as scalable as possible.

 

The Policy set would look like this:

  • AuthC
    • EAP-TLS with CAPF name, pass
    • MAB
  • AuthZ
    • EAP-TLS against CAPF: pass = permit with voice domain
    • If IdentityGroup = Profiled:Cisco-IP-Phone: put a remediation DACL to only allow necessary traffic to CUCM to register and pull a cert
    • CATCH-ALL: put a GUEST DACL that only allows internet access (block's RFC1918)

So the thought is, it would look like this:

  1. dot1x fail
  2. MAB
  3. AuthZ - If profiled as a Cisco IP phone, put a remediation DACL to only allow necessary traffic to CUCM to register and pull a cert
  4. Phone registers and pulls a cert and reboots
  5. Upon reboot, it has a cert and auth's via dot1x EAP-TLS

However, it seems to work like this:

  1. dot1x fail
  2. MAB
  3. Phone isn't profiled as a Cisco phone in time, so it gets the GUEST DACL
  4. Reauth's and by now it's profiled as a Cisco IP phone, put a remediation DACL to only allow necessary traffic to CUCM to register and pull a cert
  5. Phone registers and pulls a cert and reboots
  6. Upon reboot, it has a cert and auth's via dot1x EAP-TLS

Is this normal? Is there a way for Cisco to profile faster so it immediately sees it as a Cisco Phone?

 

We have Device sensor on.

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: Using ISE Profile (Cisco Phone) - 802.1x - Initial bootup

What you have described is how profiling works. Another option is not to use profiling for initial phase. Instead use EAP-TLS with MIC (Manufacturer Installed Certificate) that is already present on the phone as initial authentication.

  1. dot1x success and gets DACL to only allow necessary traffic to CUCM to register and pull a cert
  2. Phone registers and pulls a cert and reboots
  3. Upon reboot, it has a cert and auth's via dot1x EAP-TLS

You simply need to trust Cisco Certificate for EAP purpose and create appropriate policy to permit MIC authenticated phones to the network.

4 REPLIES 4
Highlighted
Cisco Employee

Re: Using ISE Profile (Cisco Phone) - 802.1x - Initial bootup

What you have described is how profiling works. Another option is not to use profiling for initial phase. Instead use EAP-TLS with MIC (Manufacturer Installed Certificate) that is already present on the phone as initial authentication.

  1. dot1x success and gets DACL to only allow necessary traffic to CUCM to register and pull a cert
  2. Phone registers and pulls a cert and reboots
  3. Upon reboot, it has a cert and auth's via dot1x EAP-TLS

You simply need to trust Cisco Certificate for EAP purpose and create appropriate policy to permit MIC authenticated phones to the network.

Beginner

Re: Using ISE Profile (Cisco Phone) - 802.1x - Initial bootup

So its normal for the device get to authorized as an unknown device first by ise (ie catchall). And then ise finishes profiling.... does ise then decide to put the device through the AuthZ policy again on it’s own after profiling happens and send a CoA based on the result?

 

or does the switch need to ask for a reauth?

 

thanks!!

Cisco Employee

Re: Using ISE Profile (Cisco Phone) - 802.1x - Initial bootup

It depends on the global CoA setting under Administration > System > Settings > Profiling. If set to Reauth or Port Bounce the endpoint will be moved to Phone ACL upon moving from unknown device to a known profile.

Beginner

Re: Using ISE Profile (Cisco Phone) - 802.1x - Initial bootup

My CoA Type is currently set to "No CoA". Yet, it still seems to update it's authorization. Maybe it's the switch sending re-auth's. If the switch sends re-auth requests, I'm assuming it would get authorized based on the updated profile if it changed?