Subject: RE: TLS and TN

From: [email-masked]
Date: Sun, 7 Dec 1997 19:43:13 -0800

I think that the TN Server must be able to enforce security policy
regardless of what the host does.  I can think of two reasons why this
is a requirement:

1)      The mainframe doesn't really provide any way to secure a printer
LU.  Thus, unless the TN server provides this, printer LUs are
vulnerable.  The one customer that we've had participate actively on the
security front (Boeing) has voiced repeated concerns about this issue.
2)      If the server doesn't know who should (and thus who shouldn't)
be connecting to it, it is that much more vulnerable to a denial of
service attack.  An attacker could just connect to the server without
logging on to the mainframe.  This would consume both host and server
resources.  I know that this could be handled at the Firewall, but many
customers seem intent on just letting SSL passthru unchecked.  Providing
some client authentication at the TN server helps solve this problem.

        Given the murky state of issuing and managing client-side
digital certificates, I propose that we use some sort of basic
Userid/Password mechanism.  If TLS is being used to secure the session,
this Userid/password exchange would occur after TLS negotiation on the
encrypted channel.  If there is no TLS, then there should still be an
option for this exchange to occur (so customers can still secure their
printer LUs if they so choose).

Rodger D. Erickson
Technologist
Wall Data Inc.
[email-masked]
(314) 721-4640

        -----Original Message-----
        From:   John Hind [SMTP:[email-masked]]
        Sent:   Sunday, December 07, 1997 1:27 PM
        To:     [email-masked]
        Cc:     [email-masked]
        Subject:        Re: TLS and TN

         Deric Villanueva raises an important point :

        >Will a TN3270 Server ever be interested in authorization of
        >access to setsof discrete resources under it's control?  If
        >so, then mutual authentication is necessary to determine client
        >authorization level.

        *** It is my belief that this will become important and that
        mutual authentication should be allowed if not encouraged but
        many customers may find one-way good enough for some time
        to come so it should not be mandated.

        >I can certainly see that if the TN3270 server is attached
        >to only 1 host or PU then access control or authorization
        >policy might not apply. In this case utilizing the existing
        >constucts in 3270 make sense.  However in the case of multiple
        >hosts, host types or distributed data links (e.g. SNA
        >Server) it might be useful to control access to host resource
        >(destination, LU range, printing...) based on user credentials.

        *** actually the basic resource level is a pool of LUs and in
        addition to what host applications are available to the pool
        consideration must be given to availability of to groups of
        users.

        >Is is safe to do this based on one way authentication of the
server?
        >Is >this a function that the server vendors even care about?

        *** Its "safe" if the 3270 hosts authenticate the users via
logon BUT it means
        that
        the TN server can't help in enforcing resource utilization
policies. We know
        that
        this is important to customers since that's one of the reasons
TN3270E added
        the ability to specify LUNAME (often used as an LU pool name by
TN servers).

        John Hind
        [email-masked]@internet

---

From: Michael Boe <[email-masked]>
Date: Mon, 08 Dec 1997 19:58:25 -0600

Roger,

> some client authentication at the TN server helps solve this problem.

DOS (Denial of Service) attacks can proceed at pretty much any level.
The client can procede through the TLS negotiate by sending one byte at
a time (the waiting some seconds).  This ties up the port just as surely
as does getting all the way to the host.  You perfectly right--if the
client connects to a "generic" resource then it can stay there some
length of time, chewing up one LU *and* a connection on the server.  So
your argument is another good reason why it's a "good thing" to allow
the TN Server to check authentication before allocating any LUs or other
upstream resources.

Do we have anybody saying "nay" to this claim?

> printer LUs if they so choose).

Yep.  Does anybody disagree with this claim?

/msb

>   ------------------------------------------------------------------------
>
>    Part 1.2       Type: application/ms-tnef
>               Encoding: base64