[ Kermit Home ] [ C-Kermit ] [ Kermit 95 ]
1. INTRODUCTION
2. DISCLAIMERS
3. KERMIT SECURITY USER GUIDE
4. INSTALLATION AND CONFIGURATION
5. SCRIPTING AND AUTOMATION
I. WHERE TO FIND SECURE TELNET AND FTP SERVERS
II. MULTIHOMED HOSTS, FIREWALLS, NATS
III. INTRODUCTION TO CERTIFICATES
IV. USING OTHER SECURITY METHODS WITH KERMIT
GLOSSARY
REFERENCES
TRADEMARKS
CHAPTER CONTENTS
1.1. Secure Connections 1.2. Internet Protocols 1.3. Authentication 1.4. Encryption 1.5. IntegritySECURITY 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
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.
Kermit software has offered secure connections since 1998. This document presents the security methods embodied in C-Kermit 8.0 and Kermit 95 2.0, which include:
What is a secure connection? A connection is secure if it provides:
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:
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
SECTION CONTENTS
1.3.1. Kerberos 1.3.2. SRP 1.3.3. NTLM 1.3.4. X.509 Certificates 1.3.5 Public Keys 1.3.6 Host based 1.3.7 Password based
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:
http://www-cs-students.stanford.edu/~tjw/srp/
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 distrbuted security protocols including SSH rely on a loosely managed form of authentication based on the same asymmetic 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.
Export of software incorporating strong encryption is regulated by United States law.
SECTION CONTENTS
1.4.1. Telnet 1.4.2. FTP 1.4.3. SSL/TLS 1.4.4. SSH 1.4.5. HTTP 1.4.6. Rlogin
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:
When the Telnet START_TLS option is negotiated, SSL/TLS provides encryption services for the Telnet session.
Encryption for FTP sessions depends on the authentication method:
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 negotiatied 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:
ADH-AES256-SHA DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA AES256-SHA ADH-AES128-SHA DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA AES128-SHA DHE-DSS-RC4-SHA EXP1024-DHE-DSS-RC4-SHA EXP1024-RC4-SHA EXP1024-DHE-DSS-DES-CBC-SHA EXP1024-DES-CBC-SHA EXP1024-RC2-CBC-MD5 EXP1024-RC4-MD5 KRB5-DES-CBC3-MD5 KRB5-DES-CBC3-SHA KRB5-DES-CBC-MD5 KRB5-DES-CBC-SHA EXP-KRB5-DES-CBC-MD5 EXP-KRB5-DES-CBC-SHA EDH-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EDH-DSS-DES-CBC3-SHA EDH-DSS-DES-CBC-SHA EXP-EDH-DSS-DES-CBC-SHA DES-CBC3-SHA DES-CBC-SHA EXP-DES-CBC-SHA IDEA-CBC-SHA EXP-RC2-CBC-MD5 RC4-SHA RC4-MD5 EXP-RC4-MD5 ADH-DES-CBC3-SHA ADH-DES-CBC-SHA EXP-ADH-DES-CBC-SHA ADH-RC4-MD5 EXP-ADH-RC4-MD5 RC4-64-MD5 DES-CBC3-MD5 DES-CBC-MD5 IDEA-CBC-MD5 RC2-CBC-MD5 EXP-RC2-CBC-MD5 RC4-MD5 EXP-RC4-MD5
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 HTTP connections use SSL/TLS for encryption.
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.
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):
http://www.mozilla.org/crypto-faq.html
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:
[ Kermit Home ] [ C-Kermit ] [ Kermit 95 ]
CHAPTER CONTENTS
3.1. Overview of Security Protocols 3.2. Security Command List 3.3. Making Secure Connections 3.4. Using Secure ConnectionsSuppose 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:
3.1.1. Kerberos 3.1.2. SRP 3.1.3. NTLM 3.1.4. SSL/TLS 3.1.5. SSH
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 negotiatied 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 negotations 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:
ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
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:
set auth tls rsa-cert-file /usr/local/ssl/certs/telnetd-rsa.pem set auth tls rsa-key-file /usr/local/ssl/certs/telnetd-rsa-key.pem set auth tls dsa-cert-file /usr/local/ssl/certs/telnetd-dsa.pem set auth tls dsa-key-file /usr/local/ssl/certs/telnetd-dsa-key.pem
as well as the list of acceptable ciphers:
set auth tls cipher 3DES:DSS
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:
set auth tls rsa-cert-chain-file /usr/local/ssl/certs/telnetd-rsa-chain.pem set auth tls dsa-cert-chain-file /usr/local/ssl/certs/telnetd-dsa-chain.pem
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.
This section applies only to Kermit 95.
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.
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:
SSH v1: \v(common)ssh\known_hosts SSH v2: \v(common)ssh\known_hosts2
and your user-specific (and K95-specific) known-hosts files are:
SSH v1: \v(appdata)ssh\known_hosts SSH v2: \v(appdata)ssh\known_hosts2
(\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.:
SSH v1: c:\Documents and Settings\username\Application Data\Kermit 95\ssh\known_hosts SSH v2: c:\Documents and Settings\username\Application Data\Kermit 95\ssh\known_hosts2
On Windows 98 with multi-user support, this would be:
SSH v1: c:\WINDOWS\Profiles\username\Application Data\Kermit 95\ssh\known_hosts SSH v2: c:\WINDOWS\Profiles\username\Application Data\Kermit 95\ssh\known_hosts2
On Windows 98 without multi-user support, this would be:
SSH v1: c:\WINDOWS\Application Data\Kermit 95\ssh\known_hosts SSH v2: c:\WINDOWS\Application Data\Kermit 95\ssh\known_hosts2
(\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 assurrance 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:
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.
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):
SSH V1 RSA key: identity.pub SSH V2 DSA key: id_dsa.pub SSH V2 RSA key: id_rsa.pub
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:
Of course, secure authentication for SSH clients requires modified SSH servers, which are available. GSSAPI does not require host keys at all since Kerberos authentication is mutual.
The complete list of K95's SSH v2 authentication methods is:
3.2.1. Connection Establishment 3.2.2. The SET AUTHENTICATION Command 3.2.3. The AUTHENTICATE Command 3.2.4. Other Security-Related Commands
The following notation is used in Kermit command syntax descriptions:
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
if success {
Commands to execute if Kerberos is built in.
} else {
Commands to execute if Kerberos is not built in.
}
if available encryption set telnet encryption type cast128_cfb64
SUBSECTION CONTENTS
3.2.1.1. Secure Telnet Connections 3.2.1.2. SSH Connections 3.2.1.3. Secure FTP Connections 3.2.1.4. Secure HTTP Connections
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:
http://www.columbia.edu/kermit/telnet.html
(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:
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.
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 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.
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.
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.
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:
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 SET LOGIN USER DOMAIN\\username due to the use of backslash (\) as the command quote character in Kermit's command lanaguage.
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.
V1 RSA: \v(appdata)ssh/identity V2 RSA: \v(appdata)ssh/id_rsa V2 DSA: \v(appdata)ssh/id_dsa
Windows 95/98/98SE/ME: %windir%\ssh_known_hosts Windows NT/2000/XP: \v(common)ssh\ssh_known_hosts
\v(appdata)ssh/known_hosts
external-keyx gssapi hostbased publickey srp-gex-sha1 keyboard-interactive password none
aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour aes192-cbc aes256-cbc
Windows 95/98/98SE/ME: %windir%\ssh_known_hostss Windows NT/2000/XP: \v(common)ssh\ssh_known_hosts2
ssh-rsa ssh-dsa
hmac-md5 hmac-sha1 hmac-ripemd160 hmac-sha1-96 hmac-md5-96
\v(appdata)ssh/known_hosts2
C-Kermit 8.0 and Kermit 95 2.00 provide support for authenticated and encrypted file transfers using Kerberos 4, GSSAPI-Kerberos 5, Secure Remote Password (SRP), Secure Sockets Layer (SSL), and Transport Layer Security (TLS).
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:
The following commands configure the use of FTP Security when establishing connections:
Reference: Kermit HTTP Client Documentation
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:
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 appropropriate SET AUTHENTICATION commands in your Kermit customization file: K95CUSTOM.INI (Windows) or ~/.mykermrc (UNIX).
SET AUTH K4 PRINCIPAL {}
SET AUTH K5 PRINCIPAL {}
in the Kermit initialization file or connection script.
SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL {}
has been issued.
Each item in the list may include a prefix modifier:
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.
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
In Kermit 95, the default file is \v(exedir)ca_crls.pem
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
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
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.
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
In Kermit 95, the default file is \v(exedir)ca_certs.pem
The AUTHENTICATE command obtains or destroys Kerberos tickets and lists information about them. The general format is:
The AUTHENTICATE command's INITIALIZE option is the most complex of Kermit's security commands, and its format is different for Kerberos 4 and Kerberos 5:
The Kerberos 4 principal format is:
userid[.instance[.instance]]@[realm]
but can be omitted if it is the same as your username or SET LOGIN USERID value on the client system.
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.
Note: Kerberos 5 always attempts to retrieve a Ticket Granting Ticket (TGT) using the preauthenticated TGT request.
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.
[ Kermit Home ] [ C-Kermit ] [ Kermit 95 ]
SECTION CONTENTS
3.3.1. The SET HOST Command 3.3.2. The TELNET Command 3.3.3. The SSH Command 3.3.4. The RLOGIN Command 3.3.5. Making Secure FTP Connections 3.3.6. Making Secure HTTP Connections 3.3.7. Using Only SSL or TLS 3.3.8. Using Kerberos 5 User-to-User Protocol
TCP/IP connections established by Kermit are initiated either with the SET HOST command; a protocol-specific command such as TELNET or RLOGIN; or in the case of FTP and HTTP an OPEN command.
When using the SET HOST command to establish a secure connection, several switches are available between SET HOST and the hostname, plus a protocol switch at the end:
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.
- /K5USER2USER
- Use Kerberos V User to User protocol.
- /SSL
- Perform SSL negotiations.
- /SSL-TELNET
- Perform SSL negotiations and if successful start Telnet negotiations.
- /TLS
- Perform TLS negotiations.
- /TLS-TELNET
- Perform TLS negotiations and if successful start Telnet negotiations.
The TELNET command combines a number of commands related to secure telnet connections into a single interface.
SET TELOPT AUTH ... SET TELNET AUTH TYPE ... SET TELOPT ENCRYPT ... SET TELNET ENCRYPT TYPE ... SET LOGIN USERID ... SET LOGIN PASSWORD ... SET HOST /CONNECT host port /TELNET
The optional TELNET command switches are:
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.
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:
Key Type Private Key File Public Key File v1 RSA keys \v(appdata)ssh/identity \v(appdata)ssh/identity.pub v2 RSA keys \v(appdata)ssh/id_rsa \v(appdata)ssh/id_rsa.pub v2 DSA keys \v(appdata)ssh/id_dsa \v(appdata)ssh/id_dsa.pub
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).
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).
SET LOGIN USERID ... SET HOST /CONNECT hostname service [ protocol-switch ]
where the combinations of /ENCRYPT /KERBEROS4 /KERBEROS5 result in the following protocol-switches:
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:
SET FTP AUTHTYPE SRP SET FTP AUTOAUTHENTICATE ON ; default setting SET FTP AUTOENCRYPTION ON ; default setting SET FTP AUTOLOGIN ON ; default setting SET FTP SRP CIPHER DES_ECB ; default setting SET FTP SRP HASH SHA1 ; default setting SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting SET FTP DATA-PROTECTION-LEVEL PRIVATE ; default setting FTP OPEN host /USER:username /PASSWORD:password
If the /USER and/or /PASSWORD switches are omitted, the user is prompted for the required fields.
For example, to establish a secure FTP connection using GSSAPI-Kerberos 5 the following commands could be executed:
SET AUTH KERBEROS5 REALM MY.REALM SET AUTH KERBEROS5 PRINCIPAL my-principal AUTH KERBEROS5 INIT SET FTP AUTHTYPE GSSAPI-KRB5 SET FTP AUTOAUTHENTICATE ON ; default setting SET FTP AUTOENCRYPTION ON ; default setting SET FTP AUTOLOGIN ON ; default setting SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting SET FTP DATA-PROTECTION-LEVEL PRIVATE ; default setting FTP OPEN host /USER:username
If the /USER switch is omitted, the user is prompted for the name to login as after authentication is performed.
Here is an example using TLS to secure the FTP session for an anonymous user:
SET AUTH TLS VERIFY-FILE ca-cert.pem SET FTP AUTHTYPE TLS SET FTP AUTOAUTHENTICATE ON ; default setting SET FTP AUTOENCRYPTION ON ; default setting SET FTP AUTOLOGIN ON ; default setting SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting SET FTP DATA-PROTECTION-LEVEL PRIVATE ; default setting FTP OPEN host /ANONYMOUS
Here is an example using FTP through an SSL Proxy Server:
SET AUTH SSL VERIFY-FILE ca-cert.pem SET FTP AUTOLOGIN ON ; default setting SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting SET FTP DATA-PROTECTION-LEVEL PRIVATE ; default setting FTP OPEN /SSL host /USER:username /PASSWORD:password
If the /USER and/or /PASSWORD switches are omitted, the user is prompted for the required fields.
Here is an example of a secure GET:
SET AUTH TLS VERIFY-FILE ca-cert.pem HTTP OPEN host HTTPS HTTP /USER:username /PASSWORD:password GET index.html index.html HTTP CLOSE
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 SET AUTHENTICATION { SSL, TLS }... commands are used to configure the certificates and authorities, and verification options used during connection establishment.
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:
[ Kermit Home ] [ C-Kermit ] [ Kermit 95 ]
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:
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.
[ Kermit Home ] [ C-Kermit ] [ Kermit 95 ]
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.
CHAPTER CONTENTS
4.1. Security in Kermit 95 4.2. Security in C-Kermit
SECTION CONTENTS
4.1.1. Kerberos 4.1.2. SRP 4.1.3. NTLM 4.1.4. OpenSSL 4.1.5. SSH 4.1.6. Firewalls 4.1.7. Adding Other Security Methods to Kermit 95
Kermit 95 supports Kerberos Telnet Authentication, Kerberos Rlogin, Kerberos FTP, and Kerberos SSL/TLS (K5 only) when any of the following Kerberos IV or Kerberos V implementations are installed on a Windows 95 or Windows NT workstation:
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:
http://www.kermit-project.org/export.html
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.
KRB.CON: CC.COLUMBIA.EDU CC.COLUMBIA.EDU kerberos.cc.columbia.edu KERMIT.COLUMBIA.EDU kerberos.cc.columbia.edu COLUMBIA.EDU kerberos.cc.columbia.edu .KERBEROS.OPTION. dns
The first line is the default Kerberos IV realm to be used. The subsequent lines list realms and the hostnames to be used to contact the KDC for that realm.
The last line is an indicator that DNS can be used to map Realms to KDCs and host names to Realms.
KRBREALM.CON: .CC.COLUMBIA.EDU CC.COLUMBIA.EDU CC.COLUMBIA.EDU CC.COLUMBIA.EDU .COLUMBIA.EDU CC.COLUMBIA.EDU COLUMBIA.EDU CC.COLUMBIA.EDU .KERMIT.COLUMBIA.EDU CC.COLUMBIA.EDU KERMIT.COLUMBIA.EDU CC.COLUMBIA.EDU
Each line specifies either a domain name prefaced with a "." or a host name and the Kerberos IV realm to which it belongs.
[libdefaults]
default_realm = CC.COLUMBIA.EDU
default_tkt_enctypes = des3-cbc-sha1 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-crc
ticket_lifetime = 600
dns_lookup_kdc = true
dns_lookup_realm = true
forwardable = true
proxiable = true
[domain_realm]
.cc.columbia.edu = CC.COLUMBIA.EDU
cc.columbia.edu = CC.COLUMBIA.EDU
.columbia.edu = CC.COLUMBIA.EDU
columbia.edu = CC.COLUMBIA.EDU
[realms]
CC.COLUMBIA.EDU = {
kdc = kerberos.columbia.edu:88
admin_server = kerberos.columbia.edu:749
default_domain = cc.columbia.edu
supports_tgs_enctypes = des3-cbc-sha1 des-cbc-crc
supports_tkt_enctypes = des3-cbc-sha1 des-cbc-crc
}
Kermit 95 supports Telnet Authentication via Secure Remote Password protocol without any additional software.
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:
http://www.kermit-project.org/export.html
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.
Kermit 95 supports SSL/TLS security via OpenSSL when the encryption patch (obtained from the Kermit Project) is installed. The encryption patch is available WITH EXPORT RESTRICTIONS at:
http://www.kermit-project.org/export.html
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:
\v(appdata)certs/ \v(common)certs/ \v(exedir)certs/
\v(appdata)ca_certs.pem \v(common)ca_certs.pem \v(exedir)ca_certs.pem
\v(appdata)crls/ \v(common)crls/ \v(exedir)crls/
\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:
The following is a list of things to watch out for in the Kermit 95 implmentation:
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.
Kermit 95 includes a DLL interface for adding new security methods. The DLL can be loaded with the SET NETWORK TYPE command:
SET NETWORK TYPE DLL dll-file
The connection is 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. A C language skeleton for the DLL is available here:
http://www.columbia.edu/kermit/k95dll_c.txt
SECTION CONTENTS
4.2.1. Kerberos 4.2.2. SRP 4.2.3. SSL/TLS 4.2.4. Shadow Passwords 4.2.5. PAM 4.2.6. Using External Security Methods with C-Kermit
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.
http://web.mit.edu/kerberos/www/ http://web.mit.edu/network/kerberos-form.html
http://web.mit.edu/kerberos/www/ http://web.mit.edu/network/kerberos-form.html
-DCK_AUTHENTICATION -DCK_KERBEROS
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:
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 meesages 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.
http://srp.stanford.edu/srp/
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.
-DCK_AUTHENTICATION -DCK_SRP $(SRPINC)
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:
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.
http://www.openssl.org/
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 Kebreros 5 ciphers. However, OpenSSL releases prior to version 1.0 are not guarranteed 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.
-DCK_AUTHENTICATION -DCK_SSL $(SSLINC)
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:
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:
-DCK_SHADOW
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:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/.
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.
[ Kermit Home ] [ C-Kermit ] [ Kermit 95 ]
"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
"NULL" - No authentication "KERBEROS_V4" - Kerberos 4 "KERBEROS_V5" - Kerberos 5 "SRP" - Secure Remote Password "NTLM" - NT Lan Manager "X_509_CERTIFICATE" - X.509 certificate
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
This value can be used in an IF statement, e.g.:
if \fkrbisvalid(4,[email protected]) ...
Kerberos 5 functions operate against the current credential-cache file as set by SET AUTHORIZATION K5 CREDENTIALS-FILE filename.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
SET AUTHENTICATION KERBEROS4 AUTOGET OFF SET AUTHENTICATION KERBEROS5 AUTOGET OFF
When autoget mode is disabled, Kermit does not automatically perform the function of KINIT. Instead this automation can be scripted; for example:
SET TELOPT AUTHENTICATION REQUIRED
SET HOST host:port /TELNET
IF FAILURE {
AUTHENTICATE K4 INIT ; (or K5)
SET HOST host:port
IF FAILURE { do whatever on failure }
}
or place the following in your K95CUSTOM.INI file to insure a valid Ticket Granting Ticket each time you start K95:
IF AVAILABLE KERBEROS4 {
IF NOT \Fkrbisvalid(4,krbtgt.\v(krb4realm)@\v(krb4realm)) {
echo Kerberos 4 Ticket Granting Ticket is invalid!
AUTH K4 INIT
}
}
IF AVAILABLE KERBEROS5 {
IF NOT \Fkrbisvalid(5,krbtgt/\v(krb5realm)@\v(krb5realm)) {
echo Kerberos 5 Ticket Granting Ticket is invalid!
AUTH K5 INIT
}
}
SET LOGIN USERID {}
SET AUTHENTICATION KERBEROS4 PRINCIPAL {}
SET AUTHENTICATION KERBEROS5 PRINCIPAL {}
This forces Kermit to prompt the user for the userid and principal when requesting credentials.
SET HOST /PASSWORD:password /USERID:user host port /TELNET
The security risk can be avoided if the script prompts for the password:
ASKQ \%p Password: SET HOST PASSWORD:\%p /USERID:user host port /TELNET UNDEF \%p
Of course, if the /PASSWORD switch is not specified Kermit prompts for the password automatically when the host requests the use of authentication.
SET TELOPT /SERVER AUTH REQUIRE
SET TELOPT /SERVER ENCRYPT REQUIRE REQUIRE
SET HOST * port /TELNET
IF FAILURE { do appropriate error handling }
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.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
CONTENTS
I.1. Telnet I.2. FTP I.3. Internet Kermit Service I.4. HTTP I.5. SSH I.6. Securing Insecure Services with STunntl
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.
http://www-1.ibm.com/servers/eserver/zseries/zos/commserver/kerberos.html
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.
http://web.mit.edu/kerberos/www/
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.
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.
http://web.mit.edu/kerberos/www/
Follow the links to "Getting Kerberos from MIT".
The SRP Telnet server is part of the SRP distribution:
http://www-cs-students.stanford.edu/~tjw/srp/
Follow the link to Download Software
http://www.openssl.org/
Current development snapshots of OpenSSL are required for Kerberos 5 support. A Telnet server that implements the START_TLS option and X Windows System Data Forwarding is available from:
ftp://ftp.runestig.com/pub/starttls/start_tls-telnet.current.tar.gz
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.
http://web.mit.edu/kerberos/www/
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.
The Kerberos 4 FTP server provides for strong authentication. Both the command and data channels are encrypted and integrity protected.
http://web.mit.edu/kerberos/www/
Follow the links to "Getting Kerberos from MIT".
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).
http://www-cs-students.stanford.edu/~tjw/srp/
Follow the link to Download Software
http://www.openssl.org/
Current development snapshots of OpenSSL are required for Kerberos 5 support.
Two FTP servers that implement the SSL/TLS protocol for securing both the command and data channels are available from:
ftp://ftp.runestig.com/pub/ftp-tls/ ftp://ftp.runestig.com/pub/ftpd-tls/ ftp://ftp.runestig.com/pub/proftpd-tls/
The current (Dec 2001) test version of Debian Linux includes ProFTPD with TLS security.
Available from Columbia University:
Most web servers provide support for SSL/TLS secured HTTP connections.
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:
It is also possible to wrap a nonsecure service such as Telnet or Sredird in Stunnel, for use with Kermit's abiity to negotiate non-secure protocols over SSL/TLS; CLICK HERE for a case study.
CONTENTS
II.1. Firewalls II.2. Network Address Translation II.3. Multi-Homed Hosts and Aliasing
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:
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 transfered. 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:
http://www.iana.org/assignments/port-numbers
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.
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.
In Kermit, the use of passive mode is controlled with the command:
SET FTP PASSIVE-MODE { ON, OFF }
The default is to use passive mode.
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:
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.
Kermit 95 2.00 supports SOCKS 4.2. The SOCKS Server is specified with the command:
SET TCP SOCKS-SERVER hostname/ip-address[:port]
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:
AUTH K5 INIT /ADDRESSES:{list-of-addresses}
SET AUTH K5 ADDRESSES {list-of-addresses}
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:
ftp://kermit.columbia.edu/kermit/scripts/ckermit/linksys
For those interested in more technical information on the consequences of Network Address Translation, the IETF has several Informational RFCs on the subject:
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:
[email protected]
we get a ticket for:
[email protected]
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.
[ Kermit Home ] [ C-Kermit ] [ Kermit 95 ]
CONTENTS
III.1. What Are Certificates (etc)...? III.2. RSA vs DSA Certifications III.3. Should You Be Your Own Certificate Authority? III.4. Generating a DSA CA (self-signed) Certificate III.5. Generating a DSA CSR III.6. Generating an RSA CA (self-signed) certificate III.7. Generating an RSA CSR III.8. Signing a CSR with your CA certificate III.9. Revoking a Certificate III.10. Generating a CRL III.11. Mapping a Client Certificate to a User ID
LINKS
This is a brief introduction to certificates, certificate authorities, and how to use them. The information presented here is highly technical and can be skipped unless:
RSA Security, Inc., has a good Frequently Asked Questions (FAQ):
http://www.rsasecurity.com/rsalabs/faq/questions.html
The FAQ covers many topics related to cryptography as well as how public key certificates work and how they are to be used.
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 important differences between RSA and DSA certificates are:
There are many companies that believe that providing CA services is big business. These include but are not limited to:
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:
http://www.counterpane.com/pki-risks.html
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.
openssl/dsaCA/certs/ openssl/dsaCA/crl/ openssl/dsaCA/private/ openssl/dsaCA/newcerts/ openssl/dsaCA/requests/ openssl/rsaCA/certs/ openssl/rsaCA/crl/ openssl/rsaCA/private/ openssl/rsaCA/newcerts/ openssl/rsaCA/requests/
Place the openssl.cnf file into the openssl directory. Edit it to meet the requirements of your organization. Create two sections, [ CA_DSA ] and [ CA_RSA ]:
[ CA_DSA ] dir = openssl_path/dsaCA/ # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/certs/cacert.pem # The CA certificate serial = $dir/ca.srl # The current serial number crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem # The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = x509v3_extensions # The extentions to add to the cert default_days = 365 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = sha1 # which md to use. preserve = no # keep passed DN ordering policy = policy_match # which CA policy [ CA_RSA ] dir = openssl_path/rsaCA/ # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/certs/cacert.pem # The CA certificate serial = $dir/ca.srl # The current serial number crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem # The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = x509v3_extensions # The extentions to add to the cert default_days = 365 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = sha1 # which md to use. preserve = no # keep passed DN ordering policy = policy_match # which CA policy
If you wish to use the uniqueIdentifier field to perform certificate to user ID mapping, add it after the emailAddress field.
If you wish to use the subjectAltName field to perform certificate to user ID mapping, you must to add a [ x509v3_externsions ] section:
[ x509v3_extensions ] subjectAltName = email:copy
Other formats of the subjectAltName field are:
subjectAltName = email:copy subjectAltName = issuerl:copy subjectAltName = email:[email protected] subjectAltName = DNS:www.company.com subjectAltName = IP:100.99.98.97 subjectAltName = RID:2.99999.1
Other x509v3 extensions include:
nsCaRevocationUrl = http://www.domain.com/ca-crl.pem nsComment = "This is a comment"
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.
Change the current working directory to openssl/dsaCA/.
Generate the DSA parameters to be used when generating the keys for use with your certificates:
openssl dsaparam 1024 -out dsa1024.pem
Generate the self-signed certificate to be used as the CA certificate for your organization:
openssl req -x509 -newkey dsa:dsa1024.pem -days days \
-keyout private/cakey.pem -out certs/cacert.pem
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.
You can check the contents of the CA certificate with the command:
openssl x509 -text -in certs/cacert.pem
Change the current working directory to openssl/dsaCA/.
If you have not already created a set of DSA parameters, you must generate a set:
openssl dsaparam 1024 -out dsa1024.pem
It is safe to reuse the DSA parameters.
Generate the DSA certificate request:
openssl req -newkey dsa:dsa1024.pem -keyout private/name-key.pem \
-out requests/name-req.pem
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 commerical CAs if you do not wish to be your own CA.
Change the current working directory to openssl/rsaCA/.
Generate the self-signed certificate to be used as the CA certificate for your organization:
openssl req -x509 -newkey rsa:1024 -days days \
-keyout private/cakey.pem -out certs/cacert.pem
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.
You can check the contents of the CA certificate with the command:
openssl x509 -text -in certs/cacert.pem
Change the current working directory to openssl/rsaCA/.
openssl req -newkey rsa:1024 -keyout private/name-key.pem \
-out requests/name-req.pem
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 commerical 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":
openssl ca -name caname -in requests/name-req.pem \
-out certs/name.pem -days days
The days parameter should be replaced by the number of days you want the signed certificate to remain valid. If you want to specify a specific date range you can replace the -days parameters with:
-startdate YYMMDDHHMMSSZ - certificate validity notBefore -enddate YYMMDDHHMMSSZ - certificate validity notAfter
The file certs/name.pem now contains a signed certificate that may be used by a host or client for authentication with its matching private key (private/name-key.pem.)
An alternative method of signing the CSR is to use the command:
openssl x509 -req -in requests/name-req.pem -CA certs/cacert.pem \
-CAkey private/cakey.pem -out certs/name.pem -days days \
-CAserial ca.srl -CAcreateserial
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.
You can check the contents of the CA certificate with the command:
openssl x509 -text -in certs/name.pem
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.
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.
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.
In addition to determing 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.
OpenSSL sources may be retrieved from the web site:
http://www.openssl.org/
Kermit 95 2.0 for Windows was compiled against an 0.9.7 stable build. The OS/2 version is still built against the older 0.9.4 build that was ported to that platform.
Patches for OpenSSL 0.9.4 to allow compilation under OS/2 are located at:
http://www.geocities.com/SiliconValley/Hills/8057/files/openssl.html
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.
The DLL must contain two functions with the following prototypes:
/* X509_to_user() returns 0 if valid userid in 'userid', else -1 */ int X509_to_user(X509 *peer_cert, char *userid, int len); /* X509_userok() returns 0 if access is denied; 1 is access is permitted */ int X509_userok(X509 * peer_cert, const char * userid);
An example function that uses the /UID field of the Certificate Subject name follows:
int
X509_to_user(X509 *peer_cert, char *userid, int len) {
int err;
if (!(peer_cert && userid) || len <= 0)
return -1;
/* Userid is in cert subject /UID */
err = X509_NAME_get_text_by_NID(X509_get_subject_name(peer_cert),
NID_uniqueIdentifier, userid, len);
if (err > 0)
return 0;
return -1;
}
An example function provides userid authorization follows:
int
X509_userok(X509 * peer_cert, const char * userid) {
/* check if clients cert is in "user"'s ~/.tlslogin file */
char buf[512];
int r = 0;
FILE *fp;
struct passwd *pwd;
X509 *file_cert;
if ( peer_cert == NULL )
return(0);
if (!(pwd = getpwnam(userid)))
return 0;
if (strlen(pwd->pw_dir) > 500)
return(0);
sprintf(buf, "%s/.tlslogin", pwd->pw_dir);
if (!(fp = fopen(buf, "r")))
return 0;
while (!r && (file_cert = PEM_read_X509(fp, NULL, NULL, NULL))) {
if (<ASN1_STRING_cmp(peer_cert->signature, file_cert->signature))
r = 1;
X509_free(file_cert);
}
fclose(fp);
return(r);
}
These functions must be compiled into a DLL called "X5092UID.DLL". It should be linked to the OpenSSL libraries and the DLL version of the run time library.
Contact Kermit Support for further information..
X.509 to User ID mapping functions are implemented in C-Kermit in one of two ways.
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.
Contact Kermit Support for further information..
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.)
NEC distributes a SOCKS5 Winsock shim for Windows 9x/NT at:
ftp://ftp.nec.co.jp/pub/packages/sotools/
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 <[email protected]>
*
* 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);
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
[ Top ] [ Contents ] [ Glossary ] [ C-Kermit Home ] [ Kermit Home ]