Mark,

I was thinking about whether there are good temporary workarounds for your
problem.

First attempt:

I was thinking that you could maybe use "Match" for the specific client
host that needs it and then in sshd_config add aes_ctr to the Ciphers for
that client and in zos_sshd_config change CiphersSource to any for that
client.   No go - neither one of those keywords are allowed in a Match
block in sshd_config.  Looking at the open source code, some things like
key-exchange (which is where Ciphers are negotiated) pretty early, before
Match blocks are available.  Pity.

But it is straight-forward to ask the client (assuming they have OpenSSH
and most others) to put a Match block for your server in ssh_config and
then add aesxxx-cbc to the Cipher (it is allowed there).   aes-cbc is FIPS
certified, but out of favor in ssh because of a potential vulnerability.
 z/OS OpenSSH doesn't suffer exposure, but some implementations do.   Some
shops are extra vigilant :-)

Second attempt:

As you have done, add the aes-ctr ciphers to your sshd_config Ciphers list
(along with the ICSF supported ciphers)
also change zos_sshd_config  CiphersSource to "any"

this will solve your problem, since "OpenSSL" will be used for any Cipher
(aes-ctr) that is not supported by ICSF.
The problem is that you will probably end up using aes-ctr for *most*
sessions into your server, since these are at the front of the default list
for most client implementations.   That will mean that you won't use ICSF
for your sshd ciphers.  Not great unless you have CPU cycles to burn :-)

So, the first approach is the best if you can coordinate it with your
trouble client.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> We have a new document available:  "IBM Ported Tools z/OS OpenSSH -
Quick Start Guide", which covers setup and tuning of OpenSSH + ICSF crypto.
 It can be found on the main page of our web site.


On Mon, Mar 10, 2014 at 10:02 AM, Mark Jacobs <[email protected]>wrote:

> We've been trying to migrate our ssh/sftp environment, for both our client
> and server users to only use FIPS-140-2 certified ciphers, and run ICSF in
> FIPS mode. We've had no problems doing so, except with one of our partners
> who states that their security policy will not allow their sftp server to
> accept data transmitted with any CBC cipher.
>
> I tried adding the aes-ctr ciphers to our allowed list, but it doesn't
> look like ICSF can handle it, which is needed for ICSF to execute in FIPS
> mode.
>
> It seems like I'm in a unresolvable problem from a technology standpoint,
> unless our partner changes their policy, which I don't understand why they
> don't allow FIPS-140-2 certified ciphers to be used.
>
> --
> Mark Jacobs
> Time Customer Service
> Tampa, FL
> ----
>
> The quiet ones are the ones that change the universe...
> The loud ones only take the credit.
>
> Londo Mollari - Babylon 5
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to