Walt, I guess its cool now for IBM security audits to prefer passwords to certificates, now that z/OS 1.10 TSO supports >8 character passwords ;-)
Its a pity that RACF (and hw keystores) can't store SSH-style public/private keys (DSA, RSA) and support sign/check functions, to be exploited by z/OS SSH. X.509 isn't the only game in town, and the SSH RFC group has some good rationale against adopting it. But z/OS Ported Tools OpenSSH has several weaknesses wrt security - where's kerberos? where's PAM? Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Apr 1, 2009 at 10:48 AM, Walt Farrell <[email protected]> wrote: > On Wed, 1 Apr 2009 09:37:26 -0500, Kirk Wolf <[email protected]> wrote: > > >I'm not sure exactly what this statement means wrt "passing clear-text > >passwords". Can you supply more details? > > Excellent question, Kirk. > > > > >With FTPS or SSH/SFTP, clear-text passwords are NOT sent over the network. > >(Note: FTPS needs to be configured properly to encrypt the control > >connection) > > > >To use a password from a batch client (FTPS or SSH), it is possible to put > >the password in a dataset or file that is protected by your z/OS security > >package so that only the client job can read it. The FTPS or SSH client > job > >reads this password and uses it on the connection command. > > > >FTPS also supports X5.09 certificates instead of passwords; these can be > >stored in RACF (ACF2, etc) so that only authorized users can use them for > >signing a login request. > > FTPS (to the z/OS FTP server or the i5os FTP server, at least) also allows > bypassing the prompt for the client to enter a user ID and password, when > the client has supplied a digital certificate for authentication. That > woud > eliminate the need for having the password in a secured data set, as you > wouldn't need it at all. > > However, I'm not aware of any non-IBM FTP servers that have this capabiity. > > > > >SSH (both Ported Tools and Tectia versions) supports a public/private DSA > or > >RSA keypairs as an alternative to using a password. The private key is > >stored in a file that is protected so that only the client job userid can > >access it (using standard Unix security bits or ACLs and your security > >package). There is not an option to store the private key in RACF (ACF2, > >etc). > > And storing a private key or a password in a protected data set are about > the same, from a security risk perspective. So if someone will accept > storing a private key they should accept storing a password. The only > practical difference may be that they may not require private keys to > change > as often as they require passwords to change, making use of the SSH > private/public key technology a bit simpler. > > Of course, one might argue that that makes using SSH private/public key > implementation weaker, in some ways, than using passwords. It's certainly > a > major factor in why we don't allow SSH authentication via private/public > key > in our z/OS Common Criteria security evaluations. > > -- > Walt Farrell, CISSP > IBM STSM, z/OS Security Design > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
