cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

926
Views
5
Helpful
8
Replies
smano
Cisco Employee

Prevent Authentication for Certificate duplication

Hi Folks, 

 

We are working for a customer for ISE POC, standalone node running in 2.3. Basically the use case is if the customer copy the certificate from their machine and install in different machine, the ISE should need to access reject/prevent authentication for the new machine or generate some kind of alert saying the certificate is duplicated or copied? Can we do demo this test case?

 

Any help here. 

1 ACCEPTED SOLUTION

Accepted Solutions
Arne Bier
VIP Advisor

If you are able to successfully export the private key of a user's certificate, then you have a security issue.  Client based certificates should always be made to be non-exportable.

If you have a situation where this is not done then you have shot yourself in the foot, because ISE will not, and cannot tell the difference between client A sending cert X, and client B sending cert X.  Unless of course you're clever enough to include something like a MAC address into the SAN.  But then client B could clone Client A's MAC address ... so that's not fool proof either.  

The point it is:  private key is supposed to reside on one client machine, and one client machine only.  If you prevent this from leaking out then you have a proper solution.

View solution in original post

8 REPLIES 8
Arne Bier
VIP Advisor

If you are able to successfully export the private key of a user's certificate, then you have a security issue.  Client based certificates should always be made to be non-exportable.

If you have a situation where this is not done then you have shot yourself in the foot, because ISE will not, and cannot tell the difference between client A sending cert X, and client B sending cert X.  Unless of course you're clever enough to include something like a MAC address into the SAN.  But then client B could clone Client A's MAC address ... so that's not fool proof either.  

The point it is:  private key is supposed to reside on one client machine, and one client machine only.  If you prevent this from leaking out then you have a proper solution.

View solution in original post

Damien Miller
VIP Advisor

Certificates can be provisioned to endpoints with non exportable private keys and Arne mentioned. So if a user is unable to export the certificates private key, then won't be able to use it on another machine for auth. This is not the perfect scenario however, exploitative tools exist that can bypass this but they do still require admin privileges. This would have to be a weighed risk a customer accepts.

I wouldn't want to manage the cert provisioning that maps physical machine attributes to certificates. It would be a real pain to manage, maybe in the smallest of environments or high touch environments it could be done.


Francesco Molino
VIP Mentor

Hi

It's been already answered and the answer is no unless you're adding kind of specific attributes for the machine to be authenticated as condition/combination with certificate attributes.

But in your scenario, you have a big security breach. If you're having ise to authenticate/ authorize all accesses on the network, this means you're adding some security to avoid unknown people/endpoints to access this network. My point here is, then you don't want to have a breach somewhere otherwise all this setup is useless. Our role is to tell customer that he needs to make the certificate non exportable and his issue will be solved.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Thanks Everyone. Yeah, we have told the customer the same thing, anyhow they wont do this thing in production, but the test case has been written by their red team to see how NAC server prevent such scenarios in case if something similar happened. 

At a technical level, there is nothing that can be done to detect or prevent this.  Doesn't matter what vendor Radius server is used.  The "cloned" cert is an identical copy and is indistinguishable from the "original".  So you would need to invent some clever policy to try and tell them apart (this is why I mentioned baking the MAC address into the Subject CN (not the SAN ... my bad)) - if you had MAC address in Subject CN then the rogue client's MAC address would differ and ISE could catch this by comparing Calling-Station-Id with the cert Subject CN.   But any clever hacker would clone the MAC address anyway.  So it's a futile effort.

There is no 100% reliable way to detect this situation.  In my opinion it's not a valid test case - but I stand to be corrected.

 

 

In Windows the private key cant be exported and the certificate is more secured, but in the case of MAC OS we can simply export the key through keychain access, right?. Basically they are testing this use case for MAC OS. They have considerable number of MAC laptop on their network. 

I don't know whether it's any easier to export the private key in MACOS.  But let's say it is ... then the test is still pointless because you cannot discern between two clients who have the same cert.  No radius server will stand a chance.

 

Sharing the same cert on multiple machines is not a bad idea in all cases though.  In the client case it's bad news because the Authenticating Server (ISE) is being duped. 

But in the Authenticating Server use case it's actually very helpful and used in practice.  If you had 10 ISE nodes then you can re-use the same cert on each server.  

If they want an increased level of security for authenticated users, then they should consider two factor authentication options.
Content for Community-Ad