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

From: John Hind <[email-masked]>
Date: Thu, 4 Dec 1997 11:51:07 -0500

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)
>
>     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.
>
>     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.

>
>     The SMTP, IMAP, POP, LDAP drafts all discourage the use of a separate
>     ports.
>
   ** the EMAIL wire protocols are not interested in protecting the data or
      authentication of the end-user sender/receiver (this is done by signing
      and or encrypting the message outside of these protocols using something
      like SMIME or PGP) but only in discouraging SPAMers from injecting junk
      in the network. One of the latest drafts I read clearly points out the
      man in the middle attack problem with this approach.

      The only real secure LDAP available today in fact uses a separate port
      ("The default secure (LDAP over SSL) LDAP port of 636 can be selected by
      supplying the constant LDAPS_PORT" in the oct 96 LDAP RFC draft
      at http://www.alternic.net/info/drafts/draft-howes-ldap-api-00.txt.html
and
      also see
http://home.netscape.com/eng/server/directory/3.0/ag/dsmanage.htm#1009690)
>
>     Do we really need to add a definition for a second port in this
>     document?  Please comment on or expand these lists.
>
   ** Frankly I see no need to dedicate a separate port in our RFC, the TN
server can simply
      be configured to use some port for secure operations (e.g. 8023) and this
can be communicated
      to the client configurator along with a host name and the fact security
is required. Given
      all WEB activity today it might be useful to formalize a URL format for
this such as
      TN3270ES://myhost.somewhere.com:8023/

>     Joe
>     [email-masked]
...
John Hind

---

From: Michael Boe <[email-masked]>
Date: Fri, 5 Dec 1997 09:19:18 -0800 (PST)

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...

>       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."

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).

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'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). 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.

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.

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

[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).]

>       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
    b) inline negotiation should be dropped from consideration? or
    c) servers and client must both implement inline and "up-front" TLS
negotation? or
    d) none of the above?

>       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 :-).

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
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

>       authentication of the end-user sender/receiver (this is done by
>       signing and or encrypting the message outside of these protocols
>       using something like SMIME or PGP) but only in discouraging SPAMers
>       from injecting junk in the network. One of the latest drafts I read
>       clearly points out the man in the middle attack problem with this
>       approach.
>
>       The only real secure LDAP available today in fact uses a separate
>       port ("The default secure (LDAP over SSL) LDAP port of 636 can be
>       selected by supplying the constant LDAPS_PORT" in the oct 96 LDAP RFC
>       draft at
>       http://www.alternic.net/info/drafts/draft-howes-ldap-api-00.txt.html
> and
>       also see