[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: TLS FTP
From:       Scott <scott () AITRUS ! ORG>
Date:       2009-11-24 20:48:50
Message-ID: 9b1c03bb0911241248w76c24a3ct7ec17cb0bc65639c () mail ! gmail ! com
[Download RAW message or body]

No real learning curve on RDATALIB.  Assuming "FTPD" is the id name, you'd
create an RDATALIB profile:

FTPD.KEYRINGNAME.LST

and give FTPD 'UPDATE' authority.  Unless you want it to have access to the
private key data on a CERTAUTH/SITE cert, then it needs CONTROL.

establishing RDATALIB won't affect any other KEYRING/cert access, unless
your TN3270 daemon is using that KEYRING and you don't give it access.

Obviously, you'd want to brush up on it before implementing.  That's also at
inherentlylame.com.

Anyway, because TN3270 is the owner of the Cert and you're trying to access
it with FTPD, that's where your problem is coming in.  Because it's owned by
TN3270, I do not believe you can give FTPD access to the private key data.
The ghetto-fabulous implementation was to make all your server-ish private
keys a SITE certificate and then give your daemons CONTROL authority to
IRR.DIGTCERT.GENCERT.  Which is bad and is the reason that RDATALIB is very
long overdue.

http://publib.boulder.ibm.com/infocenter/zos/v1r10/index.jsp?topic=/com.ibm.zos.r10.ichd100/usgntrdata.htm


Scott

On Tue, Nov 24, 2009 at 12:40 PM, Hal Merritt <HMerritt@jackhenry.com>wrote:

> FTPD has UPDATE to IRR.DIG** profiles.
> FTPD is the owner of the ring.
> There is only one personal certificate connected to that ring, but is owned
> by another ID. It is the same certificate used by TN3270.
> 
> I haven't had time to go through the learning curve on RDATALIB.
> 
> -----Original Message-----
> From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
> Scott
> Sent: Tuesday, November 24, 2009 12:55 PM
> To: RACF-L@LISTSERV.UGA.EDU
> Subject: Re: TLS FTP
> 
> Whatever you're using to access the KEYRING does not have authority to view
> Private Key data.
> 
> Do a LISTRING and please say who owns the key.  Is it SITE/CERTAUTH/USER?
> What access rights does your FTPdaemon have to the IRR.DIGT*.** profiles?
> 
> What you're dealing with is basically the exact reason I began using
> RDATALIB, and I made a write-up here: inherentlylame.com
> 
> Scott
> 
> On Tue, Nov 24, 2009 at 10:17 AM, Hal Merritt <HMerritt@jackhenry.com
> > wrote:
> 
> > Here is a trace entry I think is the key (pun intended):
> > 
> > STC03513 00000281  BPXF024I (SYSLOGD) Nov 19 17:56:37 TST2 ftps 50331664
> > 
> > FR0578 270
> > 270 00000281  authClient: init failed with rc = 428 (Key entry does
> not
> > contain a
> > 270 00000281  private key)
> > 
> > My server certificate is self signed and does have a private key.
> > 
> > -----Original Message-----
> > From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
> > Wai Choi
> > Sent: Friday, November 20, 2009 8:15 AM
> > To: RACF-L@LISTSERV.UGA.EDU
> > Subject: Re: TLS FTP
> > 
> > Hal,
> > 
> > Even for server authentication, private key of the server certificate is
> > still involved. You may have the keyring set up that works for tn3270
> > before. The same setup doesn't necessarily work for FTP. For example if
> > the ID that runs the FTP server is not the same as that runs the tn3270,
> > then it won't have access to the private key owned by the tn3270 server.
> > Also you will need the issuer certificate of you FTP server installed in
> > your PC client.
> > 
> > Wai Choi - RACF/PKI Development
> > 
> > 
> > 
> > 
> > From:
> > Hal Merritt <HMerritt@JACKHENRY.COM>
> > To:
> > RACF-L@LISTSERV.UGA.EDU
> > Date:
> > 11/19/2009 04:06 PM
> > Subject:
> > Re: TLS FTP
> > Sent by:
> > RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>
> > 
> > 
> > 
> > Yes, I had (or thought I had) z/os -> z/os working. I do have tn3270 TLS
> > working and that's somewhat similar.
> > 
> > This is the first PC client I've had to test, and it is a new release. I
> > have debug sec and SOC(3) turned on which is where I got that trace
> entry.
> > 
> > I'm not a RDATALIB user as yet. I'm fairly sure the RACF and FTPSDATA
> > issues were all ironed out in early testing, but that was under 1.7
> (we're
> > now 1.9).
> > 
> > 
> > 
> > -----Original Message-----
> > From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
> > Scott
> > Sent: Thursday, November 19, 2009 12:01 PM
> > To: RACF-L@LISTSERV.UGA.EDU
> > Subject: Re: TLS FTP
> > 
> > Can you list the keyring that is being used by FTPD, and your
> IRR.DIGT*.**
> > profiles (only the access that FTPD has to it) -or- your RDATALIB profile
> > covering that KEYRING, if used.  Can you list your FTP.DATA configuration
> > options related to TLS, secure_*, ciphersuite, extensions, etc?  Are you
> > able to turn on debug sec?
> > 
> > It sounds like you have z/OS ---> z/OS FTPS working (ie, between LPARs),
> > but
> > I just want to confirm that you do.  Also, is your PC windows or lunix?
> > What FTPS client are you using?
> > 
> > Once you list those, it should be a really easy thing to solve.
> > 
> > Scott
> > 
> > On Thu, Nov 19, 2009 at 10:13 AM, Hal Merritt
> > <HMerritt@jackhenry.com>wrote:
> > 
> > > I am attempting a TLS FTP connection from a PC to the z/os server and
> > > getting the following trace entry:
> > > 
> > > BPXF024I (SYSLOGD) Nov 19 17:56:37 TST2 ftps 50331664 : FR0578 270
> > > authClient: init failed with rc = 428 (Key entry does not contain a
> > > private key)
> > > 
> > > I believe I am specifying server only authentication, so why is the
> > client
> > > being authenticated?
> > > 
> > > Or is this some issue with the server's certificate?
> > > 
> > > Thanks!!
> > > 
> > > 
> > > NOTICE: This electronic mail message and any files transmitted with it
> > are
> > > intended
> > > exclusively for the individual or entity to which it is addressed. The
> > > message,
> > > together with any attachment, may contain confidential and/or
> privileged
> > > information.
> > > Any unauthorized review, use, printing, saving, copying, disclosure or
> > > distribution
> > > is strictly prohibited. If you have received this message in error,
> > please
> > > immediately advise the sender by reply email and delete all copies.
> > > 
> > NOTICE: This electronic mail message and any files transmitted with it
> are
> > intended
> > exclusively for the individual or entity to which it is addressed. The
> > message,
> > together with any attachment, may contain confidential and/or privileged
> > information.
> > Any unauthorized review, use, printing, saving, copying, disclosure or
> > distribution
> > is strictly prohibited. If you have received this message in error,
> please
> > immediately advise the sender by reply email and delete all copies.
> > NOTICE: This electronic mail message and any files transmitted with it
> are
> > intended
> > exclusively for the individual or entity to which it is addressed. The
> > message,
> > together with any attachment, may contain confidential and/or privileged
> > information.
> > Any unauthorized review, use, printing, saving, copying, disclosure or
> > distribution
> > is strictly prohibited. If you have received this message in error,
> please
> > immediately advise the sender by reply email and delete all copies.
> > 
> NOTICE: This electronic mail message and any files transmitted with it are
> intended
> exclusively for the individual or entity to which it is addressed. The
> message,
> together with any attachment, may contain confidential and/or privileged
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution
> is strictly prohibited. If you have received this message in error, please
> immediately advise the sender by reply email and delete all copies.
> 


[prev in list] [next in list] [prev in thread] [next in thread]