Subject: RE: TLS and TN

From: [email-masked]
Date: Fri, 12 Dec 1997 11:31:09 -0800

Deric,

        I agree that it is desirable to be efficient about this.  Going
to the trouble to negotiate an encrypted channel before denying a user
access to a particular service would be unfortunate.  However, I can
think of 3 reasons why it is acceptable:

1)      The investment in infrastructure required to do that sort of
authentication before negotiating an encrypted channel is large.
2)      The investment in infrastructure required to do it after an
encrypted channel is available is relatively small
3)      Support for TLS Session Caching makes subsequent connection
attempts *much* cheaper and faster since there's no key exchange.
Assuming that the user will turn around and try something else with the
same server, the problem you describe is no longer such a bad thing.

        For those that do have a Kerberos infrastructure in place, doing
the authentication ahead of the encryption may be preferred.  If we
could specify this authentication so it could take place either before
or after (rather than just after) then that *might* be desirable.  I say
*might* because I don't want a protocol that's too hard.
                Maybe we should save this for subsequent steps down the
security path when we better understand not only customers needs but how
far they are willing to go in terms of investing in security-related
infrastructure.

        Rodger

        -----Original Message-----
        From:   Deric Villanueva [SMTP:[email-masked]]
        Sent:   Friday, December 12, 1997 11:29 AM
        To:     [email-masked]; [email-masked];
[email-masked]
        Subject:        RE: TLS and TN

        Rodger

        At 07:43 PM 12/7/97 -0800, [email-masked] wrote:
        >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).
        >
        If such a mechanism were to be included it might be easier to
place this
        authentication step ahead of the establishment of an encrypted
channel.  It
        will likely consume less resources when the server must deny
service,
        rather than setting up the secure pipe then tearing it down
again.

        Deric

/=====/=====/=====/=====/=====/=====/=====/=====/=====/=====/=====/
        CyberSafe Corporation           http://www.cybersafe.com
        1605 NW Sammamish Road, #310    Issaquah WA. 98027-5378
        Tel: 425.391.6000                       Fax: 425.391.0508

        Me not them ===> CyberSafe.

/=====/=====/=====/=====/=====/=====/=====/=====/=====/=====/=====/