David, Correct - you can use REXX or a shell script to read the password from a file or dataset. You could do this for either FTPS or SSH.
For FTPS, there are pros and cons to using X.509 certificates vs passwords. Certificates are more "protected", but both partners have to manage them and ideally they should be signed by a common CA and not self-signed. And if they are not stored in secure keystores on both sides, then they aren't much more secure than passwords. Kirk Wolf Dovetailed Technologies On Wed, Apr 1, 2009 at 9:56 AM, Cebell, David <cebe...@aafes.com> wrote: > Kirk, > > Thank You for that explanation. > > An example would be > > anonymous > cebe...@aafes.com > cd /toibm/mvs/ > binary > > I must not be current on this but what you are suggesting is the > password, > In this case "anonymous" can be stored in a protected dataset and then > included in my input statements? > > Perhaps we should be looking at FTPS and X5.09 certificates instead of > passwords. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Kirk Wolf > Sent: Wednesday, April 01, 2009 9:37 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: secure file transfer FROM z/OS > > David, > > I'm not sure exactly what this statement means wrt "passing clear-text > passwords". Can you supply more details? > > 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. > > 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). > > SSH Tectia also supports X5.09 certificates just like FTPS, but this is > a > non-standard extension to the SSH protocol and will only be supported > when > talking to another Tectia SSH implementation. > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > On Wed, Apr 1, 2009 at 8:54 AM, Cebell, David <cebe...@aafes.com> wrote: > > > The person who supports file transfer in our shop reports this. > > > > "Further, we concluded that FTPS does not satisfy PCI encryption > > requirements because there is no alternative to passing clear-text > > passwords for authentication during batch processing. The sftp > protocol > > provided in ssh-Tectia addresses this requirement." > > > > Is this true od is there a workaround? > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > > Behalf Of Timothy Sipples > > Sent: Wednesday, April 01, 2009 12:37 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: secure file transfer FROM z/OS > > > > Kirk has some good information on file transfer options using common > > protocols. I've got some more nominees which may be appropriate if you > > have > > long running, targeted file transfer needs -- such as a small number > of > > particular servers that need to stay more-or-less permanently attached > > and > > transfer a lot of files. > > > > Basically the other options would all be file sharing (NFS, CIFS/SMB, > > etc.) > > over an IPSec connection (encrypted connection). z/OS supports IPSec > and > > also supports common network file systems like NFS, CIFS/SMB, etc. > > > > As Kirk alluded to, there are also numerous private protocol file > > transfer > > products, and they do have advantages in many missions. > > > > By the way, "secure file transfer" is a misnomer when used as we're > > using > > it here. To be more accurate for the > (business-oriented/risk-analyzing) > > boss I would call this "encrypted transfer of raw files without > > custodial > > controls." (That name is unwieldy, but it's much closer to the truth. > > Perhaps someone has a shorter name that still gets the point across.) > > The > > file itself could (and usually does) contain extremely sensitive > > information -- things like customer records, credit card numbers, etc. > > Once > > each record is transmitted it leaves the security zone of its parent. > > > > To use an analogy, if you have the launch codes for nuclear missiles, > > yes, > > it's a good idea if you have to communicate that information to use an > > encrypted pipe. That's necessary but not sufficient. (The only thing > > encryption does is prevent somebody from intercepting the file data > > "over > > the wire.") You better be completely sure both sender and receiver > apply > > appropriate security protocols to such sensitive information. Which is > > why > > launch codes don't get spread around a lot, nor should credit card > > numbers > > and much other financial information, medical patient records, > corporate > > accounting (in any business), product design secrets, etc. > > > > - - - - - > > Timothy Sipples > > IBM Consulting Enterprise Software Architect > > Based in Tokyo, Serving IBM Japan / Asia-Pacific > > E-Mail: timothy.sipp...@us.ibm.com > > ---------------------------------------------------------------------- > > 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 > > > > ---------------------------------------------------------------------- > > 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 > > > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- 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
