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

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

Ralphy006
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

howon
Cisco Employee
Cisco Employee

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.

View solution in original post

4 Replies 4

howon
Cisco Employee
Cisco Employee

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.

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!!

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.

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?