Secure FTP
Matthew Stitt
What are the requirements to make this work?
Thanks....
P.S.....I did send this to the TCPIP list, but got only one response, which was off base for what I wanted to know.
****************************************************************************************************
This e-mail and any files transmitted with it are confidential to abc distributing, llc.
("abc"), and may contain proprietary or copyrighted materials belonging to abc, which
are intended solely for the individual named. If you are not the named addressee, you
are notified that any copying, dissemination, distribution or disclosure of any or all of its
contents, and any action taken in reliance on the transmission, are unauthorized and
prohibited. Please notify abc immediately by e-mail reply if you have received this
transmission in error and take all necessary and appropriate actions to permanently
delete it from your system.
*****************************************************************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mark Gibbons
secure ftp. The best (I went to) was 3924, Secure Communications with
FTP and TN3270.... I'd be careful with SFTP, it might be the sftp
function from SSH which I'm told is not the ftp protocol at all. What I
remember from the sessions is that FTP using SSL should work (1.3 or
1.4? possibly earlier), using certificates for authorization and some
other fancy stuff is in z/os 1.5.
From 1.4 IP user's guide.
Transport Layer Security (TLS) is an upwardly-compatible successor to
Secure Sockets Layer (SSL). SSL is a protocol that performs secure and
encrypted TCP transmission. The FTP client supports either SSL or TLS
protected sessions, including client authentication. Note that the
negotiation of SSL versus TLS is performed by the sockets-layer TLS
code and is transparent to FTP.
The session had recommendations for ftp clients that did TLS.
** Excerpts are from a note Matthe...@ABCDISTRIBUTING.COM sent Tue, Aug
** 19th, at 09:53:29 to IBM-...@BAMA.UA.EDU, regarding "Secure FTP".
MS> I've sat on this one long enough. We have a requirement to do a secure FT
MS> using either PGP or SFTP (I'm hoping that means SSL FTP).
MS> What are the requirements to make this work?
MS> Thanks....
MS> P.S.....I did send this to the TCPIP list, but got only one response, whics
MS> off base for what I wanted to know.
Charlie Smith
>
> I've sat on this one long enough. We have a requirement to do a
> secure FTP using either PGP or SFTP (I'm hoping that means SSL FTP).
>
> What are the requirements to make this work?
>
> Thanks....
>
> P.S.....I did send this to the TCPIP list, but got only one response,
> which was off base for what I wanted to know.
Some stuff can be tunneled through a ssh connection. FTP is not very
amenable to doing that, because it uses several dynamically determined
ports for the data transfer. The password goes over port 21 so that can
be tunneled. The data would be transmitted in the clear.
If you are running ssh on both ends, you can set things up to use scp,
which is secure copy.
A good discussion of this is in the O'Reilly book on SSH, the ISBN on
that is 0-596-00011-1.
I have heard the name "sftp" mentioned, but don't know it. I'd sure
like to hear some information about it.
- Charlie
Charlie Smith cha...@elektro.cmhnet.org 614-271-1418
http://elektro.cmhnet.org/~charlie/ Columbus Ohio USA
SMS: charl...@elektro.com
Patrick O'Keefe
>I've sat on this one long enough. We have a requirement to do a secure FTP using either PGP or SFTP (I'm hoping that means SSL FTP).
>...
>P.S.....I did send this to the TCPIP list, but got only one response, which was off base for what I wanted to know.
>...
Actually, the response you got on the TCP/IP List was on target, and answered part of your question.
Alfred said SFTP isn't SSL FTP, and in fact, isn't FTP (ie, RFC 959) at all. It's a nonstandard file transfer system
that uses Secure Shell, and has nothing to do with FTP. There may be ISVs that have ported an SFTP
to Unix System Services.
As Alfred said in passing, and Mark Gibbons mentioned in greater detail on this list (quoting stuff from
Alfred's pitches at SHARE) MVS FTP supports TLS and SSL.
Alfred is the expert on SSL and TLS (among many other things) in MVS TCP/IP design and development.
If you don't think you got a good answer, try asking again. You'll be hard pressed to find anyone more
knowledgable about this aspect of MVS TCP/IP ... or more willing to help people understand MVS TCP/IP.
Pat O'Keefe
Peter Vander Woude
If you want a good place to start on research of the SSL FTP, check
out this web page, by one of the lead authors on FTP TLS.
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
Paul gives you information on clients and server implementations that
do FTP TLS (i.e. FTP SSL). I know that the z/OS 1.4 client does it just
fine, as I've been doing testing of that lately.
Peter I. Vander Woude
Sr. Mainframe Engineer
Harris Teeter, Inc.
Matt Simpson
> I know that the z/OS 1.4 client does it just
>fine, as I've been doing testing of that lately.
I've been testing it lately, without much luck, probably because I have something configured wrong. Is there a good "FTP-TLS for Dummies" reference? I've read all the parameter descriptions in the z/OS IP Config Reference doc, but I guess I'm still a little confused.
I don't really care about using TLS for client authentication. All I want to do is to encrypt the session so passwords are not sent in clear text. I'm not certain whether that means I need AUTH_TLS or not.
With my current setup, (AUTH_TLS enabled), when I connect to the z/OS server with the z/OS client, I get
EZA2897I Authentication negotiation failed
and I'm not sure why.
I understand that I need a server certificate. Our security product is ACF2, and it supports certificates and keyrings similar to the RACF support, although it's different enough that the manuals need some interpretation. I'm successfully using a site certificate stored in ACF2 for our HTTPS and TN3270 servers, so I'm not totally clueless about setting it up. But it's possible that I might not have it set up for FTP. I haven't been able to figure out whether my problem is a server certificate problem or something else.
Our certificate is signed by Thawte, which is one of the CAs that most web browsers trust without any additional tweaking. But I'm not certain about the FTP clients. Is there something I need to do to the z/OS client to tell it to trust certain CAs? The doc gives explicit instructions for copying certificates to the HOD client, but I don't have that.
Any suggestions for good doc or examples, or hints on debugging my problem?
Peter Vander Woude
In the FTP.DATA file that your FTP client is using, are you pointing
it to a keyring that contains the Thawte Certificate?
Peter I. Vander Woude
Sr. Mainframe Engineer
Harris Teeter, Inc.
>>> ma...@UKY.EDU 08/20/2003 9:45:23 AM >>>
Matthew Stitt
So I guess what I am looking for is a checklist of things that would be needed/wanted to make it happen.
-----Original Message-----
From: Peter Vander Woude [mailto:pwo...@HARRISTEETER.COM]
Sent: Wednesday, August 20, 2003 9:48 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: Secure FTP
Matt,
In the FTP.DATA file that your FTP client is using, are you pointing
it to a keyring that contains the Thawte Certificate?
Peter I. Vander Woude
Sr. Mainframe Engineer
Harris Teeter, Inc.
****************************************************************************************************
This e-mail and any files transmitted with it are confidential to abc distributing, llc.
("abc"), and may contain proprietary or copyrighted materials belonging to abc, which
are intended solely for the individual named. If you are not the named addressee, you
are notified that any copying, dissemination, distribution or disclosure of any or all of its
contents, and any action taken in reliance on the transmission, are unauthorized and
prohibited. Please notify abc immediately by e-mail reply if you have received this
transmission in error and take all necessary and appropriate actions to permanently
delete it from your system.
*****************************************************************************************************
----------------------------------------------------------------------
Matt Simpson
>
> In the FTP.DATA file that your FTP client is using, are you pointing
>it to a keyring that contains the Thawte Certificate?
>
Thanks for the hint. That made a difference, but I'm still not there. When I added that to the client FTP.DATA, I got an error about module GSKSSL not being found, so at least it was trying to do more than it did before. I added GSKLOAD to my steplib, and got past the missing module and back to the authentication failed. I turned on trace at the client end, and got different messages than I got before:
FC0139 ftpAuth: entered
FC0159 ftpAuth: security values: mech=TLS, sFTP=A, sCC=C, sDC=C
FC0182 ftpAuth: ........ cipherspecs = 060A
FC0223 ftpAuth: environment_open()
FC0341 ftpAuth: environment_init()
FC0345 ftpAuth: TLS init failed with rc = 416 (Permission denied)
I'm not sure where to go to find out what "Permission denied" means
Peter Vander Woude
and given your userid the proper access to this. I ran into that same
error recently. Once I defined the profile and gave the userid running
the job the proper access, I could run the job.
Peter I. Vander Woude
Sr. Mainframe Engineer
Harris Teeter, Inc.
>>> ma...@UKY.EDU 08/20/2003 11:50:46 AM >>>
On Wed, 20 Aug 2003 09:48:26 -0400, Peter Vander Woude
<pwo...@HARRISTEETER.COM> wrote:
>
> In the ftp.DATA file that your FTP client is using, are you
pointing
>it to a keyring that contains the Thawte Certificate?
>
Thanks for the hint. That made a difference, but I'm still not there.
When I added that to the client ftp.DATA, I got an error about module
Matt Simpson
>You haven't added the FACILITY class profile IRR.DIGTCERT.LISTRING
> and given your userid the proper access to this. I ran into that same
>error recently.
Yeah .. I figured that out. Actually, I had added it, because the servers needed it. But general users didn't have access to it. I tried it with a different user that had access to everything and got a different error:
FC0139 ftpAuth: entered
FC0159 ftpAuth: security values: mech=TLS, sFTP=A, sCC=C, sDC=C
FC0182 ftpAuth: ........ cipherspecs = 060A
FC0223 ftpAuth: environment_open()
FC0341 ftpAuth: environment_init()
FC0345 ftpAuth: TLS init failed with rc = 202 (Error detected while opening the key database)
I think this is probably because the way ACF2 stores keyrings isn't quite the same as RACF, and it takes some interesting gyrations to get things to match up. I'll have to play around with it a little more. Thanks for the help.
Peter Vander Woude
assigned to as user. When I specify the KEYRING parm in the ftp.data
file, I have to specify it as userid/ringname, where userid is the id
the ring is created under. When I leave the userid/ off the ringname, I
get the 202 error you are getting.
Peter I. Vander Woude
Sr. Mainframe Engineer
Harris Teeter, Inc.
>>> ma...@UKY.EDU 08/20/2003 12:29:14 PM >>>
Matt Simpson
>I don't know how ACF2 stores the keyring, but in RACF the keyring is
>assigned to as user. When I specify the KEYRING parm in the ftp.data
>file, I have to specify it as userid/ringname, where userid is the id
>the ring is created under. When I leave the userid/ off the ringname, I
>get the 202 error you are getting.
THANK YOU!!!! That was the trick. ACF2 uses a similar userid/ringname scheme, but I couldn't find any clear doc on how to tell which to use. I had created keyrings under the userids for the various servers (including the FTP server), and just used the ring name in their config files, and it seemed to work. I was afraid I was going to have to set up a keyring for each user that wanted to use a secure FTP client, but userid/ringname in the client FTP.DATA file worked, using the userid for the server. The next problem was that the client whined because it didnt' recognize the CA that signed the cert. I had our site cert in the keyring, but not the Thawte CA cert. I found Thawte's CA cert and added it, and now I get:
234 Security environment established - ready for negotiation
EZA2895I Authentication negotiation succeeded
Life is good!! Thank you very much!!!
Peter Vander Woude
state that issue more clearly. I only tried it because I saw something
about how to specify the keyring in the httpd.conf file, where it
mentioned the userid/keyring format.
Peter I. Vander Woude
Sr. Mainframe Engineer
Harris Teeter, Inc.
>>> ma...@UKY.EDU 08/21/2003 11:44:10 AM >>>
On Wed, 20 Aug 2003 12:35:32 -0400, Peter Vander Woude
<pwo...@HARRISTEETER.COM> wrote:
>I don't know how ACF2 stores the keyring, but in RACF the keyring is
>assigned to as user. When I specify the KEYRING parm in the ftp.data
>file, I have to specify it as userid/ringname, where userid is the id
>the ring is created under. When I leave the userid/ off the ringname,
I
>get the 202 error you are getting.
THANK YOU!!!! That was the trick. ACF2 uses a similar userid/ringname
scheme, but I couldn't find any clear doc on how to tell which to use.
I had created keyrings under the userids for the various servers
(including the FTP server), and just used the ring name in their config
files, and it seemed to work. I was afraid I was going to have to set
up a keyring for each user that wanted to use a secure FTP client, but
userid/ringname in the client ftp.DATA file worked, using the userid for
Matt Simpson
Apparently, anybody who wishes to use the z/OS client securely needs access to a keyring. I don't think I want to set up keyrings for every user. I'd rather have a global one.
From reading the doc, and seeing the access logs here, it appears that there's no way to grant access to a specific keyring; it's either all or none. Granting READ access to IRR.DIGTCERT.KEYRING allows a user to read his own keyring. Granting UPDATE access to the same resource allows him to read any keyring.
Aside from the fact that granting global access always makes me a little nervous, is there any real risk to allowing users to read somebody else's keyring?
In addition to the LISTRING, I'm also seeing CONTROL access to IRR.DIGTCERT.GENCERT when the client is invoked. I'm not sure why this is happening. Should I be frightened? Or is GENCERT relatively harmless? I guess in some shops that use client certificates a lot, users generate their own certificates. So maybe GENCERT isn't very dangerous. I've been looking at as an admin function, but maybe it's really a user function.