Subject: Re: TN3270 security proposal

From: [email-masked]
Date: Wed, 3 Dec 97 09:47:47 -0800

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.

     Inline Negotiation:

     Does not use up a second port

     Flexibility to allow for both clients that support TLS and those that
     don't.

     Client configuration is easier.  The client does not have to
     reconfigure for secure and non secure connections.

     The SMTP, IMAP, POP, LDAP drafts all discourage the use of a separate
     ports.

     Do we really need to add a definition for a second port in this
     document?  Please comment on or expand these lists.

     Joe
     [email-masked]

______________________________ Reply Separator _________________________________
Subject: TN3270 security proposal
Author:  rf27jrhe ([email-masked]) at internet
Date:    12/1/97 9:52 AM

Below is a description for using TLS for encryption with the ability  to
negotiate 1416 authentication in place of or addition to PKI. I have also tried
to describe the encryption requirement, need for client to be proactive in
security rather than be passive, the desire to be able to share certificates
with other services,  what verification means using PKI, things the server must
enforce,  dual/single ports and a shortened way to enter TLS.

I would appreciate comments and reactions to this description as it relates to
the proposed RFC.

John Hind

-------------------------------------------------------
Secure Telnet for 3270 and 5250 Emulation

 The use of telnet protocols for 3270 and 5250 emulation have traditionally
been used for two disjoint prepossess namely  to provide access to public
information held on mainframe systems over the IP Internet (such as a library
catalog) and to provide access to private  information held on a mainframe over
an IP Intranet (such as order tracking). Today there is a strong desire to blur
both the informational and network boundaries of these traditional segments and
with this desire comes the elevation of the requirements to both identify
information consumers  and protect against disclosure of information to
unauthorized parties. To put this in simple terms, an end-users mainframe
identity and password as well as any data which flows between that user and the
mainframe must be kept from a third parties view.

 In this document we are interested in addressing the interaction between the
Telnet Client and the Telnet Server that will support this secure requirement
with the knowledge that, at least for these emulation types, this is only a
portion of the total end-user to mainframe application path. Specifically it is
often true that the Telnet Server does not reside on the target mainframe (it
does not have access to a list of identities which are allowed to access to that
mainframe), and it is often true (3270) that the TN server can not even identify
that portion of the emulation stream which contains user identification/password
information. Additionally it may be the case that the Telnet client is not
co-resident with the end user and that it also may be unable to identify that
portion of the data stream that deals with user identity. We will make the
assumption here that there is a trust relationship and appropriate protection to
support that relationship between the TN Server and the mainframe such that data
on this path is protected and further that the mainframe will authenticate the
end user via the emulation stream as well as use this to control access to
information. We further make the assumption that the path between the end user
and the client is protected.

 To hold up our Telnet part of the overall secure path between the user and the
mainframe we need to make the telnet data stream unobservable to a third party.
We do this by creating a shared secret between the client and server which is
used to encrypt the flow of data and (just as important) require the client to
verify that it is talking to correct server (the one that the mainframe trusts
rather than an unintended man-in-the-middle) with the knowledge that the stream
itself will be used by the mainframe to verify the identity of the end-user.
Rather than create a specialized new protocol which accomplishes these goals we
instead have chosen to use existing protocols with certain constraints.

  The TLS (formerly known as SSL) protocol is used to provide the creation and
refresh of a shared secret, negotiation and execution of  data encryption,
primary negotiation of authentication, and if chosen execution of public key
based authentication. RFC 1416 is used for secondary negotiation of non-PKI
authentication such as Kerberos (RFC1411).  Rather than repeating details found
in these other protocols in this document, we instead will describe the
criteria by which options may be selected by the Telnet client and server as
well as how TLS/SSL fits into the Telnet stream.

When one-way authentication is negotiated it must always be of the server and
to prevent man-in-the-middle attacks the client must not only initiate the
secure channel request but also not allow a non-secure channel to be the result
of any negotiation that is undertaken. The server has the responsibility of not
only deciding if a given connection should be allowed to remain un-secure but
also ensuring that a secure channel negotiation results in encryption and at
least one-way authentication of the server OR in a disconnect.

Since both encryption and authentication is always needed for a secure channel
that meets the requirements of these emulation types, we can use the anonymous
authentication  negotiation option of TLS as an indication that the client
wants to negotiate an RFC 1416 authentication type. Granting this option by the
server indicates that the server supports one of these non-PKI forms and that
it will only allow the connection to continue if RFC 1416 based authentication
proceeds successfully as the first interaction  though the resulting  TLS
encrypted pipe.  RFC 1416 authentication may also be optionally performed after
a secure channel has been created using PKI authentication which allows the use
of older SSL V3.0 (see discusion in the TLS RFC of migration/coexistance
between SSL V3.0 and TLS V1.0) libraries that may not support anonymous
authentication.

  When PKI authentication is used no special X.509 certificate extensions will
be require but a client or server may choose to support an extension if found.
For example, they may use a contained certificate revocation URL extension if
provided. The intent is to allow sharing of certificates with other services on
the same host, for example, a Telnet server might use the same certificate to
identify itself  that a co-located WEB server uses. The method  of sharing
certificates is not a topic of this document.

  The Telnet client verification of a server certificate will include the
verification of the signature certificate chain to the point where the a
signature in that chain uses a know good signing certificate in the clients
local key chain. The client is required to drop the connection if this basic
check fails (which means that nothing in the certificate or the certificate
chain that was passed to the client can be trusted). The verification should
then continue with a check to see if the fully qualified host name which the
client connected to appears anywhere in the server's certificate subject (DN).
If no match is found then the end user should see a display of the servers
certificate and asked if he is willing to proceed with the session.

  Telnet servers will fall into one of three categories, those that do not
support secure channels, those that only support secure channels and those that
will allow secure channels (but do not require them). The first case is simple,
no change is needed to the client or server. For the second case we note that
the client must initiate a secure channel request  and not allow a negotiation
to an unsecured state so we  choose to enter the standard TLS negotiation
immediately on connect which means the server will wait for the client TLS/SSL
hello message. If the TLS negotiation fails the connection will be drooped, if
it succeeds then the Telnet protocol begins as in the first case with the
server enforced condition that encryption must have been negotiated to non-null
and if anonymous authentication was used then RFC 1416 authentication must
follow and succeed. If a Telnet client tries to access this secure only server
(port) without security  then the TLS negotiation will eventually fail causing
a disconnect but no useful information will be disclosed.

  The third category, a server that supports both unsecured and secure
connections presents an interesting set of possibilities.  One of the
acceptable arrangements is to have two ports, one that accepts only unsecure
connections and the other which accepts only secure connections. The second
optional arrangement we define here is a single server port which allows
unsecured or secure connections. It is optional because supporting this
configuration places a significant requirement on the Telnet server of ma
intaining network topology information so that it can enforce security policy.
This situation comes about when a TN server on an Intranet is exposed to the
Internet through a firewall  meaning that to enforce the need for only secure
connections to the extranet through a port that allows both the TN server must
be able to identify the origin of a connection as being outside the Intranet.
This duality of port shifts responsibility from the firewall gatekeepers to the
TN server administrator.

  For the case of the dual use port the Server will indicate a desire for
secure channel operation by sending the 3 byte Telnet command IAC WILL SECURE
(need to define this code point) in response to a connect. Following convention
old clients unaware of this option and aware clients not desiring a secure
channel will reject this offer using IAC WON'T SECURE. Aware clients desiring
a secure channel will initiate TLS/SSL negotiation by sending that protocols
"client hello" record (which has a beginning type byte value of 22
corresponding to SYN control code which is not specified to have meaning to the
basic NVT printer definition corresponding to the state of a Telnet connection
before negotiation of options).

 This definition minimizes code changes at both the client and server. On the
client side a slight adjustment to it's TLS/SSL record layer will allow the
received IAC WILL SECURE to be treated as a NOP content type and hence the
client will be able to treat a "secure only" and a "secure sometimes"
server port in the same fashion. On the server side, outside of enforcing the
security policy which duality brings, the server simply needs to be able to
recognize the first byte received from the client as a special control code
that signals the start of a TLS/SSL handshake message.

---------------------------------------------------------
John
[email-masked]@internet

supportin

---

From: [email-masked]
Date: Wed, 3 Dec 97 09:47:47 -0800

Defining a second port:

     Inline Negotiation:

     Joe
     [email-masked]

John Hind

supportin