On Wed, 1 Apr 2009 09:37:26 -0500, Kirk Wolf <k...@dovetail.com> 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
