Technical Report - SecureNetTerm

 

 

 

 

Search

Technical Report - SecureNetTerm

SecureNetTerm is a client/server application designed to interface with telnet, telnet-TLS/SSL,
rlogin, and SSH servers located on UNIX style hosts. Its foundation is derived from the product NetTerm, a highly popular telnet/rlogin client with an installed base worldwide. The primary purpose of NetTerm is to provide a Microsoft Windows based, highly stable, multiple terminal emulation environment using the telnet client server protocol. It is used to a lessor degree for rlogin and direct dial connections to host types such as bulletin boards. The client mix is libraries, universities, individuals and commercial users. 

The rapid growth of the Internet and the resulting potential for data abuse has lead to an increasing demand for secure electronic communication. The recent trend toward global consolidation of the business environment through purchases and mergers has also created a large demand on programs such as NetTerm to protect information from disclosure and to prevent unauthorized access to confidential data. In addition, many companies that deal with medical information of an individual are under increasing pressure to protect that data from unauthorized access/disclosure.

The classical form of authentication is to provide the host with a userid and a password transmitted in the clear. Once this was barely adequate, but modern technology has rendered this method as both foolish and dangerous. Session traffic has been transmitted in clear text, for all to see who has a desire to do so. For whatever reason, there are many on the Internet today that have the desire to not only intercept the data, but to change it.

SecureNetTerm builds upon the NetTerm product by adding secure authentication and encryption methods provided by publicly available open source software including Kerberos from MIT, SRP from Stanford University, OpenSSL and OpenSSH. In addition, SecureNetTerm adds the SSH protocol to the current telnet and rlogin protocols. This allows for a smooth transition from the current insecure telnet/rlogin protocols to the secure telnet and SSH protocols, protecting a companies investment in their installed base of client/server software packages. In most cases, the transition from an insecure telnet only environment to a secure TELNET/SSH environment can be made transparent with SecureNetTerm.

The design criteria of SecureNetTerm recognized that today's technology provides several methods of strong authentication as well as strong encryption ciphers. The primary goal was to allow a company and or individual to select the method which best served their needs, and protects their investment in user training and their installed base of server software. In addition, the decision to migrate from one type of authentication/encryption should be as transparent to the end user as possible. Recent news articles of attacks on several popular authentication methods validate this philosophy.

The decision to use authentication/encryption methods publicly available is based upon the philosophy that these methods should be made available for review and testing by experts worldwide to ensure their performance and test their claims of confidentiality. In addition, it allows for professional, high quality products such as SecureNetTerm to be made available and supported at reasonable prices. When evaluating a product such as SecureNetTerm, it should always be remembered that the primary function of this type of product is to provide a high quality, effective, user friendly interface to allow access to server based applications and data. Authentication and encryption , although highly important, assumes a subordinate role much like the operating system and communication methods.

The TCP based communication protocols supported by SecureNetTerm are:

  • SSH-1
  • SSH-2
  • Telnet
  • Telnet with PKI-based authentication via TLS handshake
  • Telnet witn non-PKI authentication via TLS handshake

The authentication methods supported by SecureNetTerm are as follows:

  • SRP
  • Kerberos 4
  • Kerberos 5
  • Plain Password
  • Encrypted Password
  • Microsoft NT/2000 NTLM
  • RSA public/private key
  • DSA public/private key
  • Rhosts/Rhosts with RSA public/private key
  • Challenge/Response methods such as S/Key and OPIE
  • PKI-based authentication via SSL/TLS handshake
  • Non-PKI based authentication via SSL/TLS handshake
  • SecurID

The supported ciphers are as follows:

Cipher

Key Size

DES

56

3DES

192

CAST

128

Twofish

128

Blowfish

128

RIJNDAEL

256

Cipher Remarks:

  • The RIJNDAEL cipher is also referred to as AES (Advanced Encryption Standard) cipher.
  • The key length can be less than shown above if requested by the host.

TLS Ciphers (See Appendix I)

The supported MAC digest algorithms are:

  • MD5 MD5 hash function
  • SHA SHA hash function
  • SHA1 SHA1 hash function

The supported SSL/TLS cipher encoding algorithms (Au) are:

  • eNULL No authentication
  • aRSA RSA authentication
  • aDSS DSS authentication
  • aDH Diffie-Hellman authentication

The supported SSL/TLS key exchange algorithms (Kx) are:

  • kRSA RSA key exchange
  • kDHr Diffie-Hellman key exchange (key from RSA certificate)
  • kDHd Diffie-Hellman key exchange (key from DSA certificate)
  • kEDH Ephemeral Diffie-Hellman key exchange (temporary key)

In addition to the above ciphers, both Kerberos 4 and Kerberos 5 include 56 bit DES for internal authentication support only. The version of DES used by Kerberos is provided as a part of the Kerberos authentication logic and cannot be accessed by the end user.

The type of authentication/encryption selected by SecureNetTerm is dependent upon the protocol used. If SecureNetTerm is used to connect to a host using the telnet protocol, selection is based upon standard telnet protocol specifications for both authentication and encryption. The host telnet server offers both an authentication and encryption method(s). If SecureNetTerm supports one of the offered authentication/encryption methods, the method used for authentication, and then encryption is negotiated between SecureNetTerm and the host telnet server program. The negotiated authentication/encryption method cannot be controlled by the end user. A host can also support multiple telnet servers offering different authentication/encryption methods.  For example, a host may have a Kerberos based authentication telnet server assigned to listen to port 23 and a SRP based authentication telnet server assigned to listen to port 27.

SecureNetTerm currently supports Kerberos 4, Kerberos 5, SRP, plain password, and the Microsoft NT/2000 NTLM authentication methods when used with the telnet protocol.

Session traffic for Kerberos 4, Kerberos 5, and SRP is provided by 56 bit DES, 128 bit CAST and 40 bit CAST, supplied by the OpenSSL library. The selection of the session cipher is determined by mutual agreement between the host telnet server and SecureNetTerm, however the end user cannot control which is selected. The logic within SecureNetTerm offers 128 bit CAST as the preferred cipher, followed by 56 bit DES then by 40 bit CAST. Encryption is not currently supported by any known telnet server using the Microsoft NTLM authentication method.

SecureNetTerm also supports a telnet server that conforms to the proposed IETF (Internet Engineering Task Force) draft ietf -tn3270e-telnet-tls specification for TLS-based telnet security. In addition to the authentication/ciphers specified above, a TLS -based telnet server supports three categories of cipher suites supported by TLS: ciphers supporting the X.509 certificates (PKI),  non-PKI ciphers, and anonymous ciphers. Both client and server certificates are supported. Anonymous ciphers can include any of the ciphers specified above. When authentication is performed using an anonymous cipher, SecureNetTerm does a verification of the TLS finished messages to protect against man in the middle attacks. Session traffic can also be optionally compressed prior to encryption by the standard zlib library software algorithms created by Jean-loup Gailly and Mark Adler. SecureNetTerm conforms to the following when used with telnet:

  • RFC-2712
  • RFC-2944
  • RFC-2945
  • INTERNET-DRAFT draft-ietf-tn3270e-telnet-tls-04

If SecureNetTerm is used to communicate using the SSH protocol, the types of authentication/encryption methods available is largely determined by the level of the SSH protocol supported by the host SSH server. The largest installed base of SSH servers is based upon the SSH-1 protocol, however the popular OpenSSH server is rapidly replacing the older SSH-1 based servers and it supports both the SSH-1 and SSH-2 protocol specifications. SecureNetTerm supports both the SSH-1 and SSH-2 specifications, and both can be selected by the end user. As with the telnet protocol, the authentication/encryption method is determined by mutual agreement between the host SSH server and SecureNetTerm. The major difference between telnet and SSH is both the authentication and encryption methods can be selected by the user from a list of methods supported by the protocol level, the SSH server and SecureNetTerm. Currently SecureNetTerm supports the RSA public/private key, encrypted password, Kerberos 4, Rhosts, Rhosts with RSA and challenge/response authentication methods when used with a SSH-1 server. The available encryption methods for SSH-1 are 3DES and Blowfish. When used with the SSH-2 protocol, SecureNetTerm supports the RSA, DSA public/private key, challenge/response, and encrypted password authentication methods with the 3DES, Blowfish, Twofish, ARCFOUR, CAST and RIJNDAEL ciphers.

Although SecureNetTerm does provide the necessary user interface for the Challenge/Response methods such as SecurID, S/Key and OPIE, it does not contain the software algorithms. The user must provide these as independent Windows based programs. SecureNetTerm simply presents the challenge to the user, and passes the third party software algorithm response back to the host. The Challenge/Response methods are only used for authentication.

The authentication and cipher support is provided by closed Windows based dll's, and the internal software interface is not available for modification by the user or the general public. The OpenSSL library (containing all the ciphers) is compiled within the OpenSSH dll, and is transparent and unavailable to the user. The cipher and authentication methods can only be selected by the closed user interface. In addition, the OpenSSH dll, including the OpenSSL cipher support library, is compressed with proprietary compression algorithms unknown to the general public. Session traffic for the SSH protocol can also be optionally compressed prior to encryption by the standard zlib library software algorithms created by Jean-loup Gailly and Mark Adler.

Although the support for all the most popular authentication/encryption methods may seem to present a somewhat complex challenge for use, in reality it is really quite simple and in most cases completely transparent to the user. For example, if a company has decided that it will base its secure communications upon the SRP authentication model and corresponding encryption methods, all it would do is install the SRP telnet server on their host, replacing the current telnet server. To the end users using SecureNetTerm, everything is transparent. They would still connect to the same host, and at the same port. The same would hold true for the Microsoft NTLM and Kerberos 4/5 authentication models based upon the telnet protocol. If one or both of the SSH models is chosen, then a few user choices may have to be made, but in most cases the design philosophy of  NetTerm can still be used. That is, a central support staff can determine what changes need to be made to the NetTerm control file. The control file can then be distributed to the end users of SecureNetTerm for production use. If a decision is made at a later date to change the authentication and or encryption method, the SecureNetTerm Security Wizard can be used to select the new choices. Migration is also quite simple, just replace the current NetTerm product with SecureNetTerm on each workstation or if NetTerm is deployed from a server, simply replace NetTerm on the server. All of the features/abilities of NetTerm are present within SecureNetTerm. The only difference is SecureNetTerm has the additional support for secure authentication/encryption.

From a design point of view, selection of the authentication/encryption method is by:

  • Connect to the specified host, at the port specified.
  • Determine if the host server is telnet based or SSH based.
  • If the host server is of the SSH type, determine encryption method.
  • Determine what method of authentication is to be used.
  • Inform the host server of the userid requesting access.
  • Formulate the authentication response based upon item d.
  • Receive positive authentication acceptance, if negative disconnect.
  • Determine what method of encryption is to be used, if not already known.
  • If SSH, determine if session data should be compressed prior to encryption.
  • If SSH, determine what type of message integrity logic should be used.
  • Proceed with session traffic.

If a negative or unknown response is received from the host server as a result of any of the above steps, SecureNetTerm will immediately disconnect, and depending upon the timing of the negative response, will immediately exit and destroy all internal buffer contents.

Source code for the Open Source software is publicly available from the following:

SRP

http://srp.stanford.edu/

OpenSSH

http://www.openssh.com

OpenSSL

http://www.openssl.org

Kerberos 4/5

http://web.mit.edu/kerberos/www/index.html

Since the Open Source software is in most cases designed for the UNIX environment, changes had to be made in some cases to conform and adhere to the Microsoft Windows requirements, comply with United States export requirements and patent laws and to be integrated into the SecureNetTerm Windows user interface. The magnitude of the required changes vary with the package, from absolutely none in the case of OpenSSL, few in the case of Kerberos 4/5 and SRP to somewhat complex in the case of OpenSSH. Since OpenSSH operates very near the operating system level, that should not be surprising. In fact, even in the UNIX environment there are two different distributions, one for BSD based systems and one for all others (deemed portable, at least with other UNIX based systems).

Appendix I

TLS/SSL Ciphers00

TLS/SSL Cipher Description

Level

Kx

Au

Enc

Key Size

Mac

RC4-SHA

SSLv3

RSA

RSA

ARCFOUR

128

SHA1

RC4-MD5

SSLv3

RSA

RSA

ARCFOUR

128

MD5

RC4-MD5

SSLv2

RSA

RSA

ARCFOUR

128

MD5

RC4-64-MD5

SSLv2

RSA

RSA

ARCFOUR

64

MD5

ADH-RC5-MD5

SSLv3

DH

-

ARCFOUR

128

MD5

ADH-DES-CBC-SHA

SSLv3

DH

-

DES

56

SHA1

ADH-DES-CBC3-SHA

SSLv3

DH

-

3DES

168

SHA1

DHE-DSS-RC4-SHA

SSLv3

DH

DSS

ARCFOUR

128

SHA1

DES-CBC-SHA

SSLv3

RSA

RSA

DES

56

SHA1

DES-CBC3-SHA

SSLv3

RSA

RSA

3DES

168

SHA1

DES-CBC-MD5

SSLv2

RSA

RSA

DES

56

MD5

DES-CBC3-MD5

SSLv2

RSA

RSA

3DES

168

MD5

KRB5-DES-CBC-SHA

SSLv3

KRB5

KRB5

DES

56

SHA1

KRB5-DES-CBC-MD5

SSLv3

KRB5

KRB5

DES

56

MD5

KRB5-DES-CBC3-SHA

SSLv3

KRB5

KRB5

3DES

168

SHA1

KRB5-DES-CBC3-MD5

SSLv3

KRB5

KRB5

3DES

168

MD5

EDH-RSA-DES-CBC-SHA

SSLv3

DH

RSA

DES

56

SHA1

EDH-DSS-DES-CBC-MD5

SSLv3

DH

DSS

DES

56

MD5

EDH-RSA-DES-CBC3-SHA

SSLv3

DH

RSA

3DES

168

SHA1

EDH-DSS-DES-CBC3-SHA

SSLv3

DH

DSS

3DES

168

SHA1

EXP-RC4-MD5

SSLv2

RSA

RSA

ARCFOUR

40

MD5

EXP-RC4-MD5

SSLv3

RSA

RSA

ARCFOUR

40

MD5

EXP-ADH-RC4-MD5

SSLv3

DH

-

ARCFOUR

40

MD5

EXP-ADH-DES-CBC-SHA

SSLv3

DH

-

DES

40

SHA1

EXP-EDH-RSA-DES-CBC-SHA

SSLv3

DH

RSA

DES

40

SHA1

EXP-KRB5-DES-CBC-SHA

SSLv3

KRB5

KRB5

DES

40

SHA1

EXP-KRB5-DES-CBC-MD5

SSLv3

KRB5

KRB5

DES

40

MD5

EXP-EDH-DSS-DES-CBC-SHA

SSLv3

DH

DSS

DES

40

SHA1

EXP-DES-CBC-SHA

SSLv3

RSA

RSA

DES

40

SHA1

EXP-RC4-MD5

SSLv3

RSA*

RSA

ARCFOUR

56

MD5

EXP-RC4-SHA

SSLv3

RSA*

RSA

ARCFOUR

56

SHA1

EXP-DES-CBC-SHA

SSLv3

RSA*

RSA

DES

56

SHA1

EXP-DHE-DSS-RC4-SHA

SSLv3

DH*

DSS

ARCFOUR

56

SHA1

EXP-DHE-DSS-DES-CBC-SHA

SSLv3

DH*

DSS

DES

56

SHA1


 RC4 – ARCFOUR encryption
 EXP – Export Classification
 * - 1024 key exchange (Kx) bit key

Back Top Next

HOME PAGE   SITE MAP   CONTACT US   AWARDS   DOWNLOADS   WHAT'S NEW   SECURE ONLINE ORDERING  

Designed and Maintained by BHS Digital - Optimized for Mozilla Firefox and Microsoft Internet Explorer
For additional information please contact our Sales Department or call 1.888.823.1541
© Copyright 2014, InterSoft International, Inc.  All Rights Reserved.