SECURITY is the hot topic on the Internet. Security
systems and protocols abound. But it was not always so. In the early days,
the mere act of putting two computers in touch with each other was quite
amazing. To connect multiple diverse computers to a common network, allowing
any pair of them to communicate, was almost inconceivable. When the
ARPANET (precursor of the Internet) was first
operational on October 1, 1969, the eager task for many years afterwards was
to open up more and more sites to it. The architecture of the network and its
protocols were developed in research laboratories in an atmosphere of trust.

Only later, when the ARPANET became the world-wide Internet and was opened up
to limitless numbers of people, did security become an issue: hackers,
crackers, script kiddies, terrorists, spies, hucksters, swindlers,
pornographers, saboteurs, blackmailers, pranksters, and pests of every sort
inundate the network and every computer on it with a constant barrage of
probes and attacks. It is increasingly necessary to secure connections from
eavesdropping and malicious tampering (not to mention spam, worms, viruses,
and denial-of-service attacks, but that's
another
story).

The network itself is not secure. By its very nature and
fundamental design, it is entirely open*. While
it might be possible to insert security at the transport and/or network
layers, transparent to all applications, the approach until now has been to
layer security protocols over TCP and IP: some of them standard, some not so
standard. Even among the standard ones, there are many to choose from. This
approach requires one or more security methods to be programmed into each and
every client and server application that is to make or accept secure Internet
connections. The situation should improve in the future as security becomes
part of the network itself through evolving standards such as
IPSec,
IPv6, and
DNSSEC.

Meanwhile, insecure connections remain the norm, in which
passwords, credit-card information, private correspondence, and so on can be
captured and/or altered in transit by malicious persons. Security remains
elusive because we have a 30+ year history of open networks, clients, and
servers, and because of the many competing security methods, the shifting
definitions of each one, various legal entanglements, and the overall
complexity of the entire topic.

Why should I care about security?
The reasons are obvious: to prevent fraud on your person, theft of your money
or identity, hijacking of your computer accounts, tampering with your research
results; any number of malicious acts aimed at you or performed by someone
masquerading as you. Perhaps an even more compelling reason to care is
that more and more sites are requiring secure clients for access:
plain old dialup or insecure Telnet or FTP simply can't be used any more.

Authentication of the user to the host/service without the
transmission of the user's password;

Authentication of the host to the user;

Privacy, through a shared secret that can be used as an
end-to-end encryption key; and:

Integrity: the assurance that the data has not been altered in
transit.

A secure connection requires two applications, one on each end, that support
(and can negotiate) a common security method; for example, a Telnet client on
your desktop and a Telnet server at the remote site, both equipped with
Kerberos V protocols.

Kermit software supports a variety of connection methods, including serial
ports, modems, and TCP/IP. Presently, secure connections are supported
only over TCP/IP connections. Since there are many security protocols to
consider (Kerberos, SRP, TLS, ...) and several TCP/IP application
protocols where they can be used (Telnet, SSH, FTP, HTTP, ...), and
different platforms for the clients and servers (Unix, VMS, Windows, OS/2,
...), the possibilities are many.

To complicate matters, every Kermit program can come with or without
security. Non-secure versions are required by USA export law. Secure
versions can be built with any combination of the security methods listed
above: Kerberos IV but not Kerberos V, SRP and SSL/TLS but not Kerberos, etc.
Kermit 95 has either no security methods built in or else all of them.
C-Kermit on Unix can have any combination, depending on the libraries
available on each platform and which ones were selected by the builder.

Let's begin by looking at the Internet protocols that Kermit supports
to see which security options are available for each:

TELNET (Network Virtual Terminal Protocol)

The Telnet protocol can be used to establish the most secure connections
with a large choice of authentication and privacy methods. Kermit's
Telnet implementation supports Kerberos 4, Kerberos 5, Secure Remote Password
(SRP), NTLM (K95 only), and X.509 certificates for client
and server authentication. Privacy can be accomplished with the Secure
Sockets Layer (SSL) or Transport Layer Security (TLS) cipher suites, or DES,
CAST, or 3DES streaming ciphers.

SSH (Secure Shell and Port Forwarding Protocol)

The SSH protocols (versions 1 and 2) can be used to establish secure
connections with a wide choice of authentication methods. Kermit's SSH
implementation supports Kerberos 4, Kerberos 5, Secure Remote Password (SRP),
and Public Keys for client and server authentication. Privacy is integrated
into the protocol through the use of secure public key or GSSAPI based key
exchange coupled with strong cipher suites.

Both SSH and GSSAPI have changed somewhat since K95 2.1.3 were released.
K95 2.1.3 can still be used as an SSH client, but it can't authenticate
with GSSAPI. Also, the SSH compression method has changed, so in most
cases it is necessary to tell K95 to SET SSH COMPRESSION OFF prior to
making an SSH connection. Since this command should always be in effect,
it should be put in the K95 initialization or customization file so it
will be executed automatically each time you start K95.

FTP (File Transfer Protocol)

An FTP client can make secure connections for both the command and
data channels as described in Internet
RFC 2228. Kermit's FTP
implementation supports Kerberos 4, GSSAPI Kerberos 5, SRP, and SSL/TLS.

HTTP (Hyper Text Transfer Protocol)

HTTP can be used with SSL or TLS to submit requests and receive responses
in a secure manner as described in
RFC 2818.

RLOGIN (Remote Login)

The Remote Login protocol can be used with Kerberos 4 or 5 to make
authenticated connections. After authentication the DES streaming cipher can
be used for privacy.

SSL (Secure Socket Layer) / TLS (Transport Layer Security

The SSL and TLS protocols can be used by themselves to establish a private
connection to a host. Authentication of the server (and perhaps the client)
is performed via exchange and verification of X.509
certificates or Kerberos 5 credentials. Kermit also can make Telnet
connections over a secure SSL or TLS tunnel.

Kerberos 5 User-to-User

The Kerberos 5 user-to-user protocol can make authenticated and private
connections between two end-user operated copies of Kermit.

The table below summarizes which security methods Kermit can support
for each Internet service if those security methods are built in to
Kermit. If your copy of Kermit supports a particular security method for a
particular service, you can use it if the server supports the same method.
You see out which security methods your Kermit program supports by giving
it the SHOW FEATURES command.

Protocol

Krb4

Krb5

SSL/TLS

SRP

SSH

NTLM

Telnet

Yes

Yes

Yes

Yes

Yes

K95

Rlogin

Yes

Yes

No

No

No

No

SSL/TLS

No

Yes

n/a

No

No

No

K5 User-User

No

Yes

No

No

No

No

FTP

Yes

Yes

Yes

Yes

No

No

HTTP

No

No

Yes

No

No

No

Kermit

Yes

Yes

Yes

Yes

No1

K95

SSH

No

Yes

No

Yes

n/a

No

Of course you can use Kermit protocol over SSH connections, and you
can even install C-Kermit as a file-transfer and -management service under
sshd, but Kermit itself does not yet accept incoming SSH connections.

AUTHENTICATION is the means by which one party proves its identity to to
another. The most common authentication method is the familiar process of
logging in with a username and password. When you do this on an insecure
network connection, your identity and password are transmitted in clear text
and can be "sniffed" by anybody who has access to any of the components of the
network path; for example, by anybody who has a PC on a (non-switched)
Ethernet network over which your information passes.

Furthermore, when you make (say) a Telnet connection to a network, you accept
the fact the you must authenticate yourself to it, but how do you know that
the host itself is genuine? In the normal course of events, there is no
requirement that it authenticate itself to you.

Enter secure authentication. Any secure authentication scheme requires
central management of identities, as in the Kerberos authentication system
(Section 1.3.1), X.509 certificates
(Appendix III), or Secure Remote Password
(Section 1.3.2). This type of security is best suited for
large organizations -- universities, government agencies, corporations,
hospitals -- that have a full-time professional network / security
administration staff. The learning curve and startup time are significant,
but worth the effort. Any security method can be breached, so the true
measure of its effectiveness is its manageability: can breaches be repaired,
can compromised identities be reclaimed?
It is for these reasons that Microsoft, Sun, Apple, HP, IBM, and many Linux or
BSD vendors are increasingly distributing Kerberos 5 as a core part of their
operating systems.

Unfortunately, the startup costs of a secure authentication system are
sometimes so daunting that some organizations simply don't bother, and instead
let users fend for themselves with unsigned public/private key pair schemes,
such as SSH public key authentication (Section 1.3.5)
and PGP. The only administrative tasks required up front are the installation
and/or distribution of the required client and server software. This is not a
secure authentication system; quite the opposite: it bypasses any
secure authentication / authorization system that might be in place. And
keys, once compromised, can not be revoked by those responsible for the
security of the host: a serious consideration since so many security keys are
stored on insecure disks (e.g. in Windows 9x/ME) ripe for picking.

Kerberos is a method, developed at Massachusetts Institute of Technology
(MIT), by which two parties communicating over a TCP/IP connection can
authenticate each other through a trusted, centrally managed third
party without sending passwords across the network. The Kerberos protocols
are defined in Internet RFCs
1510,
1964, and others.
You can read more about Kerberos at the following websites:

There are, in fact, two Kerberos protocols: Kerberos IV (4) and Kerberos V
(5), the latter being the more flexible and secure protocol. The two are
totally separate and incompatible. Any given site might support neither,
either one, or both. One of the unique benefits associated with the use
of Kerberos 5 authentication is its Single Sign-On (SSO) capability. This
allows a user to enter their password once on the local machine, establish a
secure connection to a second machine and from there establish additional
connections without requiring the user to enter their password a second time.

When both the client and server support the same version of Kerberos (4 or 5),
Kerberos authentication with or without encryption can be negotiated. A
"Kerberized" version of Kermit can make a connection to a non-Kerberized host,
and a non-Kerberized host can accept a connection from a Kerberized version of
Kermit, as long as neither side is configured to require Kerberos
authentication.

Kerberos authentication has been integrated into Telnet, Rlogin, FTP, and
SSL/TLS as well as many other protocols not supported by Kermit. As part of
the authentication process a session key is shared by the client and server
that can be used to encrypt the current session.

Stanford University's Secure Remote Password (SRP) protocol is a method by
which two parties can mutually authenticate each other in a secure manner
through a Zero Knowledge Identification system. SRP is defined in Internet
RFC 2945. You can read
more about SRP at the following website:

SRP authentication has been integrated into the Telnet and FTP protocol
definitions (if not yet into all Telnet and FTP clients and servers). As a
result of the authentication, a shared secret is produced that can be used to
encrypt the authenticated session.

Microsoft NT Lan Manager (NTLM) authentication is implemented in Kermit 95
only. Its only use is to authenticate Kermit 95 to Microsoft Windows based
Telnet services distributed as part of Windows 2000, Windows XP Professional,
and the NT Services for Unix products. Kermit 95 can also use NTLM to
authenticate incoming Telnet sessions when it is running under Windows
NT/2000/XP. When running under Windows 95/98/98SE/ME, Kermit 95 can only be
an authenticating client.

NTLM does not negotiate a shared secret and cannot be used to establish
encrypted sessions. Therefore, connections made with NTLM are not considered
secure although it is definitely better to use NTLM authentication than it is
to transmit a password in clear text. NTLM is a proprietary protocol
considered to be a trade secret by Microsoft. When establishing connections
with another Kermit 95 configured to accept incoming connections, Kermit 95
can negotiate NTLM over a SSL/TLS session. Security is then provided by
SSL/TLS while authentication is performed with NTLM.

When SSL/TLS is used to provide security, authentication of the server and
optionally the client can be performed using X.509 Public Key
Certificates. Certificates are used to exchange a public key for use in
establishing an encrypted connection and can be verified against a known
trusted Root Certificate and a Certificate Revocation List (CRL) to indicate
its authenticity and validity. The contents of the certificate can then be
used to determine the identity of the remote service or the client.

C-Kermit and Kermit 95 provide mechanisms for the customization of the
certificate to userid mapping.

Several distributed security protocols including SSH rely on a loosely
managed form of authentication based on the same asymmetric cryptography used
within X.509 Public Key Certificates. The technique is to
generate a public and private key pair and give the public key away as
a means of authenticating the holder of the private key. The prime
difference between this and an X.509 certificate is that the public key
is not bound to any information providing the identity of the holder
nor does it contain any information that can be used to limit the lifetime
of the public key or sources of information that can be used to determine
if the public key has been compromised or revoked for some other reason.

Several application protocols such as Rlogin and SSH support some form of
host-based authentication. In these protocols the identity of the host (not
the user) is used to determine whether the connection is to be trusted. In
Rlogin the host-based authenticator is the IP address or DNS host name, both
of which are insecure indicators of identity. SSH uses the host-assigned
Public Key pair as the host-based authenticator.

Host-based authentication is almost always used to allow system processes
which are not associated with a specific user to establish connections. This
is often done to allow the secure distribution of system configuration files
to clusters of related systems.

Passwords, Passphrases, and so called Keyboard Interactive authentication
methods are the old-fashioned traditional means of proving end-user identity.
These methods are still in use with secure connections whether they be Telnet,
FTP, or even SSH. They become safer to use when the connection is protected
by some form of encrypting cipher suite. However, it should never be assumed
that the transmission of a password to a host is safe. The host daemon process
could have been replaced by one that collects and transmits passwords to an
attacker. There have even been passive attacks that observe the timings of
transmissions between the client and the host that have enabled the attacker
to determine the password based upon the time it takes to type keys on a QWERTY
keyboard.

ENCRYPTION is the process by which data is encoded to prevent anybody from
deciphering it except those for whom it is intended. Encryption is an
essential component of Internet security because of the Internet's open
architecture; since (in principal) everybody can watch your sessions, you
have to scramble them to keep them private.

A variety of encryption methods, or algorithms, exists ranging from
easy to crack to next-to-impossible (but not truly impossible: if the
data can be decrypted legitimately, it can also be decrypted illegitimately
given adequate resources). Most modern encryption/decryption algorithms use
keys as part of the process, either provided by the user or obtained
automatically from a shared secret. For any given algorithm, the longer the
key the more secure the encryption.

Each application protocol such as Telnet, FTP and HTTP defines its own set of
protocols for encrypting a session based on the authentication method.

The following encryption algorithms can be negotiated for a Telnet session
with the Telnet Encryption Option
(RFC 2946) when used
with Kerberos IV, Kerberos V, or Secure Remote Password authentication:

Kerberos V is supported within the GSS-API framework that negotiates
the encryption algorithm at run-time. The negotiated encryption algorithm
depends on the implementation of GSSAPI available to Kermit. MIT Kerberos
supports ciphers based on 3DES, RC4, and DES.

Secure Remote Password authentication may be used with CAST-128, 3DES,
DES, and Blowfish as encryption algorithms. The selected algorithm is
user configurable.

SSL/TLS provides an extensive list of cipher suites for use protecting
session data.

Netscape's Secure Sockets Layer (SSL) and its IETF-approved successor,
Transport Layer Security (TLS), provide for authentication and encryption of
TCP/IP communications using a combination of public key and symmetric
cryptographic algorithms. TLS is defined in Internet
RFC 2246. Traditional
authentication of the server (and optionally the client) is performed by
exchanging ITU-T X.509 certificate chains (see Appendix 3),
that are verified by the receiver. Unlike raw public keys, X.509
certificates may be revoked by issuing a certificate revocation list (CRL)
that is to be checked by the receiver during verification of the certificate
chain.

Kerberos 5 credentials can be used as an alternative method for performing
mutual authentication within SSL/TLS sessions
(RFC 2712).

The encryption provided by SSL/TLS is more secure than the encryption
negotiated by the Telnet Encryption Option. This additional security is
provided by a combination of the use of longer encryption keys, the
availability of stronger symmetric cryptographic algorithms, and the signing
of each transmitted block with a message-digest algorithm.

A sample list of cipher suites from OpenSSL 0.9.7 as shipped with Kermit 95
includes:

TLS can be used with Telnet Authentication methods such as Kerberos, Secure
Remote Password, and NTLM to provide the highest level of data privacy with
the strongest forms of mutual authentication when TLS in-band authentication
is not performed.

There are two different versions of the SSH protocol: version 1 and version 2.
The cryptographic strengths of the protocols are very different. Whenever
possible SSH version 2 should be used.

SSH version 1 implements an encryption scheme that may be open to advanced
theoretical attacks. The encryption algorithms supported for this protocol
by Kermit include DES, BLOWFISH, and 3DES.

SSH version 2 implements the most advanced techniques known to the
cryptographic community. Of all the security protocols in use on the
Internet, SSH version 2 is the youngest and therefore has had the most
flexibility in implementing changes as new cryptographic attacks have been
discovered. The SSH version 2 ciphers supported by Kermit include 3DES, AES,
BLOWFISH, RC4, and CAST-128.

Secure Login connections are established by using a modified version of the
Rlogin protocol which replaces host-based authentication with a Kerberos 4 or
Kerberos 5 authentication handshake. This authentication results in the
sharing of a session key for use in encrypting the transmitted data. Kerberos
4 is limited to the exchange of DES keys whereas Kerberos 5 can exchange keys
for 3DES, RC4, and DES.

Certain security protocols including SSL/TLS, FTP SRP, FTP GSSAPI-Kerberos 5,
Kerberos 5 User-to-User, and SSH not only encrypt network data streams, but
also ensure that they have not been tampered with along the way. The
integrity algorithms are most often MD4, MD5, or SHA-1.

The statements made with regard to US export law reflect our understanding of
the situation at this writing, which might change subsequently. We expect to
update this document, and our website in general, in light of any new
developments.

Current US law forbids export of strong encryption software in binary form
from the USA to all countries except Canada without a license or license
exception. Thus the Kermit Project does not distribute pre-compiled secure
versions of C-Kermit on the Internet.

Security within Kermit is provided using the underlying services of
third-party libraries, such as Kerberos or OpenSSL. These libraries are not
necessarily included with Kermit (they are with the secure version of Kermit
95, but not with C-Kermit). If not, they must be obtained separately from the
sources listed below, in compliance with the terms and conditions given at
those sites and with United States and international law. For an overview of
this issue, see (for example):

Kermit software, when combined with the security libraries listed in this
document, has been verified to negotiate and conduct authenticated and
encrypted sessions with Kerberos, SRP, and/or SSL/TLS services on Internet
hosts at Columbia University and other test sites, with Kermit features such
as interactive terminal access, file transfer, and scripting operating
successfully over secure connections, with any exceptions noted below.

The Kermit Project does not and can not claim or warrant the external
Kerberos, SRP, OpenSSL or other third-party modules to be free of loopholes or
bugs. Authentication via Kerberos, SRP, or X.509 certificates is not
unbreakable. Any encryption method can be broken. Any software that is used
for authentication or encryption should be analyzed for weaknesses, backdoors,
bugs, and loopholes by the site and/or end user before use.

The Kermit Project and Columbia University make no claim or warranty as to any
particular level of security achievable by Kermit software with
any third party security protocol, and may on no account be held liable for
any damage resulting from its use (a more complete statement to this effect is
found in the C-Kermit 8.0 license).

Functional limitations:

Kerberos authentication is available on Telnet, FTP, Rlogin,
and SSL/TLS secured connections.

Secure Remote Password authentication is available only on Telnet
and FTP connections.

NTLM authentication is available only on Windows 95/98/Me/NT/2000/XP and
only on Telnet connections.

SSL/TLS may be used as its own connection protocol or on Telnet, FTP, and
HTTP connections.

Kerberos support is not available in Kermit 95 for OS/2 due to lack
of Kerberos implementations for OS/2.

SSH is built in to the Windows version Kermit 95, but C-Kermit uses the
external ssh program.

Suppose you work at a company (or are a student or faculty member at a
university, or otherwised engaged in an organization of some sort) that has
secure services of the kind you can access with Kermit, such as terminal
sessions, file transfer, or website management. Before you can access the
services securely, you have to "tell" Kermit which authentication method to
use, along with any site-specific parameters, and you might also want to say
what should happen if the desired type of security can't be negotiated.

Bear in mind that you can use only those security methods that are offered
with the services you will be connecting to. You can't just pick any old
security method and expect it to work: it takes two to tango.

Kermit has all the commands you need to set up secure connections, and they
are the topic of this rather lengthy chapter. But don't worry: in most cases,
you'll have to deal with these commands only once, and possibly not at all:

If your organization has a site or bulk license
for Kermit 95, the network or software license administrators in your
organization should have set it all up for you in advance.

If you are setting up Kermit for your own use within an organization's
security framework, you'll need to get assistance from the network
administrators anyway, to find out the pertinent connection details.

In Kermit 95, there is a security form in the Dialer for
any secure connections you need to make: fill it once, use it forever.

In any case, once you have put together the commands you need, you can
add them to your Kermit customization file if you want them to be in effect
every time you start Kermit, or you can make separate scripts for each host
or organization and use them whenever needed.

Therefore, this chapter is more for the system or network or security
administrator than the typical end user. Given an organization that already
has a security infrastructure in place, this chapter explains the Kermit
commands necessary to use it. All the information should be here, but if you
have trouble finding what you need or putting the pieces together, feel free
to send us questions by
e-mail.

When making a Kerberized connection, you must first know which Kerberos
version, 4 or 5, is supported by the host or service you want to connect
to, and you must be registered in the Kerberos database at the host's
site. If you're unsure about any of this, contact your site administrator.

Before authentication to a specific service (such as Telnet) can succeed, you
must login to the site's Kerberos Ticket Granting Server. Depending on the
Kerberos implementation and installation options this might be done
automatically when you log in to your operating system. Otherwise you can
do it with external utilities from MIT (such as Leash, KRB5, or
kinit), or with Kermit's built-in functionality, explained in this chapter.

Once a Ticket Granting Ticket (TGT) is acquired, Kermit can use it to request
additional tickets for each host (service) you wish to connect to. These
service tickets can be used to authenticate you with the host automatically
during a specified time interval, after which the tickets expire. When
authentication is successful, you are logged in to the host without
having to supply a user ID or password.

Besides providing credentials for use during authentication, the service
ticket also contains a session key to be used for encrypting the session.
After the connection is authenticated, Kermit (if the necessary encryption
capabilities are available) attempts to negotiate bidirectional encryption.
If encryption is negotiated, it is used in one or both directions, depending
on what the server agrees to.

When Kerberos V authentication is used, Kermit supports credential forwarding
by transferring your Ticket Granting Tickets to the host that you are
connecting to, so you can make additional authenticated connections from that
host to any others that accept those tickets. This provides a single sign-on
capability to all the hosts and services within the Kerberos realm.

Kerberos 5 authentication is one of the few authentication methods that can
be used to provide verification of anonymous TLS connections. This is taken
advantage of in Telnet by negotiating AUTH KRB5 after establishing a private
connection with the START_TLS option.

Successful operation of Kerberos requires that all machines have their dates
and times synchronized. Be aware that PC clocks can drift, and this can
cause authentication failures. Kerberos requires that all clocks be
synchronized within 5 minutes.

SRP requires no special configuration of the client. When Kermit is used to
connect to a host that supports SRP, the user name is transmitted
automatically to the host and then a Password prompt is displayed in the
Kermit command screen. This indicates that the password will not be sent to
the host over the communication channel. Instead the password is used as part
of a negotiation in which authentication is either mutual or none at all.

The result of a mutual authentication is a shared secret used to generate two
different keys for encrypting the incoming and outgoing data.

SRP authentication is one of the few authentication methods that can
be used to provide verification of anonymous TLS connections. The Kermit
Telnet client takes advantage of this fact by by negotiating AUTH SRP after
establishing a private connection with the START_TLS option.

Microsoft's native authentication method is called (Windows) NT LAN Manager,
or NTLM. It is implemented in Windows 9x/ME and NT/2000/XP and requires no
configuration on the part of the user. When K95 is used on any Microsoft
Windows version, it can be used as an NTLM Telnet client to authenticate to
Microsoft's NT Services for Unix Telnet Server or to a K95 configured to
accept incoming connections.

When K95 is used on Windows NT/2000/XP it can be configured to accept incoming
connections and authenticate NTLM Telnet clients.

NTLM is a weak form of authentication. It provides no shared secret
and cannot be used as a means of securing a connection with encryption.

(Also see
Appendix III for an introduction to the concept of
certificates.)

Secure Sockets Layer Version 3 (SSLv3) and its successor Transport Layer
Security Version 1 (TLSv1)
(RFC 2246)
were originally developed for Web browsing. They provide a framework
for using public-key certificates or Kerberos 5 to negotiate server and
(optionally) client authentication and bidirectional encryption. The
encryption provided by SSLv3 and TLSv1 is stronger than that provided by the
Telnet Encryption option.

SSLv3 and TLSv1 connections may be negotiated in two different ways. First,
the connection may be SSL/TLS-only, which is used when connecting to HTTPS
services or SSL/TLS tunnels. SSL/TLS can also be negotiated after the
connection is established via negotiations performed in some other protocol
(such as Telnet START_TLS.) Kermit supports both methods:

In their most common use, SSL and TLS negotiations provide the client with
authentication of the host computer when the host's X.509 certificate is
verified or when Kerberos 5 is used. The client can be authenticated with an
X.509 certificate issued to the end user, or with Kerberos 5, or with one of
the supported Telnet authentication methods. Even though the data channel is
encrypted, the transmission of passwords to the host should still be avoided
to prevent theft by a compromised host.

If certificates are to be verified, the root certificates of the certificate
authorities (CAs) must be available. If you are not acting as your own CA you
need a file containing the root certificates that were used to sign the
certificates belonging to the servers you want to authenticate. A compilation
of most of the commercial Certificate Authority root certificates as extracted
from Microsoft Windows XP's certificate database is available at:

Once the file is downloaded, you can tell Kermit where it is with
the following command (Section 3.2.2.3):

SET AUTH SSL VERIFY-FILE path/ca_certs.pem

When Kermit is acting as an
Internet Kermit Service
daemon (IKSD), client certificates can be used for automatic login. If a
certificate-to-userid mapping function is provided, the IKSD logs the user in
automatically if the certificate is verified and the specified userid exists.
Kermit also supports the use of a ".tlslogin" file
that allows a certificate to be used to login automatically to an account
without a certificate-to-userid mapping function. When Kermit receives a
username via the Telnet New-Environment variable after it has received and
verified a client certificate, it looks in the home directory corresponding to
the username for a file called ".tlslogin". If the file contains the
certificate presented by the client, the client is logged in as the requested
user without a password. See Appendix III for
information on certificate to user mapping.

The method for negotiating Tim Hudson's Telnet AUTH SSL option is open to a
"man-in-the-middle" attack which is capable of disabling the use of SSL before
the negotiation is begun. It should be used only with:

SET TELNET AUTHENTICATION TYPE SSL
SET TELOPT AUTHENTICATION REQUIRED

When using IKSD with START_TLS you should create an /etc/iksd.conf
including Kermit commands that point to the certificate and key files:

If your server certificate was signed by an intermediary certificate
authority instead of a root, you must provide the full chain of intermediary
certificates for the client to be able to authenticate your
server. These certificates can be specified with:

The SSL and TLS handshake can be very time-consuming, and therefore Kermit can
cache your your SSL/TLS sessions. When Kermit is used with a peer that
supports cached sessions, subsequent connections to the same host can be
securely established in a fraction of the time necessary for the initial
connection. This is especially important for FTP and HTTP, which can make
many connections to the same host during during a typical session.

For a list of Telnet servers that support START_TLS see
Section I.1 of Appendix I. For a list
of FTP servers that support AUTH SSL and AUTH TLS see Section
I.2.

SSH provides security (or the illusion of it) by encrypting the session. SSH
can work in the absence of authentication, but it also offers several options
for authentication, none of them particularly secure except for Kerberos 5
GSSAPI and SRP.

In its simplest form, SSH lets the user make encrypted connections without
setting up any kind of keys or other special authentication procedures or
files, and all the host administrator has to do is install the ssh server and
generate host keys. No alteration of the host login system is required. This
is why SSH is so popular compared to authentication methods that are more
secure and manageable: it's easy to get started. However, this kind of SSH
connection does not authenticate the host to the client and it authenticates
the client to the host only through the password file, just like an ordinary
insecure login. The only difference is that the session (including the
password) is encrypted, which makes hackers do a little extra work to decode
their sniffer logs and get your password. The assumption is that hackers
won't bother to do this since unencrypted passwords are easier to steal (like
cars without steering-wheel locks), but of course this is wishful thinking.

The most important command to know about before you try to make an SSH
connection is SET SSH STRICT-HOST-KEY-CHECK. The values are ON, OFF, and ASK.

ON means K95 won't make an SSH connection to a host whose public key
is not in its known-hosts file.

OFF means K95 will connect to any SSH host.

ASK means K95 will ask you if it's OK to connect to a host whose
key is not in its known-hosts file. This is the default.

There are two known-hosts files for each protocol version. A user
file is stored in the \v(appdata)ssh directory and is
automatically updated based upon the connections you make. The
system-wide known-host file is (optionally) stored in the
\v(common)ssh directory for the operating system and is never
updated by Kermit 95. It is there to be maintained by the system
administrator.

Your global known-hosts files are kept in a directory common to all users:

(\v(appdata) is Kermit's User Application Data Directory
variable. The user's application data directory is located in a
system dependent manner. Windows 95/98/98SE/ME/NT store the application
data with the user's profile. Windows 2000/XP store the application
data in the Documents and Settings directory.
Tell K95 to "show var appdata" to see its definition.) Thus, on Windows XP
these files are in the SSH subdirectory of your Windows APPDATA directory, e.g.:

(\v(common) is Kermit's Common Data Directory
variable. The common data directory is located in a
system dependent manner. Windows 95/98/98SE/ME/NT store the common application
data in the WINDOWS directory. Windows 2000/XP stores the application
data in the Documents and Settings\All Users directory.
Tell K95 to "show var common" to see its definition.)

Each file contains a series of (long) "lines", one per host, each line
containing the hostname and aliases and then the key in Base 64; this is the
host's public key. Adding a host key means appending such a line to the
appropriate file.

SSH STRICT-HOST-KEY-CHECK ON gives you some assurance that the host you have
connected to is the one you meant to connect to. But it also means your first
connection to a particular host is likely to be refused. It's the classic
chicken-and-egg situation. You're supposed to get host keys from a trusted
source such as a disk or CDROM from your host administrators, but if you
didn't, how do you get a key when it's on the very host you can't connect to
because you don't have its key? The possibilities include:

You can make some other kind of trusted connection to it (e.g. with
Kerberos 5 Telnet) and download the key, or:

You can tell K95 to:

SET SSH STRICT-HOST-KEY-CHECK OFF (or ASK)

and then make an SSH connection to the host, authenticate with your
password, and then the host key is automatically retrieved and added to
your known-hosts file, and then future connections to that host can be made
with SSH STRICT-HOST-KEY-CHECK ON. But of course since you have bypassed
the host authentication process to obtain the key, future authentication
using this key is worthless and you might as well not have have bothered.

You might wonder if keeping host keys is a good idea. The advantage is the
protection they offer against man-in-the-middle attacks and DNS spoofing (but
not compromised hosts). The disadvantage is that anybody who can access your
host keys (legitimately or not) knows which hosts you access, which in itself
might be information you'd rather not reveal, but also tells hackers which
hosts to attack in your name. As noted, Kermit 95 (like all other SSH
clients) appends new host keys to your user host-key file(s). You can delete
these files if you wish; for example, in your K95 ON_EXIT macro definition.

Independent of how the host is authenticated to K95, is the method by which
K95 authenticates you to the host:

Password

Public/Private Key Pair

The default method of client authentication (that is, the method that is
used unless you have configured K95 to use any of the other methods described
below) is by prompting you locally for a password and then sending it
(encrypted) to the server. This method requires you to type your password
every time you log in (unlike, say, Kerberos 5, which gives you a "single
network login").

If you must use SSH to contact a particular host, we recommend simple
password authentication. If this is OK with you, skip the
rest of this section; otherwise keep reading.

You can also use public/private key pairs, whose purpose is to allow
you to log in to the host without typing your password. THIS IS
DANGEROUS because your keys are stored on your Windows disk, where they can be
stolen (especially easy on Windows 9x/ME PCs that are attached to the network,
yet lack any form of file-system security). If your key files are encrypted,
they can be decrypted offline. (The longer the passphrase for key-file
encryption, the longer it takes to perform dictionary attacks against it; a
40-character character passphrase should be considered a minimum but
most people don't use such a long passphrase, so most key files are ripe for
plucking.)

To use public/private key pairs you must have each host's public key
in your PC's \v(APPDATA)\ssh\known_hosts (SSH v1) and/or
\v(APPDATA)\ssh\known_hosts2 files (SSH v2), and you must
also upload your own public key to each host and put it in the
appropriate place, such as ~/.ssh/authorized_keys (SSH v1)
and/or ~/.ssh/authorized_keys2 (SSH v2) when OpenSSH is the
daemon. When all the right files and keys are in the right places in
the appropriate formats, you can log in without a password. In order to
determine the correct type of key to use you must know the configuration
of the SSH daemon. If you are not the host administrator, contact the
appropriate administrator for assistance. (A common error is to leave
the permissions on the ~/.ssh/ directory and the files it contains
world or group accessible. SSH daemons refuse to use identity files that
are accessible to anyone other than the account owner.

Here's an example. I have a guest ID on a Linux machine at a remote site. If
I make an SSH connection to it (logging in with a password), K95's status line
shows me the SSH server's level is 2.0. If I want to be able to connect
without typing a password, then (1) my end is already done, since K95
added the host's public key to my known_hosts2 file the first time I
made an SSH connection to it; but (2) I must add my PC's public key to
my:

~/.ssh/authorized_keys2

file on the host. In this case there happened to be no such file. So all I
had to do was upload my public key to the host as
~/.ssh/authorized_keys2. But which public key? I have three of them
(see the SSH KEY CREATE command description below):

Well, since the server uses SSH v2, I can ignore the identity.pub
file, which is only for SSH v1. So I began by uploading my
id_dsa.pub file to my ~/.ssh directory, renaming it to
authorized_keys2, logging out, and making a new ssh connection to the
same host. It let me in without password, so I guessed right the first time.
Maybe the id_rsa.pub key would have worked too, who knows -- it
probably depends on the server.

But now, of course, anybody who can obtain a copy of the id_dsa
private key file from my Windows disk can log in to that host as me, without a
password. And it's easy for them to locate the host because it's listed in
my known_hosts2 file, along with all the other hosts I connect to
with SSH v2. So what have I accomplished? I have pretty much left the keys
to all my houses in the street, each key neatly labeled with the address of
the house it unlocks.

So having satisfied myself that the key-exchange mechanism works as designed
(by the SSH designers, not us), I deleted the authorized_keys2 file
from the host and I deleted all the private keys from my Windows disk. Unlike
Kerberos identities or X.509 certificates, compromised private keys can't
be revoked or even tracked down. And unlike encrypted password
authentication, which must be captured in its brief moment of transit, your
key files are always available to hackers, and for that matter, to a
potentially infinite number of them at once.

Note, by the way, that some SSH hosts do not support public/private key pair
authentication at all, so every combination you try will fail. There's no way
to know this without the host administrator telling you, or by exhausting all
the combinations.

Since public/private key-pair authentication is unsafe, K95 also supports two
secure authentication methods for SSH v2 that do do not require
public/private key pairs:

GSSAPI (Generic
Security Services Application Programming Interface), which hooks into the
Kerberos 5 authentication system. NOTE: Since K95 was released, GSSAPI
has changed out from under it, and in most cases it won't be possible to
authenticate SSH connections with GSSAPI.

Command keywords are shown in boldface. These are literal words to
be used in the command. Alphabetic case does not matter. Keywords can
be abbreviated to any degree that does not produce a conflict with any other
keyword that can be used in the same position.

parameter

Parameter names are shown in italics; they are to be replaced by an
actual value; for example, number might be replaced by 123, and
filename might be replaced by oofa.txt.

[ thing ]

Any item enclosed in italicized square brackets is optional; that is,
it can be omitted.

{ thing1, thing2, ... }

Italicized curly braces enclose a list of choices: pick one.

oofa.txt

Typewriter font is used for computer messages, dialogs, code,
and filenames.

In all Kermit commands:

KERBEROS4 can be abbreviated KRB4 or K4

KERBEROS5 can be abbreviated KRB5 or K5

Some of Kermit's Kerberos-related commands are rather complex, but remember
that you don't have to memorize them, or any other Kermit commands. Use
"?" at any point to feel your way through the command, or type HELP
for the desired command to see a brief explanation. If you would like to
have a tutorial in Kermit basics before proceeding, please visit:

Before you try to make any secure connections, you should check whether your
version of Kermit has the required capabilities. The SHOW FEATURES command
lists the security methods that are and are not included. In addition the
following commands can be used (typically in scripts) to check for specific
security features:

CHECK KERBEROS

tells whether your version of Kermit has been built
to include Kerberos protocol (even if it cannot function on your system).
Succeeds if Kerberos is included, fails if it isn't. The CHECK command can
be used in scripts like this:

check kerberos
if success {
Commands to execute if Kerberos is built in.
} else {
Commands to execute if Kerberos is not built in.
}

CHECK NTLM

Tells whether your version of Kermit has been built
to include the NTLM support even if it cannot function on your system,
and succeeds or fails accordingly.

CHECK SRP

Tells whether your version of Kermit has been built
to include SRP protocols. Succeeds or fails accordingly.

CHECK SSH

Tells whether your version of Kermit has been built
to include SSH (even if it cannot function on your system).
Succeeds or fails accordingly.

CHECK SSL/TLS

Tells whether your version of Kermit has been built
to include SSL/TLS (even if it cannot function on your system).
Succeeds or fails accordingly.

IF AVAILABLE ENCRYPTIONcommand

Executes the command if session encryption is available in your
version of Kermit (e.g. in K95 if the K95CRYPT.DLL file is installed
on your PC). Example:

if available encryption set telnet encryption type cast128_cfb64

IF AVAILABLE KERBEROS4command

Executes the command if
Kerberos 4 is available in your version of Kermit
(e.g. if the Kerberos 4 DLLs are installed on your PC).

IF AVAILABLE KERBEROS5command

Executes the command if
Kerberos 5 is available in your version of Kermit.

IF AVAILABLE NTLMcommand

Executes the command if Microsoft NT LAN Manager protocol is
available in your version of Kermit.

IF AVAILABLE SRPcommand

Executes the command if
Secure Remote Password protocol is available
in your version of Kermit.

IF AVAILABLE SSHcommand

Executes the command if
SSH protocol is available in your version of Kermit.

IF AVAILABLE{SSL, TLS} command

Executes the command if SSL/TLS protocol is available in your
version of Kermit.

The Telnet protocol is one of the most flexible protocols ever used on
computer networks, and therefore can be somewhat complicated when its advanced
options come into play. Kermit has commands to manage every aspect of the
Telnet connection. Kermit's Telnet engine and related commands are thoroughly
described in the Kermit Telnet Reference:

(which you should read if you're not familiar with Kermit's Telnet client).
This section focuses on Telnet-related commands for making secure connections.

Four Telnet Options can be negotiated between a Telnet client and server that
affect secure connections: AUTH, ENCRYPT,
START_TLS, and FORWARD_X. When people talk about Telnet not
being secure they are referring to Telnet clients and servers that can't
negotiate any of these four options (because they have not been coded to do
so). That does not mean that secure Telnet clients (such as Kermit) and
servers (Appendix I) are not readily available.

Telnet sessions always begin in an insecure state. Only after the initial
negotiations are complete can the session be secured. Security in Telnet can
be established using many combinations of Telnet Options and authentication
and encryption methods.

The AUTH option negotiates whether authentication is to be used for
the current session, and if so, which type of authentication. The
authentication type is determined by the server offering an ordered list of
types and the client choosing the most preferred type that it supports. Most
forms of authentication generate a shared secret that can be used with the
ENCRYPT option for privacy. The
How and Encrypt flags specify an authentication
mode and whether encryption is required for this connection. The AUTH
option can be negotiated with either the START_TLS or the
ENCRYPT option, but not both.

The following commands control Kermit's Telnet security negotiation
policies and procedures:

Tells Kermit to ACCEPT or REFUSE authentication bids, or actively REQUEST
authentication. REQUIRED refuses and closes the connection if authentication
is not successfully negotiated when either making or accepting connections.
The default is REQUESTED.

AUTOMATIC is the default. Available options can vary depending on the
features Kermit was built to support and the operating system configuration;
type "settelnetauthtype?" for
a list (Hint: keywords in Kermit commands can be abbreviated).

When Kermit is the Telnet client:

AUTOMATIC allows the host to choose the preferred type of authentication.
NONE instructs Kermit to refuse all authentication methods when the
authentication option is negotiated. A list of one or more other values
allow a specific subset of the supported authentication methods to be
used.

When Kermit is the Telnet server:

AUTOMATIC results in available authentication methods being offered to the
Telnet client in the following order: KERBEROS_V,
KERBEROS_IV, SRP, SSL, NTLM.

NONE results in no authentication methods being offered to the Telnet
server when the authentication option is negotiated. The preferred
method of disabling authentication is with
SET TELOPT /SERVER AUTHENTICATION REFUSE.

A list of one or more authentication methods specifies the order those
methods are to be offered to the telnet client.

If you wish to allow NTLM authentication to be used with the Microsoft
Windows 2000 or Services for Unix Telnet client you must specify a list
with NTLM as the first item in the list. By default, NTLM is the last
item in the list because it does not provide any form of data encryption.

SET TELNET AUTHENTICATION HOW-FLAG {ANY, MUTUAL,
ONE-WAY}

Specifies which values for the HOW-FLAG should be accepted as a client
or offered as a server. The default is ANY.

SET TELNET AUTHENTICATION ENCRYPT-FLAG{ANY, NONE,
TELOPT, TLS}

Specifies which values for the ENCRYPT-FLAG should be accepted as a client
or offered as a server. The default is ANY.

The Telnet protocol ENCRYPT option is used to negotiate whether streaming
ciphers are to be used to protect the privacy of the connection, and if so,
which encryption type to use in each direction. The encryption type is
determined by each side offering the list of types it can use to receive data.
Then the sender chooses the first type that it supports from the list. The
ENCRYPT option cannot be negotiated without the AUTH option. Whenever both
START_TLS and ENCRYPT are both available, START_TLS is used since TLS provides
both privacy and integrity to the data stream.

The first parameter specifies the Kermit-to-peer state. The second
parameter specifies the peer-to-Kermit state. The default is ACCEPTED
REQUESTED: Kermit accepts encryption if offered, and requests it in case it
is not offered.

AUTOMATIC allows the host to choose the preferred type of encryption.
Other values allow a specific encryption method to be specified. AUTOMATIC is
the default. The list of options varies depending on the encryption types
selected when Kermit was compiled. An encryption method can be used only if
there is enough key data available. Kerberos 4 can use only DES encryption
because it provides a shared secret just 56 bits in length.

The START_TLS option negotiates whether the current session is to be protected
by Transport Layer Security (TLS), the same protocol used to secure all of the
HTTP Web sites on the Internet. TLS uses X.509 certificates or Kerberos 5
credentials to authenticate the server and optionally authenticate the client.

START_TLS can be used with AUTH to allow Kerberos, Secure Remote Password, or
other authentication methods to be used to authenticate the client. START_TLS
can not be used with the ENCRYPT option. Nor is there any
need to since the protection provided by TLS is stronger than all of the
streaming ciphers supported by the ENCRYPT option.

ACCEPT or REFUSE a request to negotiate TLS, or actively REQUEST
that TLS be negotiated. REQUIRED refuses and closes the connection if
the peer refuses to negotiate TLS or the TLS negotiations end in failure.
ACCEPTED by default when a client. REQUESTED by default when a server.

After the Telnet session is established and protected, it is possible to use
it to protect the data associated with X Windows System clients started on
the remote host via the Telnet session. The FORWARD_X option is
used to negotiate and implement the protection of X Windows Systems data.

ACCEPT or REFUSE a request to negotiate FORWARD_X, or actively REQUEST
that FORWARD_X be negotiated. REQUIRED refuses and closes the connection if
the peer refuses to negotiate FORWARD_X or the FORWARD_X negotiations end in
failure. ACCEPTED by default when a client. Kermit does not support
FORWARD_X when it is a server.

After a Telnet session is authenticated and protected it is possible to
forward the credentials used to authenticate the session to the host. When
credentials are forwarded to the host you do not need to enter your password
when making additional connections from it. This is referred to as Single
Sign-On. Credentials forwarding is currently only supported when the
authentication method is Kerberos 5.

SET TELNET AUTHENTICATION FORWARDING{ON, OFF}

When Kermit is the client, set this to ON to forward forwardable Kerberos
V Ticket Granting Tickets to the host after authentication is complete, so you
can make additional authenticated connections from there. When Kermit is the
server, set this to ON to accept forwardable Kerberos V TGTs from the client.
OFF by default.

When establishing a secure connection there are potentially three usernames
associated with the connection: the name of the user on the local machine; the
name under which the user authenticates (the Kerberos principal name or X.509
certificate name); and the name the user wants to login as. The login name
can be set with either of the following commands:

SET TELNET ENVIRONMENT USER name

SET LOGIN USERID name

If a name is given, it sent to host during Telnet negotiations; if
this switch is given but the string is omitted, no user ID is sent to the
host. If this command is not given, your current USERID value,
\v(userid), is sent. When a userid is sent to the host it is a
request to login as the specified user.

All forms of authentication rely on some secret information that only the user
(or service) being authenticated knows or has in their possession. Before
Kermit can authenticate as the user it must acquire this secret information.
This is usually done by prompting the user for the necessary information at
the time of authentication. But what if you need to automate the process?
The SET LOGIN PASSWORD command can be used to specify the password to Kermit
prior to establishing the connection. However, we strongly advise that this
command be used in a script that prompts for the password and then establishes
the automated connection later. Storing a password in a script file defeats
all of the hard work you have done to secure your connections.

An NTLM user ID consists of both a DOMAIN and a username. This is set in
Kermit as SETLOGINUSERDOMAIN\\username due to the use of backslash
(\) as the command quote character in Kermit's command language.

SET LOGIN PASSWORD password

If a password is given, it is treated as the password to be used (if
required) by any Telnet Authentication protocol (Kerberos Ticket retrieval,
Secure Remote Password (SRP), or X.509 certificate private key decryption).
If no password is specified a prompt is issued to request the password if
one is required for the negotiated authentication method.

If things go wrong when establishing a secure connection it is useful to be
able to watch the telnet negotiations. Even when things go smoothly
it can be fun to watch all of the action.

If an authentication agent (ssh-agent.exe) is in use, setting this value
to ON results in the connection to the agent being forwarded to the remote
computer. The default is OFF.

SET SSH CHECK-HOST-IP { ON, OFF }

Specifies whether the remote host's ip-address should be checked against
the matching host key in the known_hosts file. This can be used to determine
if the host key changed as a result of DNS spoofing. The default is ON.

SET SSH COMPRESSION { ON, OFF }

Specifies whether compression will be used. The default is ON.

SET SSH DYNAMIC-FORWARDING
{ON, OFF}

Specifies whether Kermit is to act as a SOCKS4 service on port 1080 when
connected to a remote host via SSH. When Kermit acts as a SOCKS4 service, it
accepts connection requests and forwards the connections through the remote
host. The default is OFF.

SET SSH GATEWAY-PORTS { ON, OFF }

Specifies whether Kermit should act as a gateway for forwarded
connections received from the remote host. The default is OFF.

SET SSH GSSAPI DELEGATE-CREDENTIALS
{ ON, OFF }

Specifies whether Kermit should delegate GSSAPI credentials to the remote
host after authentication. Delegating credentials allows the credentials to
be used from the remote host. The default is OFF.

SET SSH IDENTITY-FILEfilename [ filename [ ... ] ]

Specifies one or more files from which the user's authorization identities
(private keys) are to be read when using public key authorization. These are
files used in addition to the default files:

Specifies whether Kermit should forward Kerberos 4 TGTs to the host.
The default is OFF.

SET SSH KERBEROS5 TGT-PASSING
{ ON, OFF }

Specifies whether Kermit should forward Kerberos 5 TGTs to to the host.
The default is OFF.

SET SSH PRIVILEGED-PORT
{ ON, OFF }

Specifies whether a privileged port (less than 1024) should be used
when connecting to the host. Privileged ports are not required except when
using SSH V1 with Rhosts or RhostsRSA authorization. The default is OFF.

SET SSH QUIET { ON, OFF }

Specifies whether all messages generated in conjunction with SSH
protocols should be suppressed. The default is OFF.

SET SSH STRICT-HOST-KEY-CHECK{ ASK, ON, OFF }

Specifies how Kermit should behave if the host key check fails. When
strict host key checking is OFF, the new host key is added to the
protocol-version-specific user-known-hosts-file. When strict host key
checking is ON, the new host key is refused and the connection is dropped.
When set to ASK, Kermit prompt you to say whether the new host key should be
accepted. The default is ASK. Strict host key checking protects you against
Trojan horse attacks. It depends on you to maintain the contents of the
known-hosts-file with current host keys.

SET SSH USE-OPENSSH-CONFIG
{ ON, OFF }

Specifies whether Kermit should parse an OpenSSH configuration file after
applying Kermit's SET SSH commands. The configuration file would be located
at \v(appdata)ssh/ssh_config. The default is OFF.

SET SSH V1 CIPHER
{ 3DES, BLOWFISH, DES }

Specifies which cipher should be used to protect SSH version 1
connections. The default is 3DES.

SET SSH V1 GLOBAL-KNOWN-HOSTS-FILE filename

Specifies the location of the system-wide known-hosts file. The
default location depends on the operating system:

Specifies an ordered list of Message Authentication Code algorithms to be
used for integrity protection of the established connection. The default list
is:

hmac-md5 hmac-sha1 hmac-ripemd160 hmac-sha1-96 hmac-md5-96

SET SSH V2 USER-KNOWN-HOSTS-FILE filename

Specifies the location of the user-known-hosts file. The default
location is:

\v(appdata)ssh/known_hosts2

SET SSH VERBOSE level

Specifies how many messages should be generated by the OpenSSH engine.
The level can range from 0 to 7. The default value is 2.

SET SSH VERSION { 1, 2, AUTOMATIC }

Specifies which SSH version should be negotiated. The default is
AUTOMATIC which means use version 2 if supported; otherwise to fall
back to version 1.

SET SSH X11-FORWARDING { ON, OFF }

Specifies whether X Windows System Data is to be forwarded across the
established SSH connection. The default is OFF. When ON, the DISPLAY
value is either set using the SET TELNET ENV DISPLAY command or read
from the DISPLAY environment variable.

SET SSH XAUTH-LOCATION filename

Specifies the location of the xauth executable (if provided with the
X11 Server software.)

Complete details on how to use the FTP support can be found at the Kermit website. Here
we explain how to make secure FTP connections (server willing) with the FTP
OPEN command:

FTP[OPEN [ {/SSL, /TLS} ] ]
hostname [ port ] [ switches ]

Opens a connection to the FTP server on the given host. The default
TCP port is 21 (or 990 if /SSL or /TLS are specified), but a different
port number can be supplied if necessary. /SSL or /TLS should be used
if the FTP daemon is accessed through an SSL Proxy Server.
Optional switches are:

/ANONYMOUS

Logs you in anonymously.

/USER:text

Supplies the given text as your username.

/PASSWORD:text

Supplies the given text as your password. If you include a username
but omit this switch and the server requires a password, you are
prompted for it.

/ACCOUNT:text

Supplies the given text as your account, if required by the server.

/ACTIVE

Forces an active (rather than passive) connection.

/PASSIVE

Forces a passive (rather than active) connection.

The following commands configure the use of FTP Security when establishing
connections:

SET FTP AUTHTYPElist

Specifies an ordered list of authentication methods to be attempted when FTP
AUTOAUTHENTICATION is ON. The default list is: GSSAPI-KRB5, SRP, KERBEROS_V4,
TLS, SSL.
If none of the specified methods are supported by the server, an insecure login
is used as a fallback.
It should be noted that TLS and SSL can be used to secure an
anonymous connection.

SET FTP AUTOAUTHENTICATION{ON, OFF}

Specifies whether or not authentication should be negotiated by the
FTP OPEN command. Default is ON.

SET FTP AUTOENCRYPTION{ON, OFF}

Specifies whether encryption and message integrity (privacy) should be
negotiated by the FTP OPEN command. Default is ON.

SET FTP AUTOLOGIN{ON, OFF}

Tells Kermit whether to try to automatically log you in (using the
FTP USER command) during the FTP OPEN command. Default is ON.

SET FTP COMMAND-PROTECTION-LEVEL{CLEAR, CONFIDENTIAL, PRIVATE,
SAFE}

Tells what level of protection is applied to the FTP command channel.
CLEAR means no protection at all. CONFIDENTIAL means the
messages are encrypted but not integrity protected. PRIVATE means
the messages are encrypted and integrity protected. SAFE means
the messages are integrity protected but not encrypted.

SET FTP CREDENTIAL-FORWARDING{ON, OFF}

Specifies whether end-user credentials are to be forwarded
to the server if supported by the authentication method. At the moment
only GSSAPI-KRB5 supports credentials forwarding.

SET FTP DATA-PROTECTION-LEVEL{CLEAR,
CONFIDENTIAL, PRIVATE, SAFE}

Tells what level of protection is applied to the FTP data channel.
The levels are the same as for SET FTP COMMAND-PROTECTION-LEVEL.

SET FTP SRP CIPHER cipher

Specifies a cipher to be used to encrypt FTP data if SRP security
is negotiated. The default cipher is DES3_ECB.

SET FTP SRP HASH hash

Specifies a hash to be used to integrity protect FTP data if SRP
security is negotiated. The default hash is SHA1.

C-Kermit 8.0 and Kermit 95 2.00 provide support for secure HTTP requests via
the use of SSL or TLS. Secure connections are established automatically when
the destination service name is "https" or the port number is 443.
Alternatively, SSL or TLS may be utilized with arbitrary port numbers if you
include the appropriate switch in the HTTP OPEN command:

HTTP[ switches ] OPEN[ {/SSL, /TLS} ]hostname [ service/port ]

Instructs Kermit to open a new connection for HTTP communication with the
specified host on the specified port. The default port is "http" (80). If
/SSL or /TLS are specified a secure connection is established. If
switches are specified, they are applied to all subsequent HTTP actions
(GET, PUT, ...) until an HTTP CLOSE command has been executed.

The SET AUTHENTICATION command lets you configure Kermit's authentication
methods and set defaults for the AUTHENTICATE command so
you don't always have to include all the switches if you give more than one
AUTHENTICATE command in a Kermit session.

If you always use the same setup, you can put the appropriate SET
AUTHENTICATION commands in your Kermit customization file:
K95CUSTOM.INI (Windows) or ~/.mykermrc (UNIX).

When ON, Kermit destroys all credentials in the default
credentials cache upon Kermit termination. Default is NEVER.

SET AUTHENTICATION { KERBEROS4, KERBEROS5} AUTOGET { ON, OFF }

When ON and the protocol is TELNET or FTP,
if the host offers Kerberos 4 or Kerberos 5 authentication and
Kermit is configured to use that authentication method and there is no
TGT, Kermit automatically attempts to retrieve one by prompting for the
password (and principal if needed.) Default is ON.

SET AUTHENTICATION KERBEROS5 CREDENTIALS-CACHE cache-name

Specifies an alternative credentials cache, useful when you need to
maintain two or more sets of credentials for different realms or roles. The
default is specified by the environment variable KRB5CCNAME or as reported by
the Kerberos 5 library.

SET AUTHENTICATION{ KERBEROS4, KERBEROS5} CHECK-ADDRESSES { ON, OFF }

When ON, Kermit uses the embedded IP address(es) in the ticket to
determine validity. When OFF, IP addresses are ignored by Kermit.
The default is ON.

SET AUTHENTICATION KERBEROS5 FORWARDABLE
{ ON, OFF }

ON specifies that Kerberos 5 credentials should be forwardable to the
host. If SET TELNET AUTHENTICATION FORWARDING is ON, forwardable
credentials are sent to the host. Default is OFF.

SET AUTHENTICATION KERBEROS5 GET-K4-TGT
{ ON, OFF }

ON specifies that Kerberos 4 credentials should be requested each
time Kerberos 5 credentials are requested with AUTH KERBEROS5 INIT.
The default is OFF.

SET AUTHENTICATION KERBEROS4 INSTANCE instance

Allows a Kerberos 4 instance to be specified as a default (if needed).

SET AUTHENTICATION { KERBEROS4, KERBEROS5} LIFETIMEminutes

Specifies the lifetime of the TGTs requested from the KDC. The default
is 600 minutes (10 hours).

SET AUTHENTICATION KERBEROS5 NO-ADDRESSES { ON, OFF }

Kerberos 5 tickets contain a list of all of the IP addresses associated
with the computer used to acquire them. This allows the recipient of a ticket
to check whether it came from the machine to which it was issued, and makes
stolen Kerberos tickets useless. Network Address
Translators and other Proxy services have the side effect of changing the
IP address from which a connection appears to originate. This causes the IP
address check to fail and for Kerberos 5 tickets to be rejected as invalid.
When ON, the NO-ADDRESSES command prevents the inclusion of IP addresses in
Kerberos 5 tickets retrieved with Kermit's AUTHENTICATE KERBEROS5 INIT
command enabling the tickets to be accepted from any host.

SET AUTHENTICATION KERBEROS4 PREAUTH
{ ON, OFF }

Allows Kerberos 4 preauthenticated TGT requests to be turned off. The
default is ON. Only use if absolutely necessary. We recommend that
preauthenticated requests be required for all tickets returned by a KDC
to a requestor.

SET AUTHENTICATION { KERBEROS4, KERBEROS5}
PRINCIPALname

When Kermit starts, it attempts to set the principal name to that stored
in the current credentials cache. If no credential cache exists, the
current SET LOGIN USERID value is used. SET LOGIN USERID is set to the
operating systems current username when Kermit is started. To force
Kermit to prompt the user for the principal name when requesting TGTs, place:

SET AUTH K4 PRINCIPAL {}
SET AUTH K5 PRINCIPAL {}

in the Kermit initialization file or connection script.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 }
PROMPT PASSWORDprompt

Specifies a custom prompt to be used when prompting for a password. The
Kerberos prompt strings may contain two "%s" replacement fields. The
first %s is replaced by the principal name; the second by the realm.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 }
PROMPT PRINCIPALprompt

Specifies a custom prompt to be used when prompting for the Kerberos
principal name. No %s replacement fields may be included. Kermit
prompts for a principal name when retrieving a TGT if the command:

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL {}

has been issued.

SET AUTHENTICATION KERBEROS5 PROXIABLE{ ON, OFF }

When ON, specifies that Kerberos 5 credentials should be proxiable.
The default is OFF.

SET AUTHENTICATION KERBEROS5 RENEWABLE minutes

When minutes is greater than the ticket lifetime a TGT may be
renewed with AUTH K5 INIT /RENEW instead of granting a new ticket
as long as the ticket is not expired and it's within the renewable
lifetime. Default is 0 (zero) minutes.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 }REALMname

If no default is set, the default realm configured for the Kerberos
libraries is used. Abbreviations are accepted.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 }
SERVICE-NAMEname

This command specifies the service ticket name used to authenticate to the
host when Kermit is used as a client; or the service ticket name accepted by
Kermit when it is acting as the host. If no default is set, the default
service name for Kerberos 4 is "rcmd" and for Kerberos 5 is
"host".

This command applies to both SSL and TLS. A colon-separated list of any
of the following (case-sensitive) options is accepted, depending on the
options chosen when OpenSSL was compiled:

Key Exchange Algorithms:

kRSA: RSA key exchange

kDHr: Diffie-Hellman key exchange (key from RSA cert)

kDHd: Diffie-Hellman key exchange (key from DSA cert)

kEDH: Ephemeral Diffie-Hellman key exchange (temporary key)

kKRB5: Kerberos 5

Authentication Algorithm:

aNULL: No authentication

aRSA: RSA authentication

aDSS: DSS authentication

aDH: Diffie-Hellman authentication

aKRB5: Kerberos 5

Cipher Encoding Algorithm:

eNULL: No encoding

AES256: 256-bit AES encoding

AES128: 128-bit AES encoding

DES: DES encoding

3DES: Triple DES encoding

RC4: RC4 encoding

RC2: RC2 encoding

IDEA: IDEA encoding

MAC Digest Algorithm:

MD5: MD5 hash function

SHA1: SHA1 hash function

SHA: SHA hash function (should not be used)

Aliases:

ALL: all ciphers

SSLv2: all SSL version 2.0 ciphers (should not be used)

SSLv3: all SSL version 3.0 ciphers

EXP: all export ciphers (40-bit)

EXPORT56: all export ciphers (56-bit)

LOW: all low strength ciphers (no export)

MEDIUM: all ciphers with 128-bit encryption

HIGH: all ciphers using greater than 128-bit encryption

RSA: all ciphers using RSA key exchange

DH: all ciphers using Diffie-Hellman key exchange

EDH: all ciphers using Ephemeral Diffie-Hellman key exchange

ADH: all ciphers using Anonymous Diffie-Hellman key exchange

DSS: all ciphers using DSS authentication

KRB5: all ciphers using Kerberos 5

AES: all ciphers using AES

NULL: all ciphers using no encryption

Each item in the list may include a prefix modifier:

"+"

Move cipher(s) to the current location in the list

"-"

Remove cipher(s) from the list (may be added again by
a subsequent list entry)

"!"

Kill cipher from the list (it may not be added again
by a subsequent list entry)

If no modifier is specified the entry is added to the list at the current
position. "+" may also be used to combine tags to specify entries such as
"RSA+RC4" describes all ciphers that use both RSA and RC4.

For example, all available ciphers not including ADH key exchange:

ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

All algorithms including ADH and export but excluding patented or
trade secreted algorithms:

HIGH:MEDIUM:LOW:EXPORT56:EXP:ADH:!RC4:!RC2:!IDEA

The OpenSSL command:

openssl ciphers -v list-of-ciphers

may be used to list all of the ciphers and the order described by a specific
list-of-ciphers.

SET AUTHENTICATION { SSL, TLS } CRL-DIRdirectory

Specifies a directory that contains certificate revocation files, where
each file is named by the hash of the certificate issuer name.
OpenSSL expects the hash symlinks to be made like this:

ln -s crl.pem `openssl crl -hash -noout -in crl.pem`.r0

Since all file systems do not have symlinks you can use the following
command in Kermit to copy the crl.pem file to the hash file name:

copy crl.pem {\fcommand(openssl crl -hash -noout -in crl.pem).r0}

This produces a hash based on the issuer field in the CRL such that the issuer
field of a Cert may be quickly mapped to the correct CRL.

In Kermit 95, the default directory is \v(exedir)crls

SET AUTHENTICATION { SSL, TLS } CRL-FILEfilename

Specifies a file that contains certificate revocations used to reject
the validation of certificates.

In Kermit 95, the default file is \v(exedir)ca_crls.pem

SET AUTHENTICATION { SSL, TLS } DEBUG
{ ON, OFF }

Tells whether debug information should be displayed about the SSL/TLS
connection. When DEBUG is ON, the VERIFY command does not terminate
connections when set to FAIL-IF-NO-PEER-CERT and a certificate is
presented that cannot be successfully verified; instead each error is
displayed but the connection automatically continues.

SET AUTHENTICATION { SSL, TLS }
DH-PARAM-FILEfilename

Specifies a file containing DH parameters used to generate
temporary DH keys. If a DH parameter file is not provided Kermit uses a
fixed set of parameters depending on the negotiated key length. Kermit
provides DH parameters for key lengths of 512, 768, 1024, 1536, and 2048
bits.

SET AUTHENTICATION { SSL, TLS }
DSA-CERT-CHAIN-FILEfilename

Specifies a file containing a DSA certificate chain to be sent along with
the DSA-CERT to the peer. This file must only be specified if Kermit is
being used as a server and the DSA certificate was signed by an
intermediary certificate authority.

SET AUTHENTICATION { SSL, TLS }
DSA-CERT-FILEfilename

Specifies a file containing a DSA certificate to be sent to the peer to
authenticate the host or end user. The file may contain the matching DH
private key instead of using the DSA-KEY-FILE command.

SET AUTHENTICATION { SSL, TLS }
DSA-KEY-FILEfilename

Specifies a file containing the private DH key that matches the DSA
certificate specified with DSA-CERT-FILE. This command is only necessary
if the private key is not appended to the certificate in the file
specified by DSA-CERT-FILE.

Note: When executing a script in the background or when it is
running as an Internet Kermit Service Daemon, Kermit cannot support encrypted
private keys. When attempting to load a private key that is encrypted, a
prompt will be generated requesting the passphrase necessary to decrypt the keyfile.
To automate access to the private key you must decrypt the encrypted keyfile
and create an unencrypted keyfile for use by Kermit. This can be accomplished by
using the following command and the passphrase:

openssl dsa -in encrypted-key-file -out unencrypted-key-file

SET AUTHENTICATION {SSL, TLS}RANDOM-FILEfilename

Specifies a file containing random data to be used when initializing the
Pseudo Random Number Generator (PRNG) engine. This file is overwritten with
new random data after the file is read.

SET AUTHENTICATION { SSL, TLS }
RSA-CERT-CHAIN-FILEfilename

Specifies a file containing a RSA certificate chain to be sent along with
the RSA-CERT to the peer. This file must only be specified if Kermit is
being used as a server and the RSA certificate was signed by an
intermediary certificate authority.

SET AUTHENTICATION {SSL, TLS}RSA-CERT-FILEfilename

Specifies a file containing a RSA certificate to be sent to the peer to
authenticate the host or end user. The file may contain the matching RSA
private key instead of using the RSA-KEY-FILE command.

SET AUTHENTICATION {SSL, TLS}RSA-KEY-FILEfilename

Specifies a file containing the private RSA key that matches the RSA
certificate specified with RSA-CERT-FILE. This command is only necessary
if the private key is not appended to the certificate in the file
specified by RSA-CERT-FILE.

Note: When executing a script in the background or when it is
running as an Internet Kermit Service Daemon, Kermit cannot support encrypted
private keys. When attempting to load a private key that is encrypted, a
prompt will be generated requesting the passphrase necessary to decrypt the keyfile.
To automate access to the private key you must decrypt the encrypted keyfile
and create an unencrypted keyfile for use by Kermit. This can be accomplished by
using the following command and the passphrase:

openssl rsa -in encrypted-key-file -out unencrypted-key-file

SET AUTHENTICATION {SSL, TLS}VERBOSE { ON, OFF }

Specifies whether information about the authentication (the certificate
chain) should be displayed when making a connection.

Specifies whether certificates should be requested from the peer; whether
they should be verified when they are presented; and whether they should
be required. When set to NO (the default for IKSD), Kermit does not
request that the peer send a certificate and if one is presented it is
ignored. When set to PEER-CERT (the default when not IKSD), Kermit
requests a certificate be sent by the peer. If the certificate is
presented, it is verified. Any errors during the verification process
result in queries to the end user. When set to FAIL-IF-NO-PEER-CERT,
Kermit asks the peer to send a certificate. If the certificate is not
presented or fails to verify successfully, the connection is terminated
without querying the user.

If an anonymous cipher (i.e., ADH) is desired the NO setting must be
used; otherwise the receipt of the peer certificate request is
interpreted as a protocol error and the negotiation fails.

If you wish to allow the peer to authenticate using either an X.509
certificate to userid mapping function or via use of a ~/.tlslogin file,
you must use either PEER-CERT or FAIL-IF-NO-PEER-CERT. Otherwise, any
certificates that are presented are ignored. In other words, use NO if
you want to disable the ability to use certificates to authenticate a
peer.

SET AUTHENTICATION {SSL, TLS}VERIFY-DIRdirectory

Specifies a directory that contains root CA certificate files used to
verify the certificate chains presented by the peer. Each file is named
by a hash of the certificate.

OpenSSL expects the hash symlinks to be made like this:

ln -s cert.pem `openssl x509 -hash -noout -in cert.pem`.0

Since all file systems do not have symlinks you can use the following
command in Kermit to copy the cert.pem file to the hash file name:

copy cert.pem {\fcommand(openssl x509 -hash -noout -in cert.pem).0}

This produces a hash based on the subject field in the cert such that the
certificate may be quickly found.

In Kermit 95, the default directory is \v(exedir)certs

SET AUTHENTICATION {SSL, TLS}VERIFY-FILEfile

Specifies a file that contains root CA certificates to be used for
verifying certificate chains.

Specifies the requested lifetime in minutes for the ticket. If no lifetime
is specified, 600 minutes is used. If the lifetime is greater than the
maximum supported by the ticket granting service, the resulting lifetime
is shortened accordingly.

/NOT-PREAUTH

Instructs Kermit to send a ticket granting ticket (TGT) request to the KDC
without any preauthentication data.

/PASSWORD:string

Allows the inclusion of a password in a script file. If no /PASSWORD
switch is included, you are prompted on a separate line. The password switch
is provided for use by automated scripts. However, we strongly recommend that
it not be used because clear-text passwords are easily compromised.

/PREAUTH

Instructs Kermit to send a preauthenticated ticket granting ticket (TGT)
request to the KDC instead of a plaintext request. The default when
supported by the Kerberos libraries.

but can be omitted if it is the same as your username or SET LOGIN USERID
value on the client system.

AUTHENTICATE K5 INITIALIZE switches (all optional):

/ADDRESSES:list-of-ip-addresses

Specifies a list of IP addresses that should be placed in the Ticket
Granting Ticket in addition to the local machine addresses.

/FORWARDABLE

Requests forwardable tickets.

/KERBEROS4

Instructs Kermit to get Kerberos 4 tickets in addition to Kerberos 5
tickets. If Kerberos 5 tickets are not supported by the server, a mild
warning is printed and Kerberos 4 tickets are requested.

/LIFETIME:number

Specifies the requested lifetime in minutes for the ticket. If no
lifetime is specified, 600 minutes is used. If the lifetime is greater
than the maximum supported by the ticket granting service, the resulting
lifetime is shortened.

/NO-ADDRESSES

Instructs Kermit to not include a list of local IP addresses in the ticket
retrieved from the KDC.

/NO-KERBEROS4

Instructs Kermit to not attempt to retrieve Kerberos 4 credentials.

/NOT-FORWARDABLE

Requests non-forwardable tickets.

/NOT-PROXIABLE

Requests non-proxiable tickets.

/PASSWORD:string

Allows the inclusion of a password in a script. If no password is
specified you are prompted for one. The password switch is provided for
use by automated scripts. However, we strongly recommend that it not be
used because clear-text passwords can be easily compromised. See Chapter
19 of Using C-Kermit.

/POSTDATE:date-time

Requests a postdated ticket, valid starting at date-time. Postdated
tickets are issued with the invalid flag set, and need to be fed back to
the KDC before use with the /VALIDATE switch. See
Section 1.6 of the
C-Kermit 7.0
Update Notes for acceptable date-time formats.

/PROXIABLE

Requests proxiable tickets.

/REALM:string

Allows an alternative realm to be specified.

/RENEW

Requests renewal of a renewable Ticket Granting Ticket. Note that
an expired ticket cannot be renewed even if it is within its renewable
lifetime.

/RENEWABLE:number

Requests renewable tickets, with a total lifetime of number minutes.

/SERVICE:string

Allows a service other than the ticket granting service to be specified.

/VALIDATE

Requests that the Ticket Granting Ticket in the cache (with the invalid
flag set) be passed to the KDC for validation. If the ticket is within
its requested time range, the cache is replaced with the validated
ticket.

The Kerberos 5 principal format is:

userid[/instance][@realm]

and can be omitted if it is the same principal as stored in the current ticket
cache at the time Kermit started; or the current username if a ticket
cache did not exist.

Specifies the IP address of the computer that C-Kermit is running on.
Normally this is not necessary. The exceptions would be if the host is multihomed (e.g. one host pointed to by many IP addresses, or
one of many hosts pointed to by a "common" IP address) or has multiple
physical network adapters, with a different address for each adapter, AND you
want C-Kermit to either (a) accept an incoming TCP connection
("sethost*") or (b) get a Kerberos ticket.

SET TCP REVERSE-DNS-LOOKUP { ON, OFF }

Specifies whether or not a Reverse DNS Lookup should be performed to
determine the hostname assigned to the IP address used to connect to the host.

For mutual authentication to succeed, the client and the server must agree on
the name to be used for the server. It is common for servers to have more
than one name. This is especially true for clusters of servers that provide
the same function and are referenced by an alias. For example,
www.foo.com might be an alias for three machines
www-1.foo.com, www-2.foo.com, and www-3.foo.com.
If the hosts are configured to use separate credentials for authentication it
would be necessary to know which host is actually in use since
"www.foo.com" is not equal to "www-1.foo.com".

On the other hand, since DNS is not a secure service, using an additional
lookup to verify the name associated with a particular IP address increases
the susceptibility that the authentication may be forged by an attacker.

For the highest level of security, Reverse DNS Lookups should be turned OFF.

Establishes a connection to the specified network host on the currently
selected network type. For TCP/IP connections, the default service is
TELNET and the default protocol is TELNET. Not all protocols have a default
service name.

The following SET HOST switches are useful with secure connections:

/CONNECT

Tells Kermit to enter CONNECT (terminal) mode automatically if the
connection is successful.

/SERVER

Tells Kermit to enter server mode automatically if the connection is
successful.

/USERID:[name]

This switch is equivalent to SET LOGIN USERID or SET TELNET
ENVIRONMENT USER . If a string is given, it sent to host during Telnet
negotiations; if this switch is given but the string is omitted, no user ID is
sent to the host. If this switch is not given, your current USERID value,
\v(userid), is sent. When a userid is sent to the host it is a
request to login as the specified user.

/PASSWORD:[string]

This switch is equivalent to SET LOGIN PASSWORD. If a string is given,
it is treated as the password to be used (if required) by any Telnet
Authentication protocol (Kerberos Ticket retrieval, Secure Remote
Password, or X.509 certificate private key decryption.) If no password
switch is specified a prompt is issued to request the password if one
is required for the negotiated authentication method.

The SET HOST protocol-switches used with secure connections are:

/RLOGIN

Use Rlogin protocol even if this is not an Rlogin port.

/TELNET

Send initial Telnet negotiations even if this is not a Telnet port.

/K4LOGIN

Use Kerberos IV klogin protocol even if this is not a klogin port.

/EK4LOGIN

Use Kerberos IV Encrypted login protocol even if this is not an eklogin
port.

/K5LOGIN

Use Kerberos V klogin protocol even if this is not a klogin port.

/EK5LOGIN

Use Kerberos V Encrypted login protocol even if this is not an eklogin
port.

Equivalent to SET TELNET AUTH TYPE type and
SET TELOPT AUTH REQUIRED with the following exceptions. If the type
is AUTO, then SET TELOPT AUTH REQUESTED is executed and if the type
is NONE, then SET TELOPT AUTH REFUSED is executed. If START_TLS is negotiated
REQUIRED becomes REQUESTED.

/ENCRYPT:type

Equivalent to SET TELNET ENCRYPT TYPE type
and SET TELOPT ENCRYPT REQUIRED REQUIRED with the following exceptions.
If the type is AUTO then SET TELOPT AUTH REQUESTED REQUESTED is executed
and if the type is NONE then SET TELOPT ENCRYPT REFUSED REFUSED is
executed. If START_TLS is negotiated REQUIRED becomes REFUSED.

/USERID:[name]

Equivalent to SET LOGIN USERID name or SET TELNET
ENVIRONMENT USER name. If a string is given, it sent to host during
Telnet negotiations; if this switch is given but the string is omitted, no
user ID is sent to the host. If this switch is not given, your current
USERID value, \v(userid), is sent. When a userid is sent to the host
it is a request to login as the specified user.

/PASSWORD:[string]

This switch is equivalent to SET LOGIN PASSWORD. If a string is given,
it is treated as the password to be used (if required) by any Telnet
Authentication protocol (Kerberos Ticket retrieval, Secure Remote
Password, or X.509 certificate private key decryption.) If no password
switch is specified a prompt is issued to request the password if one
is required for the negotiated authentication method.

At the K-95> prompt, simply type "ssh somehost", where
somehost is the IP host name or address of the host you want to connect
to or, if your user ID on the destination host is different from your local
user ID, "ssh somehost /user:remoteuserid". You might get some messages or
questions about the hostname the first time you make a connection, for
example:

[C:\K95] K-95> ssh xyzcorp.com
The authenticity of host 'xyzcorp.com' can't be established.
DSA key fingerprint is 85:f9:8b:cd:23:12:01:d9:cf:7a:12:cf:b5:5d:ab:60.
Are you sure you want to continue connecting (yes/no)?

but that's normal for any SSH client. Unless you have reason to believe the
host is an imposter, say "yes" (more about this in the next
section). Now K95 asks you for your password, you type it into the box,
K95 sends it over the encrypted connection, and off you go.

From this point, an SSH session is like any other K95 terminal session. You
can escape back to the prompt with Alt-X, return to the terminal screen with C
or Alt-X, transfer files, whatever you want. When you log out from the host,
K95 should pop back to its command screen automatically, but that
depends on the SSH server.

A single instance of K95 presently can not manage multiple terminal sessions,
SSH, Telnet, modem, or otherwise, but of course you can run multiple instances
of K95. You can, however, have an FTP session and/or an HTTP session at the
same time as a terminal session in a single K95 instance.

Syntax:SSH{ADD, AGENT, CLEAR, KEY,[OPEN], V2} operands...

Performs the SSH-related action specified by the keyword.

Let's look at the most important and most commonly used SSH command first:

This command establishes a new connection using SSH version 1 or version 2
protocol. The connection is made to the specified host on the SSH port (you
can override the port by including a port name or number after the host name).
Once the connection is established the authentication negotiations begin. If
the authentication is accepted, the local and remote port forwarding lists (if
any) are used to establish the desired connection(s) and if X11 Forwarding is
active, this results in a remote port forwarding between the X11 clients on
the remote host and X11 Server on the local machine. If a /COMMAND
is provided, the command is executed on the remote host in place of your
default shell.

Approximate Synonym:SET HOST /NETWORK:SSH.
This is exactly like SSH OPEN, except it does not enter the Terminal screen
(unless you include the /CONNECT switch). This allows SSH
connections to be made in scripts, in which interactions with the host are to
be automated. To see how to set up an SSH-based Kermit file-transfer
and -management service (similar to SFTP but with greater flexibility,
functionality, friendliness, and scriptability),
CLICK HERE.

If your username on the host is not the same as K95's \v(userid)
value, you must include the /USER: switch to specify the
username on the host. You can find out K95's \(userid) value by
typing SHOW VAR USERID at the K95 prompt. You can set this variable globally
with the SET LOGIN USERID command, in which case it is used for all future
network logins until you EXIT from K95. The /USER: switch, on the
other hand, applies only to the command with which it is given, and leaves the
global USERID setting alone.

Here are the rest of the SSH commands in alphabetical order:

SSH ADD LOCAL-PORT-FORWARDlocal-port host port

Adds a port forwarding triplet to the local port forwarding list. The
triplet specifies a local port to be forwarded and the hostname / ip-address
and port number to which the port should be forwarded from the remote host.
Port forwarding is activated at connection establishment and continues until
the connection is terminated.

SSH ADD REMOTE-PORT-FORWARDremote-port host port

Adds a port forwarding triplet to the remote port forwarding list. The
triplet specifies a remote port to be forwarded and the hostname/ip-address
and port number to which the port should be forwarded from the local machine.
Port forwarding is activated at connection establishment and continues until
the connection is terminated.

SSH AGENT ADD [ identity-file ]

Adds the contents of the identity-file (if any) to the SSH AGENT private
key cache. If no identity-file is specified, all files specified with SET SSH
IDENTITY-FILE are added to the cache.

SSH AGENT DELETE [ identity-file ]

Deletes the contents of the identity-file (if any) from the SSH AGENT
private key cache. If no identity-file is specified, all files specified with
SET SSH IDENTITY-FILE are deleted from the cache.

SSH AGENT LIST [ /FINGERPRINT ]

Lists the contents of the SSH AGENT private key cache. If
/FINGERPRINT is specified, the fingerprint of the private keys are
displayed instead of the keys.

SSH CLEAR LOCAL-PORT-FORWARD

Clears the local port forwarding list.

SSH CLEAR REMOTE-PORT-FORWARD

Clears the remote port forwarding list.

SSH KEY Commands:

The SSH KEY commands create and manage public and private key pairs
(identities). There are three forms of SSH keys. Each key is stored
in its own file:

Keys are stored using the OpenSSH keyfile format. The private key
files can be (optionally) protected by specifying a passphrase. A
passphrase is a longer version of a password. English text provides
no more than 2 bits of key data per character. 56-bit keys can be
broken by a brute force attack in approximately 24 hours. When used,
private key files should therefore be protected by a passphrase of at
least 40 characters (about 80 bits).

This command creates a new private/public key pair. The defaults are:
BITS:1024 and TYPE:V2-RSA. The filename is the name of the private key file.
The public key is created with the same name with .pub appended to it. If a
filename is not specified Kermit prompts you for it. V1 RSA key files may
have an optional comment, which is ignored for other key types.

The RLOGIN (Remote Login) protocol is not as flexible as the Telnet protocol
and supports no option mechanism. Authentication and privacy are not part of
the RLOGIN protocol. When we refer to authenticated and encrypted RLOGIN we
are really referring to one of four other protocols derived from RLOGIN:
Kerberos 4 Remote Login (K4LOGIN); Kerberos 4 Encrypted Remote Login
(EK4LOGIN); Kerberos 5 Remote Login (K5LOGIN); and Kerberos 5 Encrypted Remote
Login (EK5LOGIN).

RLOGIN /ENCRYPT /KERBEROS4 /KERBEROS5hostname username

The RLOGIN command is a shortcut for making interactive connections.
It is the equivalent of specifying:

By default Kermit tries to negotiate a secure authentication method and to
obtain private command and data channels. Therefore, all that is normally
required to establish a secure FTP session is to issue the FTP OPEN
command. If the server to which you are connecting supports a common security
mechanism, it is used to secure the session.

For example, to establish a secure FTP connection using SRP the following
commands could be executed:

Secure Sockets Layer (SSL) and Transport Layer Security (TLS)
protocols were designed to secure e-commerce transactions (HTTP) over the
Internet. Their use as a tunnel protocol is becoming widespread as a means
for securing other protocols such as FTP, IMAP, POP3, LDAP, NNTP, and even
insecure versions of Telnet (this is frequently done with STunnel:
http://www.stunnel.org/.)
Kermit provides the ability to establish SSL and TLS connections to transfer
data, script HTTP sessions, or use Telnet protocol without the
START_TLS option.

Kermit provides four protocol-switches for establishing SSL or TLS
connections: /SSL, /TLS, /SSL-TELNET, and
/TLS-TELNET. Unlike other protocols such as TELNET and RLOGIN there
are no standard services (IP ports) assigned to these protocols. Use of these
protocols assumes prior knowledge of the ports to connect to on the remote
host. There are also no shortcut commands for use with these protocols. Use
the SET HOST command as described above when making connections.

The Kerberos 5 authentication implemented in the Telnet protocol is a
client to server authentication protocol. It requires that the parties
to the authentication be an end user principal and a service principal.
The Kerberos 5 User to User protocol is specificly designed to allow
two end user principals to authenticate one another. The shared secret
generated during the authentication is then used to ensure the privacy
of the data transmitted on the connection.

There is no shortcut command provided for Kerberos 5 User to User protocol;
nor is there a default service. To establish a connection between two Kermit
processes using Kerberos 5 User to User protocol:

Once you have a secure connection, you can use it just like a regular
(insecure one). Telnet sessions are Telnet sessions; FTP is FTP. However,
encryption and the subsequent decryption of a data stream can result in 10% to
60% reduction in file transfer performance depending on the encryption
algorithm. Encrypted data streams are uncompressible, thus reducing
throughput on PPP or SLIP connections.

When OpenSSL is built with support for ZLIB compression and compressed SSL/TLS
connections can be negotiated, the degradation in file transfer performance
can be reduced.

In Kermit 95, the authentication type and encryption levels are displayed in
the terminal-screen status Line as follows:

K4

Kerberos IV

K5

Kerberos V

NTLM

NT LAN Manager

SRP

Secure Remote Password

pp

No encryption

Ep

Encryption to host, plaintext from host

pD

Plaintext to host, encryption from host

ED

Encryption both directions

SSL

Secure Sockets Layer (both directions)

TLS

Transport Layer Security (both directions)

Encrypted sessions become unreadable if even one bit of data is inserted into
or deleted from the data stream. One damaged bit results in nine damaged
bytes but subsequent bytes remain readable. But since TCP/IP is a reliable
transport by definition, none of this should occur.

Windows login names are not case-sensitive. However, Unix login names are.
If the Unix login name is "fred" but Windows was logged in using the name
"Fred", authentication appears to succeed but telnetd closes the connection
after Telnet negotiations are complete. There are several solutions to this
problem:

Make sure the Windows login name is case identical to the Unix login name.
(If Windows has recorded the login in the registry as "Fred" it won't
matter if you login to Windows using "fred". The only way to correct
this problem is to edit the Registry.)

Use the SET LOGIN USERID name command to set the proper login name
before connecting to the telnet server.

Use the SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL
name command to set the proper principal name before connecting to the
telnet server.

Specify the remote username in the principal of your AUTHENTICATE
Kxxx INITIALIZE command.

Kermit adjusts the case of the name if and only if a case insensitive
comparison of the SET LOGIN USERID name and the name in the authentication
ticket shows no differences.

This chapter is intended for those who are building secure Kermit programs
from source code and/or installing secure versions of Kermit for use within
their organization. It presumes that you've read all the previous chapters.

When Kerberos IV and/or Kerberos V are installed and the DLLs are located in
the PATH, Kermit 95 attempts to negotiate authentication with the host if the
host is Kerberized and if you have not instructed Kermit 95 to do otherwise.

In addition, if the appropriate encryption patch (obtained from the Kermit
Project) is installed, two-way encryption is also negotiated and used if
authentication was negotiated. The encryption patch is available WITH EXPORT
RESTRICTIONS at:

Due to the length of the shared secret negotiated by Kerberos 4 only 56-bit DES
encryption can be used.

Per-PC configuration files may or may not be necessary at your installation.
If your site's DNS servers supply Kerberos realm information, no
configuration files are needed and you can skip to
Section 4.1.2.

Kerberos IV uses three configuration files in the
\WINDOWS directory: LEASH.INI (user settings),
KRB.CON and KRBREALM.CON. KRB.CON and
KRBREALM.CON are used by Kerberos IV to map your host's domain name
to a realm and then to determine the name of the Kerberos server for that
realm. As distributed from MIT, these files are set up for MIT's realm,
domain, and host information, so if you are not at MIT you'll need to
substitute the information for your own site; for example:

In addition, if the appropriate encryption patch (obtained from the Kermit
Project) is installed, two-way encryption is also negotiated and used if
authentication was negotiated. The encryption patch is available WITH EXPORT
RESTRICTIONS at:

Kermit 95 contains support for authenticating incoming connections using SRP.
Unfortunately, there are no Windows based tools for creating the SRP password
file. However, once a password and config file are created on Unix they can
be copied to Windows. On Windows 9x the tpasswd and
tpasswd.conf files are stored in the C:\WINDOWS directory.
On NT they are stored in %windir%\SYSTEM32\DRIVERS\ETC.

NTLM authentication is a feature of Windows 95/98, NT, and Windows 2000. It
is used to authenticate Windows clients to Windows services. Telnet Auth
NTLM is implemented in the Microsoft Telnet Daemon that ships with NT
Services for Unix and with Windows 2000.

Windows 95/98 only contains support for the client whereas NT contains
support for both client and server. Kermit 95 can authenticate incoming
connections with NTLM when it is executing on NT.

On non-Unix platforms OpenSSL does not define default locations for
certificates and revocation lists therefore the appropriate SET AUTH {
SSL, TLS } commands must be given (e.g. included in the
K95CUSTOM.INI or IKSD.KSC file) before certificate
verification to be performed.

As of Kermit 95 version 1.1.21 the default locations are provided as follows:

CA certificates are searched for in the following directories using the
hash of the certificate as the filename:

\v(appdata)certs/
\v(common)certs/
\v(exedir)certs/

CA certificates are searched for in the following files:

\v(appdata)ca_certs.pem
\v(common)ca_certs.pem
\v(exedir)ca_certs.pem

CRLs are searched for in the following directories using the hash of the
CRL as the filename:

\v(appdata)crls/
\v(common)crls/
\v(exedir)crls/

CRLs are searched for in the following files:

\v(appdata)ca_crls.pem
\v(common)ca_crls.pem
\v(exedir)ca_crls.pem

Due to patent licensing restrictions on the IDEA algorithm within the
United States, all binaries that the Kermit Project distributes to
provide SSL/TLS support for Kermit 95 do not contain IDEA ciphers.

See Appendix III if you wish to provide server-side
support for authentication of clients using public key certificates.

SSH was added to Kermit 95 because many sites today refuse Telnet connections
(clear-text or secure) and accept only SSH connections. As of version 1.2.21,
the Windows (not OS/2) version of Kermit 95 includes SSH v1 and v2 clients:

K95's SSH implementation was originally based on
OpenSSH 3.0.2p1, and was
customized to (a) allow connections in series; (b) incorporate
Kerberos and Secure Remote Password authentication methods; (c)
interface with the rest of K95 (settings, etc); and (d) close some
potential security holes in the original distribution.

K95 can make SSH connections to any host that has sshd for SSH 1.3,
1.5, or 2.0. OpenSSH does not support SSH versions 1.2 or earlier.

Unless you force a specific SSH version when connecting (SSHOPENblah/VERSION:1), K95 negotiates the version
automatically. The negotiated version is shown in the Terminal-screen status
line, e.g. "SSH-2.0".

As with all Kermit's other features, the SSH client is configurable by the
user in every conceivable way (so anybody who doesn't like its defaults or
behavior can change them) and it includes built-in key creation and management
tools so no external "helper applications" are required.

The K95 implementation of SSH has been tested in connections to Solaris,
HP-UX 8.00 and above, Linux, OpenBSD, FreeBSD, and VMS ...

The following is a list of things to watch out for in the Kermit 95
implementation:

K95 tries to negotiate SSH v2 by default so if you try to connect to an
SSH V1 server, it might take a long time. In such cases, use "sshhost/version:1" to get an immediate connection.

Stairsteps. SSH servers on some Unix systems (usually old ones but
reportedly also some new ones too) do not translate LF to CRLF, so lines come
out on your screen in stairstep fashion. You can usually fix this by giving
an "stty sane" command at the Unix host prompt, or by telling Kermit to "set
terminal newline on". Other SSH clients behave exactly the same way with the
same hosts.

Some SSH servers do not break the connection when you log out. If you
log out but Kermit stays in its terminal screen, use Alt-u to disconnect.
(The same thing happens with other SSH clients.)

SSH compression is enabled by default. It improves performance on fast
machines, but might slow things down when the CPU is the bottleneck,
especially on fast LAN connections. Compression is important, however, for
modem connections (e.g. PPP) because the encrypted data stream can't be
compressed by the modem.

Both the Windows and OS/2 versions of Kermit 95 support SOCKS 4. In Windows
there is no nameserver support; local username is retrieved from Windows.
Requires SOCKS_SERVER environment variable and SOCKS.CONF file in the
/ETC directory. Command: SET TCP SOCKS-SERVER host.

C-Kermit 8.0 can be compiled with support for Kerberos 4, Kerberos 5, Secure
Remote Password, and OpenSSL's SSLv3 and TLSv1. As of this writing the
following combinations of platforms and security protocols are provided in the
Makefile distributed with C-Kermit:

Kerberos IV and Kerberos V support is available for Unix versions of C-Kermit
8.0. Kerberos support in C-Kermit is provided for both outgoing and incoming
connections (SET HOST /SERVER * port /TELNET or the Internet Kermit Service).

Kerberized C-Kermit binaries are not available due to export restrictions (see
Section 2); you must build your own binary from a
combination of Columbia source code and Kerberos libraries from other sources.

Retrieve a Kerberos 5 1.2.2 or later source code kit from the appropriate
site:

Build and install Kerberos on your system according to the instructions
that come with the Kerberos distribution you have chosen.

Add a new entry to the C-Kermit makefile for your platform that
uses "krbmit" as the build target and adds the following to CFLAGS:

-DCK_AUTHENTICATION -DCK_KERBEROS

For Kerberos 4 include:

-DKRB4 $(K4INC)

For Kerberos 5 include:

-DKRB5 $(K5INC)

For Kerberos 5 with Kerberos 4 compatibility mode:

-DKRB5 -DKRB524 -DKRB4 $(K5INC)

If you desire DES and 3DES encryption include:

-DCK_ENCRYPTION -DCK_DES

Add the appropriate libraries to LIBS. For Kerberos 4 include:

$(K4LIB) -lkrb

For Kerberos 5 include:

$(K5LIB) -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto

For Kerberos 4 compatibility mode with Kerberos 5 include:

$(K5LIB) -ldes425 -lkrb4 -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto

The makefile defines the path to the Kerberos header files using the
variables K4INC or K5INC:

-I/usr/kerberos/include

The location of the Kerberos libraries is specified using the variables
K4LIB or K5LIB:

-L/usr/kerberos/lib

The Kerberos header files and libraries are often installed in host specific
locations. The values of the K4INC, K5INC, K4LIB, and K5LIB variables can
be altered by:

Editing the makefile

Defining new values on the make command line

Exporting the variables to the system environment and specifying the
-e on the make command line.

Use the "linux+krb5", "linux+krb5+krb4", and
"sunos41gcc+krb4" makefile entries as models.

Note that the select() version of the CONNECT-command module
(ckucns.c) must be used rather than the older fork() based
(ckucon.c) version.

When C-Kermit 8.0 is built with Kerberos support and installed as an Internet Kermit Service
Daemon (IKSD), Kerberos is offered for authenticating incoming connections
if there is a valid keytab file providing local access to the key necessary
for decrypting messages encoded in the server's key.

Note: Due to conflicts between the internal DES implementations used by MIT
Kerberos 4 (not the Kerberos 4 compatibility mode provided by Kerberos 5) and
OpenSSL, C-Kermit cannot be built to support Kerberos 4 FTP authentication
when both OpenSSL and Kerberos 4 are used in combination.

Secure Remote Password (SRP) support is available for Unix versions of
C-Kermit 8.0. SRP support in C-Kermit is provided for both outgoing and
incoming connections (SET HOST /SERVER * port /TELNET or the Internet
Kermit Service).

SRP C-Kermit binaries are not available due to export restrictions (see
Section 2); you must build your own binary from a
combination of Columbia source code and SRP libraries from other sources.

There are several different methods for configuring the build process
of SRP. Two methods are supported for use with C-Kermit. The recommended
way is to build SRP using OpenSSL to provide the required big number math and
cryptographic functionality. DES/3DES functionality is built into OpenSSL.

The second method is to build SRP with the
GNU MP library for big number math and use SRP's Krypto library for the
cryptographic functionality. If

Regardless of which method you decide to use, be sure to read
the installation instructions before installing because SRP replaces many
standard Unix system files and failure to follow the procedures may leave
you locked out of your system.

Add a new entry to the C-Kermit makefile for your platform that:
uses "srpmit" as the build target and adds the following CFLAGS:

-DCK_AUTHENTICATION -DCK_SRP $(SRPINC)

If you built SRP with OpenSSL add:

$(SSLINC)

If you desire telnet encryption include:

-DCK_ENCRYPTION

For CAST encryption add:

-DCK_CAST

For DES and 3DES encryption add:

-DCK_DES -DLIBDES

Add the appropriate libraries to LIBS. If you built SRP using OpenSSL:

$(SRPLIB) -lsrp -lkrypto $(SSLLIB) -lcrypto

If you built SRP with GNU MP but without DES/3DES support use:

$(SRPLIB) -lsrp -lgmp -lkrypto

If you built SRP with GNU MP and Eric Young's DES library use:

$(SRPLIB) -lsrp -lgmp -ldes -lkrypto

The makefile defines the path to the SRP header files using the variable
SRPINC:

-I/usr/local/include

The location of the Kerberos libraries is specified using the variable SRPLIB:

-L/usr/local/lib

The makefile defines the path to the OpenSSL header files using the
variable SSLINC:

-I/usr/local/ssl/include

The location of the OpenSSL libraries is specified using the variable
SSLLIB:

-L/usr/local/ssl/lib

The SRP and OpenSSL header files and libraries are often installed in host
specific locations. The values of the SRPINC, SRPLIB, SSLINC, and SSLLIB
variables can be altered by:

Editing the makefile

Defining new values on the make command line

Exporting the variables to the system environment and specifying the
-e on the make command line.

Use the "linux+srp" and
"linux+krb5+krb4+srp" makefile entries as models.

Note that the select() version of the CONNECT-command module
(ckucns.c) must be used rather than the older fork() based
(ckucon.c) version.

When C-Kermit 8.0 is built with SRP support and installed as an
Internet Kermit Service
Daemon (IKSD), SRP is offered for authenticating incoming connections.

OpenSSL support is available for Unix versions of C-Kermit 8.0. SSLv3 and
TLSv1 support in C-Kermit is provided for both outgoing and incoming
connections (SET HOST /SERVER * port /TELNET or the Internet Kermit Service).

OpenSSL C-Kermit binaries are not available due to export restrictions (see
Section 2); you must build your own binary from a
combination of Columbia source code and the OpenSSL libraries from other
sources.

Build OpenSSL according to the installation instructions. Be aware that
OpenSSL includes support for algorithms that are covered by patents or
claimed as intellectual property in the United States (and perhaps some other
countries.) Use of these algorithms without the proper licenses can make you
liable to legal action. Be sure to read the entire README file before
building and installing OpenSSL.

OpenSSL has many features that can be selected when it is configured prior to
compiling the libraries. One feature that's useful to C-Kermit is support for
Anonymous-Diffie-Hellman (ADH) ciphers in SRP and Kerberos 5 Telnet
Authentication.

Note: If you are using a version of OpenSSL later than SNAPSHOT 20011201 you
can build it with support for ZLIB compression and Kerberos 5 ciphers.
However, OpenSSL releases prior to version 1.0 are not guaranteed to be
backward compatible. C-Kermit 8.0 builds with any 0.9.6 version of OpenSSL.
C-Kermit 8.0 might not build with future versions of OpenSSL without
modification.

Add a new entry to the C-Kermit makefile for your platform that uses
"krbmit" as the build target and adds the following to CFLAGS:

-DCK_AUTHENTICATION -DCK_SSL $(SSLINC)

To add support for ZLIB compression add the following to CFLAGS:

-DZLIB

Add the appropriate libraries to LIBS:

$(SSLLIB) -lssl -lcrypto

For ZLIB compression add to LIBS:

-lzlib

The makefile defines the path to the OpenSSL header files using the
variable SSLINC:

-I/usr/local/ssl/include

The location of the OpenSSL libraries is specified using the variable
SSLLIB:

-L/usr/local/ssl/lib

The OpenSSL header files and libraries are often installed in host specific
locations. The values of the SSLINC and SSLLIB variables can
be altered by:

editing the makefile

defining new values on the make command line

exporting the variables to the system environment and specifying the -e
on the make command line.

Use the "linux+openssl" and
"linux+krb5+krb4+srp+openssl" makefile entries as models.

Note that the select() version of the CONNECT-command module
(ckucns.c) must be used rather than the older fork() based
(ckucon.c) version.

When C-Kermit 8.0 is installed as an Internet Kermit Service (IKSD), TLSv1
is offered for authenticating incoming connections via the Telnet START_TLS
option.

If you wish to provide support for authentication of clients using public
key certificates you must provide two custom functions X509_to_user()
and X509_userok. These functions
provide the certificate to local userid mapping and user authorization
functionality. Example functions that
use the /UID field of the Certificate Subject name may be activated by
specifying:

make entry KFLAGS=-DX509_UID_TO_USER

when compiling C-Kermit. If you with to use the Certificate Subject Alternate
Name you can specify:

make entry KFLAGS=-DX509_SUBJECT_ALT_NAME_TO_USER

The X509_to_user() and X509_userok()
functions are the last functions in the ck_ssl.c module. See
Appendix III.

Shadow password files are used in many versions of Unix to provide a greater
level of security for user passwords stored on the local disk. The standard
Unix password file must be world readable so processes can find out the user's
shell, home directory, and other permissions. By moving the passwords into a
separate file that only stores passwords, access to the file can be restricted
to only those processes that are authorized to perform authentication.

When C-Kermit 8.0 is used as the Internet Kermit Service on systems that are
configured to use shadow passwords the following CFLAG must be added to the
makefile entry:

PAM is implemented in many versions of Unix so system administrators can
add new forms of authentication for interactive login (console, telnet,
rlogin, ...) without requiring recompilation of each service.

When C-Kermit 8.0 is used as the Internet Kermit Service on systems that are
configured to use PAM the following CFLAG must be added to the makefile
entry:

-DCK_PAM

and the following libraries may have to be included:

-lpam -ldl

The default PAM Service Name is "kermit". If you wish to use a different
name specify:

KFLAGS=-DPAM_SERVICE_NAME="service-name"

when building C-Kermit.

Before C-Kermit can be used with PAM, configuration information must be added
for the specified PAM_SERVICE_NAME to either /etc/pam.conf or
/etc/pam.d/ depending on the version of PAM your operating system has
installed. A complete primer on PAM can (or once could be) be found at:

Other protocols can be used to create secure connections that are not
currently implemented in Kermit, such as Secure Shell (SSH). The fact that
SSH is not integrated into Kermit software does not mean that Kermit cannot be
used in conjunction with it. SSH provides for tunneling, which allows a
localhost proxy to be configured to take insecure connections on the local
machine and connect them via secure connections to remote hosts.

Secure connection clients can be used as the communication channel in C-Kermit
7.0 and later and Kermit 95 1.1.16 and later via the PTY (Unix only) and PIPE
commands. See
Section 2.7
of the
C-Kermit 7.0 Update
Notes for details.

Firewalls based on access lists, proxies, and SOCKS do not provide secure
connections. However, they do restrict the ports that may be used to
communicate between the Internet and the Intranet which makes it more
difficult for someone to break into the Intranet from outside. They do not
protect the network from internal attacks nor do they protect a connection,
once made, from eavesdropping or hijacking. They may be used in conjunction
with secure connection systems but should not be used as a replacement for
them. C-Kermit can be built as a SOCKS client if you have a SOCKS library;
otherwise you can run SOCKSified Telnet or Rlogin clients through C-Kermit
with the PIPE command. See Section 8.1.1 of
the C-Kermit
Configuration Options document for details.

Valid only when Kermit is accepting a connection. This
variable contains the name of the user that has been
authenticated as opposed to \v(userid) which contains the
name the user chose to login as. This distinction is
important for \v(authstate) = "user" since this means that
although we were able to authenticate the user as \v(authname)
we could not verify that she has authorization to access
the account of \v(userid).

\v(authstate)

String indicating current state of authentication:

"rejected" - Rejected or otherwise not authenticated
"unknown" - Anonymous connection
"other" - We know him, but not his name
"user" - We know his name
"valid" - We know him, and he needs no password

All Kerberos functions require the Kerberos version number, 4 or 5, as the
first argument (n).

\fkrbtickets(n)

The number of active Kerberos n (4 or 5) tickets. This resets the
ticket list used by \fkrbnextticket(n).

\fkrbnextticket(n)

The next ticket in the Kerberos n (4 or 5) ticket list that was set
up by the most recent invocation of \fkrbtickets(n).

\fkrbisvalid(n,name)

The name is a ticket name, as returned by
\fkrbnextticket(n). Returns
1 if the ticket is valid, 0 if not valid. A ticket is valid if all the
following conditions are true:

it exists in the current cache file;

it is not expired;

it is not marked invalid (K5 only);

it was issued from the current IP address

This value can be used in an IF statement, e.g.:

if \fkrbisvalid(4,krbtgt.FOO.BAR.EDU@FOO.BAR.EDU) ...

\fkrbtimeleft(n,name)

The name is a ticket name, as returned by
\fkrbnextticket(n). Returns
the number of seconds remaining in the ticket's lifetime.

\fkrbflags(n,name)

The name is a ticket name, as returned by
\fkrbnextticket(n). Returns the flags string as reported with
AUTH K5 LIST /FLAGS. This string can be searched for a particular
flag using the \findex() function when SET CASE is ON (for case
sensitive searches). Flag strings are only available for K5 tickets.

Kerberos 5 functions operate against the current credential-cache file as set
by SET AUTHORIZATION K5 CREDENTIALS-FILE filename.

The \v(authstate) variable tells the script which level of
authentication has been achieved. If the value is "valid" that means that the
account specified by \v(userid) has been authenticated and authorized
for use by \v(authname). If the value of \v(authstate) is
"user" then \v(authname) has been authenticated but she does not have known
authorization to access the account \v(userid). This usually means
that some additional verification is needed.

IF EQ "\v(authstate)" "valid" {
proceed without further authorization
}
IF EQ "\v(authstate)" "user" {
perform further authorization before providing service
}

It is important to realize that when a Kermit script is used in this manner,
the Telnet negotiations provide authentication of the user and potentially
encryption of the data communication. There is no facility in a Kermit script
to change the ownership of the currently running process from the user that
started it to the user ID of the authenticated user. This means that the
script the authenticated user is accessing has all of the privileges of the
process executer and not the authenticated user.

Another important fact to remember is that secure access to an insecure
environment is not secure. If you are using Windows 95 or 98 to run scripts,
while it is possible to use Kerberos or SRP to authenticate the incoming
clients, the insecure nature of the Windows environment means that it is
impossible for the Kerberos service key tables and SRP password databases to
be protected from tampering; the security in this case is no stronger than
than the security of Windows 9x.

Contrary to widespread misconception, Telnet and FTP are not insecure
protocols to be discarded. These protocols have been secured by the IETF
through the addition of standard security methods: Kerberos, SSL/TLS, and SRP
(see REFERENCES) and continue to offer manifold
advantages over their would-be replacements in terms of functionality,
flexibility, and platform independence. If your operating system does not
include secure remote access methods, secure third-party servers can often be
found.

The Kerberos 5 Telnet server is part of the standard Kerberos 5
distribution available from MIT. Kerberos 5 is unique among authentication
methods in offering true single sign-on capability to the network via
forwarded credentials. It also allows authentication to cross Kerberos
realms; for example, between different organizations.

The Kerberos 5 Telnet server is "downwards compatible" with the older Kerberos
4 protocol. The Kerberos 5 Telnet authentication protocol provides for strong
mutual authentication of the client and server without requiring the client to
possess prior knowledge of the server's credentials. During authentication a
session key (DES, RC4, 3DES) is produced that is used with a negotiated
encryption algorithm to give privacy protection to incoming and outgoing
data.

Follow the links to "Getting Kerberos from MIT". Future versions of
the MIT Kerberos 5 distribution will include support for
SSL/TLS and X Windows System Data Forwarding.

MIT Kerberos 4

The precursor to Kerberos 5. Kerberos 4 provides strong authentication
without the single sign-on or cross-realm capabilities of Kerberos 5. The
Kerberos 4 Telnet server is part of the Kerberos 4 distribution.

The Kerberos 4 Telnet authentication protocol provides for strong mutual
authentication of client and server without requiring prior knowledge by the
client of the server's credentials. During authentication a session key
(56-bit DES only) is produced for use with a negotiated encryption
algorithm for privacy of incoming and outgoing data.

SRP is based on Zero Knowledge Identification algorithms by which the
client and server prove their identities by exchanging data over a public
channel. This data can't be used to determine the secrets involved nor can it
be used to replicate the authentication sequence. Authentication of the
server does not require the client to have prior knowledge of the server's
credentials. During authentication a session key (320-bits) is produced for
use with a negotiated encryption algorithm to provide privacy protection to
incoming and outgoing data. As of the 1.7.1 release, the SRP Telnet client
and server implement the START_TLS option as well as the X Windows Systems
Data Forwarding option. This distribution can be built against MIT Kerberos 5
or MIT Kerberos 4 distribution to enable Kerberos authentication. The
combination of START_TLS and AUTH (SRP and KRB5) provide for the strongest
combination of private communication and password based mutual
authentication.

TLSv1 (the successor to SSLv3 used in most Web browsers) provides strong
encryption and optional authentication of the server and client using X.509
certificates or Kerberos 5. Authentication of the server via X.509 requires
the client to have prior knowledge of the server's X.509 certificate or the
certificates of the Certificate Authorities that signed the server's
certificate. An open source distribution of TLSv1 is available from:

The Kerberos 5 FTP server is part of the standard Kerberos 5 distribution
available from MIT. Kerberos 5 is unique among authentication methods in
offering true single sign-on capability to the network via forwarded
credentials. It also allows authentication to cross Kerberos realms; for
example, between different organizations.

The Kerberos 5 FTP server provides for strong authentication using either
Kerberos 4 or GSSAPI-Kerberos 5. Both the command and data channels are
encrypted and integrity protected.

Follow the links to "Getting Kerberos from MIT". Future versions of
the MIT Kerberos 5 distribution will include support for
SSL/TLS and X Windows System Data Forwarding.

MIT Kerberos 4

The precursor to Kerberos 5. Kerberos 4 provides strong authentication
without the single sign-on or cross-realm capabilities of Kerberos 5. The
Kerberos 4 Telnet and FTP clients and servers are part of the Kerberos 4
distribution.

The Kerberos 4 FTP server provides for strong authentication. Both the
command and data channels are encrypted and integrity protected.

SRP is based on Zero Knowledge Identification algorithms by which the
client and server prove their identities by exchanging data over a public
channel. This data can't be used to determine the secrets involved nor can it
be used to replicate the authentication sequence. Authentication of the
server does not require the client to have prior knowledge of the server's
credentials. During authentication a session key (320-bits) is produced
for use with a negotiated encryption algorithm to provide privacy protection
to incoming and outgoing data.

The FTP server provides for strong authentication. Both the command and
data channels are encrypted and integrity protected with a user selectable
set of encryption algorithms (blowfish, cast-128, 3des, des) and hash
algorithms (md5, sha-1).

TLSv1 (the successor to SSLv3 used in most Web browsers) provides strong
encryption and optional authentication of the server and client using X.509
certificates or Kerberos 5. Authentication of the server via X.509 requires
the client to have prior knowledge of the server's X.509 certificate or the
certificates of the Certificate Authorities that signed the server's
certificate. An open source distribution of TLSv1 is available from:

The OpenSSH Project distributes SSH servers. To add the extra security of SRP
and/or GSSAPI authentication, they must be patched. First download the
OpenSSH source code, then use the 'patch' program to apply the desired
patches:

The Internet was originally designed for end-to-end communication between
connected computers belonging to a single cloud. All computers were able to
directly communicate with all the other computers attached to the network.
In particular, if computer A could communicate with computer B then computer B
could communicate with computer A. Unfortunately, this no longer true.

Three factors changed this. First, the abuse of the Internet by hackers and
virus/worm authors convinced organizations that wished to join the internet
that it was not safe to do so without limiting their exposure. This resulted
in the popular use of firewalls to restrict the types of communications that
could flow across the Internet gateways.

The second factor was the success of the world wide web and the use of client
only computers that did not have permanent addresses. These computers (mostly
DOS, Windows, and Macintosh) did not run services and were only used to
communicate with a very small number of server computers that spoke HTTP.
Connectivity to these machines only required one way communication: from the
client to the server.

The third factor was the explosion in the number of client devices that are
connected to the Internet. When an individual or company wants to connect
their computers to the Internet they need to be assigned IP addresses for
their computers. However, most ISPs sell service based on the number of
assigned IP addresses or, in the case of home networks, provide only a single
address. To save money or simply two put all the kids' computers on the
network at the same time, people started to experiment with network gateways
that implemented Network Address Translation (NAT). The NAT would convert the
IP addresses of multiple computers on the private side of the gateway to share
a single address on the public side of the gateway. A computer that has been
assigned an address that is being translated can establish and listen for
connections with other computers on the private side of the network and can
establish connections to computers on the public side of the network.
However, the computers cannot receive connections established from computers
on the pubic side of the network because the true address of the computer has
been hidden.

These factors complicate the use of many Internet protocols such as FTP and
cause problems for authentication systems. In addition to these problems
there are some other issues that must be taken into account. It is possible
for a single computer to have multiple network adapter cards. This is often
done to allow a computer to act as a gateway between two networks; to provide
the computer with redundancy for critical services; or to allow the computer
to maintain more than one identity (such as to provide web services for two
different domains.) Computers with multiple network addresses are referred to
as being "multi-homed".

There are also potential problems caused when multiple computers are used to
serve a single purpose. For instance, a web server for a large commercial
operation probably does not have a single computer providing service to all of
their customers. Instead they have a farm (or cluster) of computers. The one
you actually are served by is determined randomly using a load-balancing
algorithm. When you authenticate to one of these computers you do not want to
authenticate to the individual name assigned to each computer but to the
common name used to access any one of them. The technique used to allow
multiple computers to respond to a single name is called "aliasing".

Firewalls are used to restrict the types of network packets that may cross
a network boundary. Firewall products fall into four general categories:

Port Filtering Firewalls

Port Filtering firewalls are the simplist of the firewall techniques.
Port filtering is performed by specifying an ordered set of ACCEPT and DENY
rules for each combination of:

packet type

source address

source port

destination address

destination port

if packet type is TCP, whether a connection must exist or not

This allows a firewall to be configured to only allow through the firewall
packets that are meant for specific computers; or packets meant for specific
services; or packets to/from specific hosts/networks.

Port Filtering firewalls frequently cause problems for users of Kerberos
authentication when they are not configured to allow UDP packets to be
sent or received from the Key Distribution Center.

Port Filtering firewalls are also a problem for the FTP protocol since the
standard mode is for the FTP server to establish a data channel on a random
port number to the FTP client when data is to be transferred. This port
number is agreed to be sending the destination address and port value across
the FTP command channel.

Port Filtering firewalls need to be configured to allow connections
from clients to reach the host ports necessary for each protocol that is
used with Kermit:

Port

Protocol

21/tcp

FTP

22/tcp

SSH

23/tcp

Telnet

80/tcp

HTTP

88/udp

Kerberos 5 authentication

443/tcp

HTTP over TLS

750/udp

Kerberos 4 authentication

990/tcp

FTP over TLS

992/tcp

Telnet over TLS

1649/tcp

Internet Kermit Service (Kermit)

The official list of "well-known" and "registered" port assignments is
available from Internet Assigned Numbers Authority:

Content-Aware Firewalls attempt to solve the problem with FTP and similar
protocols that transmit addressing information as part of the protocol.
These firewalls are aware of a specific set of internet protocols such as FTP.
When the FTP client specifies the destination address and port to used by the
server to establish the data channel, the firewall can watch and temporarily
allow that connection to pass through the firewall. Unfortunately, Content
Aware Firewalls cannot work with secure protocols since all of the data is
being transmitted in encrypted form.

Application Layer Gateways

Application Layer Gateways are services that appear to be the actually
service you wish to connect to. Instead of connecting directly to the telnet
service on foo.bar.com you connect to the telnet service on the firewall and
allow the firewall to establish an equivalent session with the telnet service
on foo.bar.com.

As with Content-Aware Firewalls this procedure simply does not work with
secure connections. The Application Layer Gateway (ALG) will either not know
the key to use to read the protected data; or the ALG will be able to
decrypt all of the data and the end-to-end security of the connection
know has a location where a man-in-the-middle attack can be targeted.

Authenticated Firewall Traversal Protocols

Authenticated Firewall Traversal Protocols simply allow a client process
running on a computer to create connections that may cross the firewall once
the client or service has been authenticated and authorized. These firewalls
are quite flexible and work very well with secure connections. In fact, they
enhance the security of the connection from the perspective of the network
administrator.

FTP is one of the few well-known Internet services that requires the use of
multiple connections. As described above, FTP originally required the server
to establish the data connection to the client using a destination address and
port provided by the client. This method of operation does not work with Port
Filtering Firewalls.

More recently, FTP was extended to support "passive mode". When passive mode
is use the connections for the data channels are created in the reverse
direction. Instead of the server establishing a connection to the client; the
client establishes a second connection with server as the destination. This
works just fine as long as the client is behind the firewall and the server is
in public address space. If the server is behind a firewall then the
traditional mode must be used. If both the client and server are each behind
their own Port Filtering Firewalls then data channels cannot be established.

This is supposed to be solved by the use of Content Aware Firewalls or
Application Layer Gateways. However, was the command channel is encrypted
the Firewall is unable to view the IP address information.

The simplist form of firewall traversal is the HTTP CONNECT command. The
CONNECT command was implemented to allow a public web server which usually
resides on the boundary between the public and private networks to forward
HTTP requests from clients on the private network to public web sites. In
order to allow secure web connections to be established, the CONNECT command
works by authenticating the client with a username/password and then
establishing a tunnel to the desired host.

Many web servers support the CONNECT command and it can be configured to allow
outgoing connections to authenticated user to any TCP/IP hostname/port
combination accessible to the web server. The limitations of HTTP CONNECT is
that it can only be used for outgoing connections for protocols that are
implemented using TCP/IP. Protocols such as Kerberos authentication that use
UDP/IP cannot be tunneled using HTTP CONNECT.

Kermit provides support for the use of HTTP CONNECT proxy services with the
command:

SET TCP HTTP-PROXY hostname/ip-address[:port]

When a port is not specified the default port configured on the HTTP server is
used. This is frequently port 443. When a hostname is specified, it is
resolved using the DNS available to the web server.

In the early 1990s as firewalls were becoming prevalent, David Koblas
developed the SOCKS protocol for firewall traversal of TCP/IP. There are two
popular versions of SOCKS currently in use. Version 4.2 provides support for
client applications using TCP/IP to traverse firewalls. This functionality is
similar to the support provided by HTTP CONNECT. However, there is one
distinction. A client using SOCKS is aware of the public source IP address
and port. This allows this information to be used within the application
protocol to assist in securing the connection. (This information is crucial
to securing FTP sessions with GSSAPI Kerberos 5.)

After 1995, the IETF began working on a successor to the SOCK 4 protocol.
This work produced SOCKS Version 5
(RFC 1928).
SOCKS 5 is significantly more general than version 4. In addition to
supporting client to server TCP/IP connections, it provides two crucial sets
of functionality not found in previous protocols:

Authenticated firewall traversal of UDP/IP packets.

Authenticated binding of incoming public ports on the firewall.

This allows a service on the private network to offer public services. It
also allows client applications such as FTP to establish a temporary public
presence that can be used by the FTP server to create a data channel. By
allowing the client bind to a public port on the firewall and be aware of the
public address, SOCKS 5 allows the application protocol to communicate that
information to the server.

C-Kermit can be built using either SOCKS 4 or SOCKS 5. Configuration of the
SOCKS servers is determined by the requirements of the SOCKS library.

It should be noted that the best part about the SOCKS protocols is that each
and every application does not need to implement them. Instead, SOCKS can
be built into the IP stack on each host operating system and the protocols
could work transparently without any change to the programs already shipped.

Network Address Translation (NAT) is a technique used to allow a single public
IP address provided by an Internet Service Provider (ISP) to be shared among
multiple computers on a private IP based network. NAT technology is often
found in routers designed for the Home and Small Office market. This
technique is wonderful as long as the application protocols being used do not
require knowledge of the IP addresses being used. In fact, NATs when combined
with SOCKS Version 5 would be a perfect solution except that we have never
seen a product that combines these two technologies. (It is most likely a
chicken-and-egg situation. No client applications support SOCKS 5, therefore
no router manufacturers feel pressure to produce them. Since no routers
support SOCKS 5, application vendors do not implement it.)

NAT has particularly bad implications for Kerberos authentication that
traditionally embeds into the ticket the IP addresses on which the ticket is
valid. Another protocol that is adversely affected by NAT is FTP. However,
FTP passive mode works around it.

As luck would have it. Kerberos 4 has no problem with NAT because the
Kerberos 4 ticket has room for only a single IP address and that IP address is
assigned not by the client but by the KDC. The result is that when Kerberos 4
is used from behind a NAT the IP address that is placed into the ticket is the
public IP address of the NAT, not the IP address of the client machine. This
means the ticket is good only on the far side of the NAT and not on the near
side.

Kerberos 5 on the other hand is seriously affected by NAT.
The addresses are stored in the ticket by the client. This allows the
ticket to support the multiple addresses needed for multi-homed systems.
However, when NAT is used, it is the private IP address that is stored into
the ticket and not the public address seen by the KDC. If this ticket is
now used to access a service on the public network, the service rejects
the Kerberos 5 ticket since the IP address in the ticket does not match the
source IP address used to establish the connection.

This can be worked around if the client uses a kinit that allows a list of
additional IP addresses to be specified for inclusion in the TGT.
Kermit supports this capability with one of the following commands:

The problem with this solution is that, although it is secure, in most cases
the end user does not know which IP address is assigned to the far side of the
NAT. In this situation it is necessary to remove all IP addresses from the
TGT. Kermit provides the AUTH K5 INIT /NO-ADDRESSES and SET AUTH K5
NO-ADDRESSES ON commands for this purpose. However, this solution is less
secure since a TGT with no specified IP addresses can be used from any
machine. Stolen TGTs are therefore extremely useful to a thief. We strongly
advise that removing the IP address information from Kerberos 5 tickets not be
performed on computers using file based caches as they are particularly
vulnerable to theft.

Sometimes it is possible to read the public address from the device providing
NAT, as shown in the following Kermit script:

IP socket connections are established using IP addresses and port numbers.
Human beings do not remember large groups of numbers well. Instead we
remember do a better job remembering names. The Domain Name Service (DNS) is
globally distributed database that converts between the names that humans
recognize and the IP addresses that allow the desired service to be
communicated with.

There are two situations where multiple IP addresses can be associated with
the same computer or service. The first is a computer that has multiple
network interfaces. This is known as a multi-homed computer. Each interface
is assigned its own IP address. The second situation is where a DNS name
resolves to multiple computers. This is referred to as aliasing. Both can
play havoc with authentication when using either Kerberos or X.509
certificates. Kermit is designed to support multi-homed computers and those
with multiple names. Unfortunately, not everything else is.

Kerberos 4 does not support multi-homed computers. Its ticket format only has
space for a single IP address. If you are using Kermit as a client with
Kerberos 4 authentication you must be sure to set the network interface you
use for establishing your connections to match the one stored in the Kerberos
4 ticket. The ticket address can be viewed with the command:

AUTH K4 LIST

The interface to be used can be configured with:

SET TCP ADDRESS

There is no method for automating this process at the current time.

Kerberos 5 has no problem with multihomed hosts because the ticket supports
multiple IP addresses and those IP addresses are inserted into the ticket by
the client, not by the KDC.

There can also be problems when a host is being accessed through a
DNS alias. The administrator for the host needs to install the
service keys for both the unique hostname and the alias name in the
Kerberos 4 service key file. When this is not done it can lead to
problems because the service key retrieved by the client does not
match the one used by the service.

Kermit attempts to compensate for this by resolving the DNS alias to real
hostname. However, this does not always work on Windows 95 or Windows NT 3.5x
due to their caching of DNS information. For instance, at Columbia University
the CUNIX name resolves to one of six machines, each with a different name,
such as HOSTA, HOSTB, etc. When telneting to CUNIX, you might be given IP
address 128.59.35.136. But even though the DNS servers are properly
configured to return the proper name (e.g. HOSTB) for that IP address, Windows
95 returns CUNIX because it retrieves the information from its internal cache
instead of performing another network call. This means that instead of
retrieving a Kerberos 4 ticket for the service:

rcmd.hostb@CC.COLUMBIA.EDU

we get a ticket for:

rcmd.cunix@CC.COLUMBIA.EDU

This use of the wrong ticket produces the following error:

Can't decode authenticator (krb_rd_req)

DNS aliases and multiple addresses can be a problem for connections protected
with SSL/TLS. To maximize their revenue streams, most commercial certificate
authorities do not issue certificates with multiple hostnames and/or IP
addresses. Therefore the hostname used to access the service has to match the
one that used in the certificate. Although Kermit can resolve aliases to
unique hostnames for Kerberos, it cannot do so for X.509 certificates.

When you are acting as your own Certificate Authority using the OpenSSL tools
you can produce certificates containing multiple hostnames and IP addresses.
Kermit authenticates connections correctly when presented with these
certificates.

Public key (asymmetric) cryptography defines a class of algorithms for key
exchange that include RSA and Diffie-Hellman (DH). These algorithms provide a
mechanism to create a shared secret that can be used for encrypting future
communications. Anyone listening to the exchange would be no closer to
figuring out the value of the shared secret than if they were to take a guess.

There are two parts to the exchange. A private key that is never disclosed,
and a public key that may be viewed by all. An X.509 certificate is a
standard package for distributing a public key with identifying features such
that the authenticity and validity of the public key may be verified by a
recipient.

The authenticity and validity of a certificate is provided by a combination of
information provided within the certificates (the subject, the issuer, dates
of validity, ...) as well as the trust that is placed in the certificate
issuer (the Certificate Authority, or CA). The CA signs each of the
certificates that it issues with its own certificate. With a copy of the CA's
certificate it is possible to validate all of the certificates that were
signed by the CA's private key.

A user who wants to have a certificate signed by a CA creates a Certificate
Signing Request (CSR). The CSR is an unsigned certificate presented
to the CA along with information verifying the identity and desired use for
the certificate. The CA signs the CSR producing a certificate that is valid
for a specific time frame, which is then returned to the user.

If the private key of the certificate were to be compromised the CA may revoke
the certificate. The CA publishes a Certificate Revocation List (CRL) on a
periodic basis containing a list of all certificates that would otherwise be
valid if they were not revoked. It is the responsibility of the verifier to
check not only the authenticity of the certificate but also whether or not it
has been revoked by the issuer.

The RSA algorithms are supported by all the major browsers whereas DSA
are not.

The RSA algorithms were patented in the United States (until Sept 29,
2000), requiring payments of licensing fees for producers of software
utilizing them, whereas DSA is free.

The RSA private and public key pairs may be used for encrypting data as
well as signing. DSA private and public key pairs may only be used for
signing. Therefore, products incorporating only DSA algorithms are easier
to export from the United States.

The root CA certificates of these companies certificates are included most of
the popular browsers. This provides an ease-of-use advantage to the
recipients of certificates they sign since the root certificates do not need
to be otherwise distributed to authenticate the signed certificates.

On the other hand, as is pointed out by C. Ellison and B. Schneier in their
paper, Ten Risks of PKI: What You're Not Being Told About Public Key
Infrastructure:

using the commercial CA services it makes it difficult to decide whether or
not a certificate should be trusted for a particular purpose, especially if
you want to use certificates to authenticate an end user to a system for
remote access. In this situation it is necessary to not only be able to
authenticate a certificate but be able to know that the information within the
certificate, such as the uniqueIdentifier used for the User ID, is tightly
controlled and in fact unique in your environment.

If you choose to be your own CA you will have to configure your environment.
Create the following directory trees to store the DSA and RSA CAs.

To avoid the need to specify the location of the openssl.cnf file, set the
environment variable OPENSSL_CNF to be equal to the full path of the file. If
you do not create this environment variable you must to include the option:

-config path/openssl.cnf

to each openssl command.

Create the file that stores the next available serial number for each CA:

openssl/dsaCA/ca.srl
openssl/rsaCA/ca.srl

The format of this file is a hex value followed by a LF (0x0A) character.
The value "01" is an appropriate initial value.

Create an empty file to store the index of signed certificates:

openssl/dsaCA/index.txt
openssl/rsaCA/index.txt

Now you are ready to create the DSA and RSA CA certificates for your
organization.

The days parameter should be replaced by the number of days you want
this certificate to remain valid. All certificates signed by this certificate
become invalid when this certificate expires.

Be sure to not forget the pass-phrase you use to protect the private key of
the CA certificate. If you do not wish to encrypt the CA's private key you
may specify the -nodes option. But this is highly discouraged.

where name should be replaced by something that identifies the files.
Perhaps the hostname or userid for which the certificate is being generated.

If you are generating a CSR for use as a host certificate, be sure to specify
the fully qualified domain name as reported by the DNS as the Common Name for
the certificate. Otherwise, it won't be recognized as belonging to the host
it is installed on by its clients.

Be sure not to forget the pass-phrase you use to protect the private key of
the CA certificate. The certificate (after signing) is unusable without it.
Use the -nodes option if you wish to store the key unencrypted.

You can check the contents of the CSR with the command:

openssl req -text -in requests/name-req.pem

The CSR now stored in requests/name-req.pem may be sent to one of the
commercial CAs if you do not wish to be your own CA.

The days parameter should be replaced by the number of days you want
this certificate to remain valid. All certificates signed by this certificate
become invalid when this certificate expires.

Be sure not to forget the pass-phrase you use to protect the private key of
the CA certificate. If you do not wish to encrypt the CA's private key you
may specify the -nodes option. But this is highly discouraged.

name should be replaced by something that identifies the files, such as
the hostname or userid for which the certificate is being generated.

If you are generating a CSR for use as a host certificate be sure to specify
the fully qualified domain name as reported by the DNS as the Common Name for
the certificate. Otherwise, it is not recognized as belonging to the host it
is installed on by its clients.

Be sure not to forget the pass-phrase you use to protect the private key of
the CA certificate. The certificate (after signing) is unusable without it.
Use the -nodes option if you wish to store the key unencrypted.

You can check the contents of the CSR with the command:

openssl req -text -in requests/name-req.pem

The CSR now stored in requests/name-req.pem may be sent to one of the
commercial CAs if you do not wish to be your own CA.

If you are signing a DSA certificate change directory to
openssl/dsaCA/ and use a caname of "CA_DSA". If you are
signing an RSA certificate change directory to openssl/rsaCA/ and use
a caname of "CA_RSA":

The "openssl x509" command provides greater functionality at the expense of
ease of use. The X509 may be used to assign X.509v3 certificate extensions
with the -extfile and -extensions switches. It may also be used to produce
certificates that may only be used for specific purposes.

If you are revoking a DSA certificate change directory to
openssl/dsaCA/ and use a caname of "CA_DSA". If you are
revoking an RSA certificate change directory to openssl/rsaCA/ and use
a caname of "CA_RSA".

openssl ca -name caname -revoke certs/name.pem

marks the certificate as being revoked in the index.txt file. It is
necessary to revoke a certificate with a given subject name if you wish to
generate a new certificate with an identical subject name. Once a
certificate is revoked it is listed in the next generated CRL.

If you are generating a CRL for your DSA certificates change directory to
openssl/dsaCA/ and use a caname of "CA_DSA". If you are
generating a CRL for your RSA certificate change directory to
openssl/rsaCA/ and use a caname of "CA_RSA":

openssl ca -name caname -gencrl -out crl/date-crl.pem

date should be replaced by the date the crl was generated.

You can check the contents of the CRL with the command:

openssl crl -in crl/date-crl.pem -text

The current CRL should be placed somewhere it is publicly and easily
accessible. For instance, by HTTP or FTP. The CRL is signed by the CA
certificate

Kermit can be configured to perform a mapping from an X.509 client certificate
to a User ID. This is primarily of use when Kermit is installed as an
Internet Kermit Service. When a mapping is enabled, the client certificate
may be used to authenticate and automatically login a user to their account or
resources.

Unfortunately, it is not possible to build a function in to Kermit to provide
the mapping from Certificate to User ID that would be secure and/or applicable
to every installation. There are several commonly used approaches to map a
certificate to a userid. Kermit can be customized to use whichever one
you choose to use in your environment.

Map the X.509 uniqueIdentifier field to the User ID

The uniqueIdentifier field of the X.509 client certificate can include the
userid of the end user. For instance, John Doe's uniqueIdentifier might be
jdoe. A mapping function can extract the contents of this field and
return it as the User ID.

The problem with this approach is the uniqueIdentifier may not be very unique.
Let us assume that you do not want to go through the trouble of managing your
own Certificate Authority because it is too much work. So you refer all of
your clients to request X.509 certificates from one of the commercial
Certificate Authorities. It is possible that another site is doing exactly
the same thing and that this other site has a user Jane Doe with User ID
jdoe. In this circumstance, simply verifying the certificate against
the CA certificate and extracting the uniqueIdentifier results in a
security hole since Jane Doe would be able to gain access to John Doe's
account.

Map the X.509 subjectAltName to the User ID

The subjectAltName field of the X.509 client certificate can include the
e-mail address of the user instead of simply the userid of the user. In the
case of John Doe, his subjectAltName would be jdoe@mydomain.com whereas
Jane Doe's subjectAltName would be jdoe@someotherdomain.com. A mapping
function using the subjectAltName can extract the contents of the
subjectAltName, verify the domain is correct and then return the User ID.

This method is safer than the uniqueIdentifier, but it is still placing a lot
of trust in the Certificate Authority. If you are not issuing the
certificates yourself you'll have to trust that the CA has a legitimate
method for verifying that the e-mail address belongs to the user for whom the
CA is signing a certificate.

Map the Entire Certificate to the User ID

Instead of trusting the contents of one of the fields within the
certificate you can require that your user's submit their certificates for
registration prior to use. The mapping function can then lookup the
certificate in a local database or an LDAP server to retrieve the User ID. Of
the methods described, this is the most secure.

In addition to determining which userid is associated with a given client
certificate, it is just as important to know whether or not the user is
actually authorized to access the service when the certificate is provided.

The X509_userok() function determines whether or not the combination
of the provided X509 certificate and username is valid for automatic login.
Whereas X509_to_user() is used to provide authentication of the user,
the X509_userok() function is used to provide authorization. The
certificate passed into X509_userok() does need to map to a userid;
nor would the userid it would map to need to match the userid provided to the
function. There are numerous circumstances in which it is beneficial to have
the ability for multiple users to gain access to a common account such as
'root' on Unix; or a class account on a web server.

In Unix this capability can be provided with a
~userid/.tlslogin file that contains a list of X509
certificates thatMay can be used to access the account userid.

X.509 to User ID mapping functions are implemented in Kermit 95 via the use of
a user compiled Dynamic Link Library (DLL), X5092UID.DLL. To build
this DLL you need a C compiler such as Microsoft's Visual C++ and OpenSSL
0.9.4 (or higher) compiled and installed.

On Windows, OpenSSL must be compiled and linked to use the NT DLL option
without Debug information. Compiling the DLLs with support for debugging
links the DLLs to an incompatible C Run Time Library DLL. On OS/2, OpenSSL
must be compiled to use the DLL version of the run time library.

X.509 to User ID mapping functions are implemented in C-Kermit in one of two
ways.

If you want to use the uniqueIdentifier field you can specify
KFLAGS=-DX509_UID_TO_USER at compile time.

If you want to use the subjectAltName field you can specify
KFLAGS=-DX509_SUBJECT_ALT_NAME_TO_USER at compile time.

Otherwise, you need to customize the X509_to_user() function in the
ck_ssl.c source file to implement your verification method.

A X509_userok() that supports the use of the ~userid/.tlslogin file
is provided. This function should be examined for compatibility with the
institutional access policies. It should be replaced or modified as needed.

Other protocols can be used to create secure connections that are not
currently implemented in Kermit, such as Secure Shell (SSH) in C-Kermit.
The fact that SSH is not integrated into C-Kermit does not mean that
Kermit cannot be used in conjunction with it. SSH provides for tunneling,
which allows a localhost proxy to be configured to take insecure connections
on the local machine and connect them via secure connections to remote hosts.

Secure connection clients can be used as the communication channel in C-Kermit
7.0 (and later) and Kermit 95 1.1.16 (and later) via the PTY (Unix only) and
PIPE commands. See
Section 2.7 of the
C-Kermit 7.0
Update Notes for details.

Firewalls based on access lists, proxies, and SOCKS do not provide secure
connections. However, they do restrict the ports that may be used to
communicate between the Internet and the Intranet which makes it more
difficult for someone to break into the Intranet from outside. They do not
protect the network from internal attacks nor do they protect a connection,
once made, from eavesdropping or hijacking. They may be used in conjunction
with secure connection systems but should not be used as a replacement for
them. (The Windows 95 and NT versions of Kermit 95 do not support SOCKS; the
OS/2 version has built-in support for SOCKS4. C-Kermit can be built as a
SOCKS client if you have a SOCKS library; otherwise you can run SOCKSified
Telnet or Rlogin clients through C-Kermit with the PIPE command.)

Kermit 95 provides an interface that allows it to use a DLL to provide an
alternative mechanism for implementing secure communication methods. The DLL
is loaded via a network type command:

SET NETWORK TYPE DLL dll-file

The connection is then made with a SET HOST command

SET HOST command-line

where the command-line is passed to the DLL after the normal Kermit
quoting rules are applied.

/* Kermit 95 - External Network DLL specification
* July 16 1998
* Jeffrey Altman <jaltman@columbia.edu>
*
* The following specification defines a set of functions to be exported from
* a DLL in order for the DLL to work with Kermit 95 version 1.1.17 or higher.
*
* The DLL is loaded by Kermit 95 via use of the command:
* SET NETWORK TYPE DLL dllname
*
* Notes:
* The functions specified here must be thread safe. It is possible
* for multiple threads to be calling any combination of functions
* simultaneously.
*
* The 1.1.17 interface does not provide for the ability of the
* DLL to query the user with echoing input, nor is the a method
* for querying the values of Kermit variables such as 'userid'
* or Kermit version number. This will be added in a later release.
*/
/*
* N E T O P E N - Network Open
*
* The network open function is called by Kermit 95 when a new connection
* is desired. Usually in response to:
* SET HOST command_line
*
* Parameters:
* command_line - the command line specified in the SET HOST command
* after quoting rules and variables have been applied.
* termtype - a string representing either the currently selected
* terminal type or a user specified string as per
* SET TELNET TERMINAL string
* height - initial height of the terminal window (chars)
* width - initial width of the terminal window (chars)
* readpass - a pointer to a function to be used to read a password
* without echoing
*
* Return values:
* 0 on success
* < 0 on failure
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netopen(char * command_line, char * termtype, int height, int width,
int (* readpass)(char * prompt,char * buffer, int length));
/*
* N E T C L O S - Network Close
*
* The network close function is called by Kermit 95 when the user requests
* a disconnect or in response to fatal error.
*
* Parameters: None
*
* Return values:
* 0 on success
* < 0 on failure
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netclos(void) ;
/*
* N E T T C H K - Network Terminal I/O Check
*
* The network terminal i/o check function is called regularly by Kermit 95
* to poll the status of the connection and to retrieve the number of input
* characters waiting to be processed. Because it is called frequently this
* function should be designed to be low cost.
*
* Parameters: None
*
* Return values:
* >= 0 number of characters waiting in the input queue
* < 0 indicates a fatal error on the connection and the connection
* should be closed.
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
nettchk(void);
/*
* N E T F L U I - Network Flush Input
*
* The network flush input function should clear the connection's input
* queue.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netflui(void);
/*
* N E T B R E A K - Network Break
*
* The network break signal is called in response to a user initiated
* break command. For example, on a serial device this should result in
* a Break signal and on a Telnet connection a Break Command is sent.
* For connection types without an equivalent simply return 0.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netbreak(void);
/*
* N E T I N C - Network Input Character
*
* The network input character is used to read the next character from
* the input queue.
*
* Parameters:
* timeout - 0 indicates no timeout, block until the next character
* is available;
* > 0 indicates a timeout value in seconds;
* < 0 indicates a timeout value in milliseconds;
*
* Return values:
* >= 0 is interpreted as a valid character
* -1 is a timeout [errorstr() is not called]
* < -1 is a fatal error
*
* return codes < -1 should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netinc(int timeout);
/*
* N E T X I N - Network Extended Input
*
* The network extended input is called to read a large number of waiting
* input characters. It will never be called with a number larger than
* reported as available and waiting by nettchk(). The function may return
* fewer characters than is requested. This function should not block.
*
* Parameters:
* count - number of characters to be read
* buffer - buffer of length count to be used to store the data
*
* Return values:
* >= 0 the number of characters actually returned by the function
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netxin(int count, char * buffer);
/*
* N E T T O C - Network Terminal Output Character
*
* The network terminal output character transmits a single character
*
* Parameters:
* c - a single character to be output
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
nettoc(int c);
/*
* N E T T O L - Network Terminal Output Line
*
* The network terminal output line is used to output one or more
* characters.
*
* Parameters:
* buffer - contains the characters to be output
* count - the number of characters to be output from buffer
*
* Return values:
* >= 0 the number of characters actually output. The function
* should make its best attempt to transmit all 'count'
* characters.
* < 0 indicates a fatal error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
nettol(char * buffer, int count);
/*
* T T V T - Terminal to Virtual Terminal Mode
*
* Terminal to Virtual Terminal Mode is called to notify the DLL that
* Kermit 95 is about to enter terminal mode communications. This means
* either the CONNECT or DIAL commands will be sending output. In most
* cases, this will be either printable text or escape sequences.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
ttvt(void);
/*
* T T P K T - Terminal to Packet Mode
*
* Terminal to Packet Mode is called to notify the DLL that
* Kermit 95 is about to enter file transfer operations.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
ttpkt(void);
/*
* T T R E S - Terminal Restore Mode
*
* Terminal Restore Mode is called to notify the DLL that it should
* Kermit 95 restore to default settings.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
ttres(void);
/*
* T E R M I N F O - Terminal Information
*
* The terminal information function is called whenever the terminal
* type or window size is changed.
*
* Parameters:
* termtype - a string representing either the currently selected
* terminal type or a user specified string as per
* SET TELNET TERMINAL string
* height - initial height of the terminal window (chars)
* width - initial width of the terminal window (chars)
*
* Return values: None
*/
void
terminfo(char * termtype, int height, int width);
/*
* V E R S I O N - Version String
*
* Version is called to get a user displayable version string for use
* as part of the SHOW NETWORK command.
*
* Parameters: None
*
* Return values:
* a string which will not be deleted by the caller.
*/
const char *
version(void);
/*
* E R R O R S T R - Error String
*
* Error string is called to retrieve a user displayable error message
* describing the type of error being reported by the function.
*
* Parameters:
* error - the error value reported by the DLL function.
*
* Return values:
* a string which will not be deleted by the caller.
*/
const char *
errorstr(int error);

(Kerberos) Invalidation of a ticket after a certain period of time.
A ticket's lifetime is chosen by the user when obtaining the ticket; the
maximum allowable lifetime for different kinds of tickets is set by the site
administrator.

FTP

File Transfer Protocol. On the Internet, this refers to a specific
protocol defined in
RFC 959 and its followons.

Forwardable Tickets

(Kerberos) Tickets that can be forwarded (copied) to a remote
machine, where they can be used, eliminating the need to obtain new Ticket
Granting Tickets (q.v.) on that machine, e.g. for Telnetting from machine A to
machine B and then from machine B to machine C.

Host

A computer that can be accessed over a network.

HTTP

Hyper Text Transfer Protocol, the protocol of the World Wide Web,
RFC 2616.

Pretty Good Privacy, the original do-it-yourself
public key security scheme, first developed in 1991 by Phil Zimmerman.

Preauthenticated Ticket Granting Ticket Request

(Kerberos) The client must include a time stamp encrypted with the
user's password when requesting the TGT from the KDC. This allows the KDC to
only deliver a TGT to a valid user. When preauthentication is not used the
TGT may be attacked offline to determine the user's password.

NAT

Network Address Translator.

NTLM

Microsoft (Windows) NT LAN Manager authentication protocol.

PKI

Public Key Infrastructure.

Postdated Ticket

(Kerberos) A ticket that does not become valid until after a
specified time. This allows for secure unattended operations.

Principal

(Kerberos) A string that names a specific entity to which a set of
credentials may be assigned. It generally has three parts,
primary/instance@REALM:

Primary: Identifies the user or service.

Instance: Usually a hostname or REALM.

REALM: Logical network served by a single Kerberos database and
KDC.

Privacy

The assurance that traffic on a network connection is intelligible only
to the two communicating parties.

Proxiable Ticket

(Kerberos) A ticket that may be given to a service to allow the
service to impersonate the user for whom the ticket has been issued.