Does Cisco support strong remote network authentication protocols?

[Nadav]

Hi everyone,

To the best of my knowledge IOS and IOS-XE support nothing better than PAP for the remote authentication of users to network devices. Is there a stronger solution than PAP, perhaps CHAP or P/EAP-based? Considering the fact that OpenSSL is already installed in these devices, I'm surprised that EAP-TTLS hasn't been adopted as a secure alternative.

Any insights?

[Peter Paluch]

Hello,

When saying "remote authentication of users to network devices", what exactly do you have in mind? If talking about Telnet and/or SSH to access the CLI of the device, they have their own authentication mechanisms, with the possibility of moving the database of users to a remote server that is queried either by TACACS+ or RADIUS. If talking about PPP, then PAP, CHAP, MS-CHAP, MS-CHAPv2, and EAP-based methods have been supported for many years. And if talking about either 802.1X on wired Ethernet, or about enterprise-level authentication in wireless 802.11 networks, the authentication method is entirely up to the wired/wireless client and the RADIUS/TACACS+ server, and can be anything, ranging from basic PAP through PEAP up to LEAP, EAP-TLS, EAP-TTLS and others.

So I am not entirely certain if I understand your question. Can you perhaps give us a specific example of the service that is using PAP only?

Best regards,
Peter

[Nadav]

Hi Peter,

I'm referring to CLI access. CLI access is broken down into two parts: client to NAS, and NAS to authentication server. 

First of all, telnetting/SSHing into the NAS from a client isn't very secure. If you're using telnet then all your credentials are in cleartext (among other compromises), and using SSH means your credentials are encrypted but there is no mutual authentication between client and NAS.  Either way the NAS doesn't know if the client is legit, and the client doesn't know if the NAS is legit.

As for NAS to authentication server, via radius and tacacs+ this is performed by PAP.  Even though the users may be stored in some secure database whether a directory or internally on the authentication server, the authentication method itself is considered extremely insecure by today's standards. For example, username is delivered in plaintext and it is known to be subject to password guessing and snooping.

I'm interested in whether or not it's possible to use stronger authentication such as certificates or an authentication challenge (such as CHAP) to log in to Cisco IOS and IOS-XE devices. 

[Masoud Pourshabanian]

Hello,

There are two cases involved.

1- Clients send username and password to NAS through SSH or telnet.

2 -NAS sends username and password to a Tacacs or radius server by PAP or chap or ... for authentication.

Protocols like PAP and Chap are involved in the second case between NAS and Tacacs or radius server. If you are trying to make client and NAS connection more secure, you need to find a way to secure the first case. There are two ways coming to my mind if your NAS does not support CA.

1- Using SSH tunnel based on certificate. SSH server is a proxy between clients and NAS. Client and SSH server authenticate each other, then a tunnel will be established between client and your NAS. As far as I know, it can be done by OpenSSH .

2 - This one is easier. Establishing VPN between Client and  server. Server can be a Cisco ASA, router or linux. Then directing telnet or SSH through this tunnel.

[Peter Paluch]

Hod, Masoud,

Masoud has made a very nice analysis of the situation involved. One issue is accessing the managed device securely (obviously, you would not use Telnet for that), the other issue is how this managed device accesses an AAA server to verify your credentials.

Frankly, I was not able to find much about this. I digged out information about the possibility of using X.509 PKI certificates to authenticate SSH users when logging in:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_ssh/configuration/15-mt/sec-usr-ssh-15-mt-book/sec-secure-shell-auth-digi-certificate.html

Also, there is an option of using Kerberos to authenticate users, coupled with "kerberized" Telnet:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_cfg/configuration/15-mt/sec-usr-cfg-15-mt-book/sec-cfg-kerberos.html

Perhaps this Kerberos-based authentication could also be extended to SSH but I have currently no way of testing that.

Apart from these, however, I am not aware of any other options that would provide more secure authentication mechanisms to the remote CLI protocols (Telnet/SSH). I believe this is partly due to the fact that the SSH clients (let's not discuss Telnet anymore) do not commonly implement alternative authentication mechanisms even there seems to be a support for that in SSH.

Best regards,
Peter

[Nadav]

Thank you both for your well thought answers,

The X.509 solution with OCSP (optional) is interesting. As for device to AAA server, Masoud mentioned that there may be a method to secure the communication if the network device supports CA (I take it that means PKI in general). The question remains whether or not such support for PKI or any other secure framework exists within IOS. 

Something like TrustSec comes to mind where the AAA server authenticates the network device with EAP-FAST. 

[Peter Paluch · Accepted solution]

Hi Hod,

As far as I am concerned, I do not know of any readily available technique to protect RADIUS sessions between the authenticator and the RADIUS server. The need for that is perhaps downplayed by the fact that most common applications of RADIUS (namely, PPP, 802.1X and wireless authentication) establish a supplicant-to-RADIUS protected channel and use EAP to carry whatever authentication the supplicant and RADIUS support, with the authenticator being relegated to a very minor role of repackaging EAP messages into RADIUS A-V pairs and vice versa. As this entire chain carrying user credentials can be TLS-protected, the actual communication between a RADIUS server and its authenticators is not protected by itself.

Many sources often state in an off-hand remark that a VPN tunnel, such as IPsec, could be used to protect RADIUS sessions. This is hardly doable, though, as many devices in the authenticator role (e.g., switches) have no support for IPsec whatsoever. It appears that RADIUS actually has been recently extended with TLS support - the "RadSec" is described in RFC 6614 but I haven't seen it supported on devices yet - quite honestly, I've learned about it only now as I was looking for some specifics while writing this answer.

Protecting the aged RADIUS protocol is still a challenge, it would seem.

Best regards,
Peter

[Nadav]

Both RADSEC and Diameter have been downplayed, which is too bad. Thanks for your thoughts :)

[WimVS]

Hello,

I know this is an old post, but the question stays the same...

Maybe there happens to be a solution at this point?

Thanks.

Regards.

[jeremytetart]

Hello Cisco Guy,

As Nadav and other people, I'm asked why PAP ASCII is used as a authentication method even though we know this is not an encrypted protocol.

After some test, I confirm the PAP ASCII is used but encrypted by tacacs+ protocol. For me, login/pwd not pass in plaint text on the network.

Here the test's explaination :

Client (computer)

NAS (Switch, Router, Loadbalancer, Firewall etc...)

Authenticator (ACS/ISE)

There are 2 connections :

First connection :

From Client to NAS (SSH connection, tunnel is encrypted)

Second connection :

From NAS to Authenticator (Via Tacacs+ & PAP ASCII or CHAP)

On ISE node, we see the tacacs request with authentication method "PAP ASCII" protocol

I started a tcpdump on ISE node before I start a ssh session.

Now, I will check the first tacacs request (authentication) on wireshark trace

As you can see, the request is encrypted. No login/pwd appear in clear text.

Now I will decrypt the request through the shared secret configured between the NAS and the ISE node.

To sum up, Tacacs encrypt the PAP protocol so there is no login/pwd in clear text in the request.

If anyone is not agree with my conclusion, I'm available to discuss about it.

Regards