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
