Subject: Re: TN3270E Digest - 1 Dec 1997 to 3 Dec 1997

From: John Hind <[email-masked]>
Date: Mon, 8 Dec 1997 11:55:03 -0500

Michael,

 Please see my comments identified by  ***>  below:

----------------------------------------------------------------------------------------------------------------------
John,

I *think* that you're arguing for implementing dual-ports, and I *think* you're
not arguing against inline.  See some embedded questions for further options...

***> True, I believe that using dual ports when one needs both secure and
***> insecure access on the same TN Server is the best solution.

>  See my comments below:
>
> >     What are the advantages of defining a second TLS port for or doing
> >     inline negotiation of TLS? Here is a rough attempt at some of the
> >     advantages of each method.
> >
> >
> >     Defining a second port:
> >
> >     Can provide for easier server configuration in the presence of a
> >     firewall.
> >
>    ** TRUE, with single port the TN Server MUST KNOW NETWORK TOPOLOGY to
>       enforce security policy (e.g. all external traffic must be secured)

I'm not so sure. For certain server-site security policies, your statement is
certainly true.  But there are reasonable policies that don't require network
topology knowledge by the server.  Here's (what I hope is) such a policy:

a) client connections not providing authentication can access only those
applications which are considered "non-sensitive."

***> The problem is that the TN3270 server really has no way to know
***> what is or is not sensitive, at best it knows about pools of
***> LUs but it cant understand what the user is doing as far as
***> logon or application execution (eg a CICS transaction).

b) clients providing verifiable credentials can access a greater range of
application, or may be automatically connected to a single application
(depending on what their authorization is).

***> Perhaps by a future extension which allows the TN3270 Server to
***> process the data stream as if it where an emulator (eg EHLLAPI
***> macros set up by the administrator) but this is not yet
***> defined.

Note that you don't even need to consider a trans-firewall connection with the
policy.  For instance, this policy is most likely an intranet policy, not an
extranet one.

***> Here is where we disagree, many corporate entities might well allow
***> clear text logon and transactions over their INTRANET but not
***> over an INTERNET connection. So lets take the example of a salesman
***> in such a company with his portable computer loaded with a TN client,
***> when it's plugged into the LAN at his office it's fine that his
***> non-secure connection request to the sales TN server work but
***> when dial-in via an ISP that same request must fail since it
***> would expose ID/password/data on the INTERNET (note here that I
***> am not addressing VPN arrangements like using L2TP or IPSEC which
***> logically make his portable look like its plugged into the office
***> even though it's dialed in via the Internet). To do this either
***> the firewall or the TN server must stop the external non-secure
***> request from working, if its the TN server then it must know the
***> topology, if it's the firewall then it either must be able to
***> rely on a port always demanding secure connections.

Here's a variation on that theme.  Consider the corporation moving away from
RACF on their customer-support desks and replacing it with "smart-cards" that
the provide RSA certs to the server (and so obviate the need for the
customer-support person to enter in a account/userid/password on the screen at
each login).

***> suggest you look at
***>    http://www.s390.ibm.com/products/racf/racfhp.html#newstuff

The systems integrator has converted all the machines. However,
the company cannot convert all the customer-support personnel at once; the
facilities/security department says it will take at least six months to finish
issuing all customer-support personnel with proper smart-cards (this should
sounds familiar to many of us :-).

a) client connections not providing authentication can access the old version
of the application which does a RACF password challenge; and

b) clients providing verifiable credentials gets the new version of the
application which does not challenge.

***> The TN server can't do this yet without full awareness of the data stream,
***> even if it has awareness it still may be impossible due to the way
applications
***> work on a host today (passing a session from one to another). I suggest
***> that there will always be a need for an access control manager on a host
***> and that the identity of the session user will some-how need to be
submitted
***> to it be it and ID or a DN verified by a password or digital signature,
etc

If a dual-port approach is taken, a change must be made on each
customer-support desktop soon after that customer-support person is "flipped"
to use the smartcard.  This is because the sessions go to port 23 if they are
going to the "old" version, but need to go to port 992 if they are going to the
"new version."  A single-port approach is best here, because it avoids someone
having to change all the desktop configurations.

***> no matter how you slice it there MUST be a change at the client be it a
***> checkbox or "992", in fact for this scenario I suspect there is also a
***> total re-install/replacement of the TN client as well as some smartcard
***> reader hardware and a compatible security software layer be (eg
CAPI,CDSA,...)

Note that again, network topology doesn't enter into the discussion.

***> If the single port you speak of is available to the Internet then if it
***> allows unsecured connections the TN server must be aware of topology.

[The moral I'm driving at as that we need to consider all reasonable use-cases
here, not just extranet/trans-firewall ones. Of course, we don't want to
consider any *un*reasonable ones (and grant us the grace to distinguish them).]

> >
> >     Inline Negotiation:
> >
> >     Does not use up a second port
>
>    ** TRUE
> >
> >     Flexibility to allow for both clients that support TLS and those that
> >     don't.
> >
>    ** TRUE, note that some existing support libraries/classes/wedges would
>       need  code changes for even the simple scheme I proposed.

Are you proposing that:
    a) some clients (or servers) don't have to implement inline negotiation at
all to be compliant?  or
***> Yes
    b) inline negotiation should be dropped from consideration? or
***> inline, IMHO, should be optional
    c) servers and client must both implement inline and "up-front" TLS
negotation? or
***> those supporting security would implement up-front TLS be it separate
***> port or the "up front" inline scheme I proposed.
    d) none of the above?

> >
> >     Client configuration is easier.  The client does not have to
> >     reconfigure for secure and non secure connections.
> >
>    ** FALSE, THE CLIENT MUST FORCE SECURITY AND NOT NEGOTIATE TO NON-SECURE
>       as doing this allows a man in the middle attack - the clients session
>       configuration must at least have a secure/not-secure flag that can
>       not be negotiated on session setup.

I agree that the clients must have some means of regulating how much/little
security is used, and that due to server-spoofing, this regulation must come
from within each participant independent of the other participant. Just to make
sure we're talking about the same thing, here's what I think you saying:

client-in-unsecure-environment:    needs to make sure connection is secure
client-in-secure-environment:      no need for secure connection

The trick is how the client can determine whether or not it is in a secure
environment.  Where it is not sure, it's of course best to one of two things
(again, dependent on site policy):
    a) query the end-user with a pop-up noting a security anomoly and asking
user whether it's safe to continue, or
    b) shut down the connection.

Note that option (a) is functionally equivalent to having some
"secure/not-secure" flag in the configuration. We can argue human-factors some
other time :-).

***> after seeing some of the pop-ups from web browsers and imagining I was
***> some clerk trying to get my job done, I believe we need to consider
***> "human-factors" up front.

Now in some environments, the client may be able to determine if the current
environment meets the policy-requirements of being a "secure" environment. If
the client, for instance, can determine that it is in an IPSec environment that
stretches from the local subnet to the server, then it might feel comfortable

***> VPNs are yet another TN topology problem for the single port solution!
***> You can't rely on the client to know. (remember that laptop and how easy
***> it was to click the in-office icon after a dial-in.

not using TLS. However, that's all value-added stuff that has little to do with
fleshing out a useful spec that results in interoperable implementations.

/msb

---

From: Michael Boe <[email-masked]>
Date: Mon, 08 Dec 1997 21:12:55 -0600

John,

Another trip on the merry go 'round....

>  Please see my comments identified by  ***>  below:

Sure, I agree that the TN Server doesn't know about whether the LU is
sensitive.  However, the configuring-user can certainly set things up
that way. For instance, the configuring user can make sure that all the
LUs accessible via a given port on the TN Server all go to a single
application.  If that application has sensitive data, then the
configuring-user should also ensure that the TN Server requires
authentication and/or encryption on all connections coming into that
port.  The TN Server doesn't have a clue about whether the application
is sensitive, yet the configuring-user has managed to successfully
implement the site policy.

My general point is that we shouldn't be trying to guess whether or not
the TN server knows whether an application or LU is going to be carrying
sensitive data.  I've given one example, I'm sure there are others
(there are certainly other options on CIP TN3270 Server, where the
program can actually listen on multiple server IP addresses).

> ***> macros set up by the administrator) but this is not yet

No, I don't think this matters, and I think the same example I gave
above works here (with a little expansion).  A server implementation
might "map" a user-identity to an LU, or a pool of LUs (which might in
turn be mapped to an application).

Or, it can do exactly as the IBM MVS TCPIP TN3270 Server does now.  That
implementation never really communicates to VTAM what the LOGON is--it
interprets the reply to the USS10 message and then applies authorization
policy to that. The result is that the TN server hands VTAM the SIMLOGON
request directly.

> ***> rely on a port always demanding secure connections.

That's a valid example, but it doesn't diminish the validity of my
original example. In the original, note that the TN Server servicing
Intranet clients can listen for incoming connections on a
ip-address/port which cannot be reached from outside the firewall. The
TN Server needs no conception of connections originating from "inside"
or "outside" of the firewall. The network-designer (and the
configuring-user) need to be aware of this distinction, but the TN
Server does not need to be.

Again, all I'm claiming (here) is that there are many valid security
policies that do not require the TN Server to have knowledge of
application-content or network-topology, yet can be implemented with a
single-port solution.

> ***>    http://www.s390.ibm.com/products/racf/racfhp.html#newstuff

Yep....though others outside of IBM might choose to do things other
ways.

> ***> to it be it and ID or a DN verified by a password or digital signature,

Can you explain why you think this?  My employer's TN Server product can
currently map which application an incoming TN3270 connection gets on
the basis of:
    a) which server IP address the client connected to;
    b) which server port the client connected to;
    c) which client IP address the client connected from;
    d) which LU the client requested.

MVS TCPIP TN3270 Server has some of these same features.

> ***> reader hardware and a compatible security software layer be (eg

Sure....my example had all client desktops getting upgraded to have
smartcard readers. But the client desktops had to work without
configuration change at the desktop from the time before the user were
issued the actual smartcards to the time through the time after the user
was issued the smartcard and instructed to use it. My example showed how
this could be done (using a single port). On the other hand, it doesn't
appear possible to execute this migration smoothly (ie without having to
go back and change the desktop configuration when the user changes from
non-smartcard to smartcard) with a dual port implementation.

> ***> allows unsecured connections the TN server must be aware of topology.

Nope.  Again, this server's listening-point (IP-address & port #)
doesn't need to be visible to people outside the firewall for the
example to be valid.  So why do you think it needs to know the network
topology?

> ***> port or the "up front" inline scheme I proposed.

Let's discuss this in the WG meeting on Wednesday.

> ***> "human-factors" up front.

Anyone?  As a server vendor, I'm not really in a position to weigh in on
this with any authority.  Sure, I occasionally run into Netscape browser
messages concerning certificate validity, but it's still a novelty to me
and so I haven't been annoyed enough by the way things currently work to
think of something new :-).

> ***> it was to click the in-office icon after a dial-in.

I'm not disagreeing with that.