Re: TN5250 SSL Client Authentication -- MIDRANGE-L

Hi,

Normally in SSL applications, certificates are verified by checking to see
who "signed" them.  If the certificate authority who signed the
certificate is trusted by the application, it will allow the certificate.

In places like the internet, it's not practical to keep a database of
every possible certificate to see if it's valid, and/or delete it when you
want to revoke it.    Just imagine if every web browser needed to contain
a copy of every possible web server's SSL certificate!

Anyway...   by issuing each user a certificate signed by your own personal
certificate authority -- and configuring your iSeries telnet server to
only trust certificates signed by your iSeries -- you've made your system
significantly more secure.   Now only users that you've issued
certificates to can connect.   That's great!

If someone leaves the company, they can still connect, it's true.
They'll get a sign-on screen.   But, if you disable their user profile,
how will they log in?

but, if you don't want them to even be able to try userids and passwords,
you can extend the security of your system using a "Telnet Device
Initialization Exit Program".  In that program, you can write code that
examines the certificate that they've presented.  I see no reason why you
couldn't write code to check if they're still an active user, and if not,
deny access.



On Fri, 4 Apr 2003, Sean Porterfield wrote:

> Has anyone successfully implemented client authentication?  I know it gets
> brought up occasionally, but I couldn't find any details in the archives.
>
> I found the message Scott Klement sent referring me back to the one I sent
> that has a link to IBM.  FYI, the procedure has changed since then!  We are
> on V5R1 now, and to force client authentication you need to use DCM
> application configuration.
>
> I created a certificate authority and certificate.  Assigned the certificate
> to the services I wished.  Turned on "require client authentication" and
> restarted telnet.  I was denied a signon screen (finally!)
>
> Then I created a user certificate, installed it in my browser, exported to a
> file, imported into key manager.  I may have had to reboot at this point,
> but after specifying "Use default" under client certificate, I got a signon.
> So far, so good.
>
> Then I went back to DCM and removed the assignment of the certificate to the
> user.  No change - still get a signon.  So I deleted the certificate (just
> to confuse the issue, I had created 2 certificates, so it seems I used
> "remove" for one and "delete" for the other.)  No change, still able to get
> a signon with the deleted certificate.  Ended and started telnet to be sure,
> no effect.  Even rebooted, not that it should matter since I'm trying to get
> the AS/400 to do the verification.
>
> Is this correct behavior?  Once genereated, the AS/400 will trust the
> certificate until expired even though it's been deleted?  Doesn't do much
> for our security plan...
>
> I have a few more docs to read, but if the above doesn't generate any
> obvious answers, the next step appears to be enabling CRL and figuring out
> how to publish the CRL to the LDAP server.  Then figure out how to revoke a
> certificate.  And decide how to create certificates for all the users.
>
> Luckily, I have a backup system to work on for testing, but I need to get
> this going in production ASAP.
>
> Any ideas will be greatly appreciated.  I've already skimmed through the
> obvious Redbooks (Tips and Tools for Securing your iSeries, Deploying a
> Public Key Infrastructure, Developing a Digital Certificate Infrastructure,
> iSeries Security Reference)
>
> Thanks!
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>