TACACS+ vs RADIUS

[edw]

Hi,

I know this has been asked several times but I think I will ask myself. We have ACS at present and need to move to a upgraded version due to systems refreshes and thus incompatability with our newer OS's. This means that we will be going to ISE 2.0 which includes TACACS+ as an extra addon. However I'm being told that I don't need TACACS+ as we can use Radius for device administration.

My question is how safe this is due to the fact that RADIUS does not encrypt the whole packet only the password and therefore does the commands which the user enter get transmitted back to ISE for auditing purposes if so surely we would want that packet to be encrypted, of course there are other considerations. The network is relatively small with two core switches and then 15 switch closets and wireless APs around site, VPN users and device admin and we will deploy network device authentication too with the new ISE platform. We are a building which has floors open to the public.

Any points greatfully received.

Thanks

Ed

[Javier Henderson · Accepted solution]

With RADIUS, you will not have command accounting and authorization, meaning you won't have an audit trail of who entered what commands on what device and when, and you can't control which commands are executed by each user (they will be able to execute whatever commands are available for their current privilege level).

For those reasons, TACACS+ is usually preferred for device administration.

Javier Henderson

Cisco Systems

[edw]

Hi,

Thanks for the replies. Javier, this is what I thought. Nadav these are good points but I think the cost and complexitiy of the IPSEC soultion would mitigate the cost of running ISE. Especially when we have educational charity pricing.

My only concern is that apprently ISE needs 500GB of drive space which is a LOT for what we have I think.

Ed

[Nadav · Accepted solution]

IPSEC is to protect traffic including RADIUS, whether you pick ISE or not your security concerns remain.

With ISE your RADIUS server will run on ISE, yet the authentication and response packets are still cleartext. This is the same for any RADIUS solution that isn't protected. 

My views on ISE have to do with the specific feature set you're looking for in a device administration AAA solution. Whether you pick ISE or not, RADIUS does not have encryption built in (except for password in access-request), unlike TACACS.

[edw]

Yes, that is what I originally thought.

So I think ISE with TACACS+ is the right solution.

Thanks

Ed

[Nadav]

Hi Ed,

1) If the only reason you're upgrading to ISE is to support TACACS+, then you may want to look around to find a solution tailored for TACACS+. There are dozens of applications which can do the trick.

If you are thinking of upgrading to ISE 2.x, and decide that RADIUS is enough because TACACS+ isn't necessary, then I suggest you once again look at other solutions.

ISE is primarily a policy management platform for Trustsec and not a device administration authentication server. It's great software, but make sure it's what you're looking for. For the purposes you've described, the upgrade from ACS 4.1/4.2 would be ACS 5.x and not ISE 2.x. 

You should take a look at the bottom line of each solution (ACS 5.x with Base license vs ISE 2.x with XXXXX user support license and device administration license).

If you do prefer the ISE route, keep in mind that migrating from ACS requires upgrading to ACS 5.5 and above first. Take a look at:

http://www.cisco.com/c/en/us/td/docs/security/ise/2-0/migration_guide/b_ise_MigrationGuide20.pdf

2) Accounting exists in both TACACS+ and RADIUS. If you're bothered by the commands being sent to the RADIUS server for accounting, then perhaps you should look into not configuring accounting for RADIUS in your equipment. There are solutions such as RADSEC but they aren't usually found in the Cisco ecosystem. But to be honest you can likely encrypt traffic between your network devices and authentication servers via IPSEC, assuming you have the right equipment. Keep in mind that IPSEC isn't all or nothing, you can select which traffic gets encrypted via a crypto ACL. 

[Peter Koltl]

Nowadays command authorization can be performed by 'parser view' in IOS so most companies can get on well with RADIUS. The parser view can be controlled with a RADIUS attribute.

[Nadav]

The thing about cli-view-name is that it requires you to configure the command set locally on each device rather than centrally on the server. This makes it less scalable, and less secure since anyone with local access to the switch can see your device administration security policies for named groups.

As far as I can tell, it doesn't give much added value (other than if you want to make authorization hierarchical using superviews) to the previous solution of setting privileged levels locally from 2-14 with predefined allowed commands per privilege level.