Cisco ISE sshd encryption-algorithm choices & OpenSSH

[dynaB]

Hi,

In the following Cisco ISE guide it is stated the four encryption-algorithm options supported for the sshd service are: aes128-cbc, aes256-cbc, aes128-ctr, aes128-ctr. However, I read somewhere Cisco ISE's ssh functionality is based on the OpenSSH library. Current OpenSSH versions offer more than those four choices: 

OpenSSH: the supported ciphers are

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

OpenSSH: the default is

chacha20-poly1305@openssh.com,
aes128-ctr,aes192-ctr,aes256-ctr,
aes128-gcm@openssh.com,aes256-gcm@openssh.com

I wonder if any of the @openssh.com choices would be able to be used for Cisco ISE as well, on its current state.

Cheers,

[Aref Alsouqi]

As of version 3.3 the algorithms shown in this link seem to be the only ones supported:

Cisco Identity Services Engine CLI Reference Guide, Release 3.3 - Cisco ISE CLI Commands in Configuration Mode [Cisco Identity Services Engine] - Cisco

I'm not sure though if TAC team via ISE root shell could enable more algorithms or not. I think it's worth check with TAC about this.

[Arne Bier]

@dynaB may I ask why you're looking for additional SSH encryption algorithms in ISE?  Is there an issue with the ones that we have available? I haven't studied the pros and cons of all of these - just curious.

[dynaB]

@Arne Bier So far there shouldn't be a problem with the encryption algorithms using CTR since it goes accompanied with authentication via a MAC, and CBC is still supported to this day even if not as a default in some libraries (openssh, for example) due to other options (CTR in this case) being considered more secure. These two options also seem more widespread than GCM.

However, supporting GCM as well could be an attractive option. Without trying to sound too preachy, it is a form of authenticated encryption - it encrypts via using a variant of CTR, while having a built-in integrity check, thus forgoing the need for a MAC found in the current options. Overall, GCM is considered a faster (due to integrating authentication within the encryption process rather than separated) and safer option to implement (it is only one implementation rather than two; less concern is raised with making encryption side and authentication side compatible with each other).

An aspect to consider is that current SSH options for GCM (and Chacha20Poly1305, offering a similar functionality) are defined by openssh itself, based on RFC 5647 (SSH follows its corresponding IETF RFCs as standard). Hence why they are accompanied with the @openssh.com tag. This in principle shouldn't be a problem since the differing factor from the standard is a matter of functionality within OpenSSH, fixing an existing issue.

Cheers,

[Arne Bier]

It's good to get one's head around these things, because it's not obvious at first glance.