19 November 2001
This document describes Kerberos(TM), Secure Remote Password (SRP)(TM) protocol, Secure Sockets Layer (SSL)/Transport Layer Security (TLS), and other security implementations in, or to be used with, current or forthcoming releases of Kermit software. NOTE: The terms "Windows 95" and "Windows 9x" in this document refer to both Windows 95, Windows 98, and Windows ME; the term "Windows NT" refers to Windows NT 3.51 and later; to Windows 2000 and Windows XP (all versions).
[ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit 95 ] [ Kermit Home ]
1. INTRODUCTION
2. DISCLAIMERS
3. AVAILABILITY
3.1. Security in Kermit 95
3.1.1. Kerberos in Kermit 95
3.1.2. Secure Remote Password (SRP) in Kermit 95
3.1.3. NTLM in Kermit 95
3.1.4. OpenSSL support for SSLv3 and TLSv1 in Kermit 95
3.2. Security in C-Kermit
3.2.1. Kerberos in C-Kermit
3.2.2. Secure Remote Password (SRP) in C-Kermit
3.2.3. OpenSSL support for SSLv3 and TLSv1 in C-Kermit
3.2.4. Shadow Passwords in C-Kermit
3.2.5. Pluggable Authentication Modules (PAM) in C-Kermit
4. KERBEROS GLOSSARY
5. SECURITY PROTOCOL OVERVIEWS
5.1. Kerberos
5.2. Secure Remote Password (SRP)
5.3. NT LAN Manager (NTLM)
5.4. SSLv3 and TLSv1
6. SECURITY COMMANDS
6.1. Security Commands Related to Establishing Connections
6.1.1. Security Commands Related to Telnet Connections
6.1.2. Security Commands Related to FTP Connections
6.1.3. Security Commands Related to HTTP Connections
6.2. The SET AUTHENTICATION Command
6.2.1. Kerberos settings
6.2.2. SRP settings
6.2.3. SSL and TLS settings
6.3. The AUTHENTICATE Command
7. ESTABLISHING A SECURE CONNECTION
7.2. Using TELNET protocol
7.3. Using RLOGIN protocol
7.4 Using FTP protocol
7.5 Using HTTP protocol
7.6. Using Only SSL or TLS
7.7. Using Kerberos 5 User to User protocol
8. EFFECTS OF ENCRYPTION ON FILE TRANSFER PERFORMANCE
9. MULTI-HOMED HOSTS AND NETWORK ADDRESS TRANSLATORS
10. OTHER NOTES
11. VARIABLES
11.1. General Authentication Variables
11.2. Kerberos Variables
11.3. SSL/TLS Variables
12. FUNCTIONS
13. SCRIPTING HINTS
13.1. Kerberos Autoget
13.2. Autodestruction of Kerberos credentials
13.3. Automated Prompting for Usernames
13.4. Password Inclusion in Script Files
13.5. Using Kermit Scripts to Produce Secure Telnet Services
14. USING OTHER SECURITY METHODS WITH KERMIT
14.1. Implementing other security methods for Kermit 95
15. THE KERMIT SECURE FTP CLIENT FOR KERMIT 95
15. AN INTRODUCTION TO CERTIFICATES AND CERTIFICATE AUTHORITIES WITH OPENSSL
15.1. What Are Certificates, Private Keys, CSRs, CAs, and CRLs?
15.2. RSA Certificates v. DSA Certificates
15.3. Should You Be Your own Certificate Authority?
15.4. Generating a DSA CA (self-signed) certificate
15.5. Generating a DSA CSR
15.6. Generating a RSA CA (self-signed) certificate
15.7. Generating a RSA CSR
15.8. Signing a CSR with your CA certificate
15.9. Revoking a Certificate
15.10. Generating a CRL
15.11. Mapping a Client Certificate to a User ID
15.11.1. Mapping a Client Certificate to a User ID in Kermit 95
15.11.2. Mapping a Client Certificate to a User ID in C-Kermit
16. Secure Shell (SSH) client functionality
[ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit 95 ] [ Kermit Home ]
A secure connection is one that provides:
C-Kermit and Kermit 95 are capable of creating and accepting secure connections via a variety of protocols:
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), then 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 which can be used to encrypt the current session.
http://srp.stanford.edu/srp/
SRP authentication has been integrated into Telnet and FTP. As a result of the authentication a shared secret is produced which can be used to encrypt the current session.
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 as plain-text. NTLM is a proprietary protocol which is considered to be a trade secret by Microsoft. Kermit 95 when establishing connections with another Kermit 95 configured to accept incoming connections can negotiate NTLM over a SSL/TLS session. Security is then provided by SSL/TLS while authentication is performed with NTLM.
C-Kermit and Kermit 95 provide mechanisms for the customization of the certificate to userid mapping.
Each application protocol such as Telnet, FTP and HTTP define their own protocol sets for encrypting the session based upon the authentication mechanism being used.
When the Telnet STARTTLS option is negotiated, SSL/TLS is used to provide encryption services for the Telnet session.
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.
TLS may be used in conjunction wth 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.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
The statements made with regard to US export law reflect the situation in November 2001, which might have changed since then. We will 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. Thus the Kermit Project does not distribute pre-compiled secure versions of C-Kermit via the Web.
Security within Kermit is provided via the use of third party libraries. These libraries are not included with Kermit; 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 in conjunction 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:
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
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/noexport.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 ahead to Section 3.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 = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ticket_lifetime = 600
dns_fallback = 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
supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4
supported_keytypes = des:normal des-cbc-crc:v4
}
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/noexport.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.
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.
http://www.kermit-project.org/noexport.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 specified in the K95CUSTOM.INI (or IKSD.KSC) file in order for certificate verification to be performed.
As of Kermit 95 version 1.1.21 the default locations will be provided as follows:
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 section 15.1.1 if you wish to provide server-side support for authentication of clients using public key certificates.
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/ or: http://web.mit.edu/network/kerberos-form.html
http://web.mit.edu/kerberos/www/ or: http://web.mit.edu/network/kerberos-form.html
-DCK_AUTHENTICATION -DCK_KERBEROS
For Kerberos 4 include:
-DKRB4 $(K4INC)
For Kerberos 5 include:
-DKRB5 $(K5INC)
For Kerberos 5 with Kerberos 4 compatibility mode:
-DKRB5 -DKRB524 -DKRB4 $(K5INC)
If you desire DES and 3DES encryption include:
-DCK_ENCRYPTION -DCK_DES
Add the appropriate libraries to LIBS. For Kerberos 4 include:
$(K4LIB) -lkrb
For Kerberos 5 include:
$(K5LIB) -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto
For Kerberos 4 compatibility mode with Kerberos 5 include:
$(K5LIB) -ldes425 -lkrb4 -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto
The makefile defines the path to the Kerberos header files using the variables K4INC or K5INC:
-I/usr/kerberos/include
The location of the Kerberos libraries is specified using the variables K4LIB or K5LIB:
-L/usr/kerberos/lib
The Kerberos header files and libraries are often installed in host specific locations. The values of the K4INC, K5INC, K4LIB, and K5LIB variables can be altered by:
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.
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)
If you built SRP with OpenSSL add:
$(SSLINC)
If you desire telnet encryption include:
-DCK_ENCRYPTION
For CAST encryption add:
-DCK_CAST
For DES and 3DES encryption add:
-DCK_DES -DLIBDES
Add the appropriate libraries to LIBS. If you built SRP using OpenSSL:
$(SRPLIB) -lsrp -lkrypto $(SSLLIB) -lcrypto
If you built SRP with GNU MP but without DES/3DES support use:
$(SRPLIB) -lsrp -lgmp -lkrypto
If you built SRP with GNU MP and Eric Young's DES library use:
$(SRPLIB) -lsrp -lgmp -ldes -lkrypto
The makefile defines the path to the SRP header files using the variable SRPINC:
-I/usr/local/include
The location of the Kerberos libraries is specified using the variable SRPLIB:
-L/usr/local/lib
The makefile defines the path to the OpenSSL header files using the variable SSLINC:
-I/usr/local/ssl/include
The location of the OpenSSL libraries is specified using the variable SSLLIB:
-L/usr/local/ssl/lib
The SRP and OpenSSL header files and libraries are often installed in host specific locations. The values of the SRPINC, SRPLIB, SSLINC, and SSLLIB variables can be altered by:
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 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 which is useful to C-Kermit is the support for Anonymous-Diffie-Hellman (ADH) ciphers for use in combination with 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.
-DCK_AUTHENTICATION -DCK_SSL $(SSLINC)
To add support for ZLIB compression add the following to CFLAGS:
-DZLIB
Add the appropriate libraries to LIBS:
$(SSLLIB) -lssl -lcrypto
For ZLIB compression add to LIBS:
-lzlib
The makefile defines the path to the OpenSSL header files using the variable SSLINC:
-I/usr/local/ssl/include
The location of the OpenSSL libraries is specified using the variable SSLLIB:
-L/usr/local/ssl/lib
The OpenSSL header files and libraries are often installed in host specific locations. The values of the SSLINC and SSLLIB variables can be altered by:
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 which uses 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 section 15.11.2.
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
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 an alternate 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 be located at http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
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 may 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 below.
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 may be used to authenticate you with the host automatically during a specified time interval. When authentication is successful, you are logged in to the host without a Login: or Password: prompt
Besides providing credentials for use during authentication, the service ticket also contains a session key to be used for encrypting the communications. 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 agreed 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 the network.
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 STARTTLS 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.
The result of a mutual authentication is a shared secret which is 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. This is taken advantage of in Telnet by negotiating AUTH SRP after establishing a private connection with the STARTTLS option.
When K95 is used on NT 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 Section 15 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 use by Web browsers. 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 may also be negotiatied after the connection is established via negotiations performed in some other protocol (such as Telnet START_TLS.)
Kermit supports both kinds of connections:
In its most common use the 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. Authentication of the client may be performed by the use of an X.509 certificate issued to the end user, via Kerberos 5, or via 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.
For verification of certificates to be performed, the root certificates of the certificate authorities (CAs) must be available. If you are not acting as your own CA you will need to use a file containing the root certificates used to sign the certificates belonging to the server's you are attempting to authenticate. A compilation of most of the commercial Certificate Authority root certificates as extracted from Microsoft Windows XP's certificate database is being made available at:
ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
The file once downloaded can be used by Kermit via the command:
SET AUTH SSL VERIFY-FILE path/ca_certs.pem
When Kermit is used as an Internet Kermit Service, 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 on the system. 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 section 15.11 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 only be used in conjunction with:
SET TELNET AUTHENTICATION TYPE SSL SET TELOPT AUTHENTICATION REQUIRED
When using IKSD with START_TLS you should create an /etc/iksd.conf file and place within it commands pointing 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 ciphers that you are willing to accept:
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 in order 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. Therefore, Kermit supports session caching. When 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 establish numerous connections to the same host during during a typical session.
For a list of Telnet servers that support START_TLS see:
http://www.columbia.edu/kermit/telnetd.html
For a list of FTP servers that support AUTH SSL and AUTH TLS see:
http://www.columbia.edu/kermit/ftpd.html
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
In all Kermit commands:
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. Basic commands:
Four Telnet Options can be negotiated between a Telnet client and a Telnet server which 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 which are not capable of negotiating any of these four options.
When a Telnet session begins it starts in an insecure state. Only after the initial negotiations are complete will the session be secure. Security in Telnet can be established using many combinations of different Telnet Options and authentication and encryption methods.
The AUTH option negotiates whether authentication will 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 the provide privacy on the connection. The how and encrypt flags are used to specify an authentication mode and whether encryption is required for this connection. The AUTH option may be negotiated in conjunction with either the START_TLS or ENCRYPT options, but not both.
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: 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 ENCRYPT option is used to negotiate whether streaming ciphers will 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. The sender then chooses the first type from the provided list that it supports. 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 protection to the data stream.
The START_TLS option negotiates whether the current session will 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 in conjunction 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 in conjunctions 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 the user authenticates as (ie, 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 these commands.
All forms of authentication rely on some secret information that only the user (or service) being authenticated either 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 only conjunction with a script that prompts for the password and then establishes the automated connection at a later date and time. Storing a password in a script file defeats all of the hard work you have put into securing your systems.
A 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 '\' 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 are working perfectly it can be fun to watch all of the action.
Complete details on how to use the FTP support can be found in the Updates to C-Kermit 8.0.
In summary, FTP connections are established by using the FTP OPEN command.
Syntax: FTP [ OPEN ] hostname [ port ] [ switches ]
Opens a connection to the FTP server on the given host. The default
TCP port is 21, but a different port number can be supplied if
necessary. Optional switches are:
/ANONYMOUS
Logs you in anonymously.
/USER:text
Supplies the given text as your username.
/PASSWORD:text
Supplies the given text as your password. If you include a username
but omit this switch and the server requires a password, you are
prompted for it.
/ACCOUNT:text
Supplies the given text as your account, if required by the server.
/ACTIVE
Forces an active (rather than passive) connection.
/PASSIVE
Forces a passive (rather than active) connection.
The following commands configure the use of FTP Security when establishing connections:
Syntax:
HTTP [ switches ] OPEN [{ /SSL, /TLS }] service/port
Instructs Kermit to open a new connection for HTTP communication with
the specified host on the specified port. The default port is "http".
If /SSL or /TLS are specified a secure connection will be established.
If switches are specified, they will be applied to all subsequent
HTTP actions (GET, PUT, ...) until an HTTP CLOSE command has been
executed.
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 algorithms:
HIGH:MEDIUM:LOW:EXPORT56:EXP:ADH:!kRSA:!aRSA:!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 Kermit is running as an IKSD it cannot support encrypted private keys. If your private key file is encrypted you can use the following command to unencrypt it (provided you know that pass phrase):
openssl dsa -in encrypted-key-file -out unencrypted-key-file
Note: When Kermit is running as an IKSD it cannot support encrypted private keys. If your private key file is encrypted you can use the following command to unencrypt it (provided you know that pass phrase):
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 INITIALIZE command is the most complex of Kermit's security commands, and its format is different for Kerberos 4 and Kerberos 5:
All switches are optional. The Kerberos 4 INITIALIZE switches are:
principal may be of the form:
userid[.instance[.instance]]@[realm]
and can be omitted if it is the same as your username or SET LOGIN USERID value on the client system.
The INITIALIZE command for Kerberos 5 can include a number of switches; all are optional:
principal may be of the form:
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 instance 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 will 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.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
The following switches are useful with secure connections:
The protocol-switches used with secure connections are:
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
where:
The RLOGIN (Remote Login) protocol unlike the Telnet protocol is not at all flexible and it supports no option mechanism. Authentication and privacy is not really 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 will attempt to negotiate the use of authentication and establish both the command and data channels in private mode. Therefore, all that is 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 will be 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 left out, the user will be prompted for the required fields.
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 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 which can then be used 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, certificate 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:
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
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 avoided.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
However, this does not always work on Windows 95 or Windows NT 3.5x due to their caching of DNS information. For instance, at Columbia University the CUNIX name resolves to one of six machines, each with a different name, such as HOSTA, HOSTB, etc. When telneting to CUNIX, you might be given IP address 128.59.35.136. But even though the DNS servers are properly configured to return the proper name (e.g. HOSTB) for that IP address, Windows 95 returns CUNIX because it retrieves the information from its internal cache instead of performing another network call. This means that instead of retrieving a Kerberos 4 ticket for the service:
rcmd.hostb@CC.COLUMBIA.EDU
we get a ticket for:
rcmd.cunix@CC.COLUMBIA.EDU
This use of the wrong ticket produces the following error:
Can't decode authenticator (krb_rd_req)
Kerberos 4 has no problems with NATs but fails with Multihomed systems. Why? A K4 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 K4 is used from behind a NAT the IP address that is placed into the ticket is the 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. It also means that when a K4 ticket is used with a multihomed host that the ticket is good only on the interface that was used to acquire the ticket in the first place.
Kerberos 5 has no problems 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. However, this also means that K5 fails when it is used through a NAT. The address in the ticket is the private IP address and not the address that the KDC sees. 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 the
AUTH K5 INIT /ADDRESSES:{list-of-addresses}
or
SET AUTH K5 ADDRESSES {list-of-addresses}
command. 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.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
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.
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
"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,krbtgt.FOO.BAR.EDU@FOO.BAR.EDU) ...
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 ]
Secure connection clients can be used as the communication channel in C-Kermit 7.0 and Kermit 95 1.1.16 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 <jaltman@columbia.edu>
*
* The following specification defines a set of functions to be exported from
* a DLL in order for the DLL to work with Kermit 95 version 1.1.17 or higher.
*
* The DLL is loaded by Kermit 95 via use of the command:
* SET NETWORK TYPE DLL dllname
*
* Notes:
* The functions specified here must be thread safe. It is possible
* for multiple threads to be calling any combination of functions
* simultaneously.
*
* The 1.1.17 interface does not provide for the ability of the
* DLL to query the user with echoing input, nor is the a method
* for querying the values of Kermit variables such as 'userid'
* or Kermit version number. This will be added in a later release.
*/
/*
* N E T O P E N - Network Open
*
* The network open function is called by Kermit 95 when a new connection
* is desired. Usually in response to:
* SET HOST command_line
*
* Parameters:
* command_line - the command line specified in the SET HOST command
* after quoting rules and variables have been applied.
* termtype - a string representing either the currently selected
* terminal type or a user specified string as per
* SET TELNET TERMINAL string
* height - initial height of the terminal window (chars)
* width - initial width of the terminal window (chars)
* readpass - a pointer to a function to be used to read a password
* without echoing
*
* Return values:
* 0 on success
* < 0 on failure
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netopen(char * command_line, char * termtype, int height, int width,
int (* readpass)(char * prompt,char * buffer, int length));
/*
* N E T C L O S - Network Close
*
* The network close function is called by Kermit 95 when the user requests
* a disconnect or in response to fatal error.
*
* Parameters: None
*
* Return values:
* 0 on success
* < 0 on failure
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netclos(void) ;
/*
* N E T T C H K - Network Terminal I/O Check
*
* The network terminal i/o check function is called regularly by Kermit 95
* to poll the status of the connection and to retrieve the number of input
* characters waiting to be processed. Because it is called frequently this
* function should be designed to be low cost.
*
* Parameters: None
*
* Return values:
* >= 0 number of characters waiting in the input queue
* < 0 indicates a fatal error on the connection and the connection
* should be closed.
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
nettchk(void);
/*
* N E T F L U I - Network Flush Input
*
* The network flush input function should clear the connection's input
* queue.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netflui(void);
/*
* N E T B R E A K - Network Break
*
* The network break signal is called in response to a user initiated
* break command. For example, on a serial device this should result in
* a Break signal and on a Telnet connection a Break Command is sent.
* For connection types without an equivalent simply return 0.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netbreak(void);
/*
* N E T I N C - Network Input Character
*
* The network input character is used to read the next character from
* the input queue.
*
* Parameters:
* timeout - 0 indicates no timeout, block until the next character
* is available;
* > 0 indicates a timeout value in seconds;
* < 0 indicates a timeout value in milliseconds;
*
* Return values:
* >= 0 is interpreted as a valid character
* -1 is a timeout [errorstr() is not called]
* < -1 is a fatal error
*
* return codes < -1 should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netinc(int timeout);
/*
* N E T X I N - Network Extended Input
*
* The network extended input is called to read a large number of waiting
* input characters. It will never be called with a number larger than
* reported as available and waiting by nettchk(). The function may return
* fewer characters than is requested. This function should not block.
*
* Parameters:
* count - number of characters to be read
* buffer - buffer of length count to be used to store the data
*
* Return values:
* >= 0 the number of characters actually returned by the function
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
netxin(int count, char * buffer);
/*
* N E T T O C - Network Terminal Output Character
*
* The network terminal output character transmits a single character
*
* Parameters:
* c - a single character to be output
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
nettoc(int c);
/*
* N E T T O L - Network Terminal Output Line
*
* The network terminal output line is used to output one or more
* characters.
*
* Parameters:
* buffer - contains the characters to be output
* count - the number of characters to be output from buffer
*
* Return values:
* >= 0 the number of characters actually output. The function
* should make its best attempt to transmit all 'count'
* characters.
* < 0 indicates a fatal error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
nettol(char * buffer, int count);
/*
* T T V T - Terminal to Virtual Terminal Mode
*
* Terminal to Virtual Terminal Mode is called to notify the DLL that
* Kermit 95 is about to enter terminal mode communications. This means
* either the CONNECT or DIAL commands will be sending output. In most
* cases, this will be either printable text or escape sequences.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
ttvt(void);
/*
* T T P K T - Terminal to Packet Mode
*
* Terminal to Packet Mode is called to notify the DLL that
* Kermit 95 is about to enter file transfer operations.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
ttpkt(void);
/*
* T T R E S - Terminal Restore Mode
*
* Terminal Restore Mode is called to notify the DLL that it should
* Kermit 95 restore to default settings.
*
* Parameters: None
*
* Return values:
* 0 indicates success
* < 0 indicates an error
*
* return codes should be defined such that they can be passed to
* errorstr() to retrieve an appropriate error message for the user.
*/
int
ttres(void);
/*
* T E R M I N F O - Terminal Information
*
* The terminal information function is called whenever the terminal
* type or window size is changed.
*
* Parameters:
* termtype - a string representing either the currently selected
* terminal type or a user specified string as per
* SET TELNET TERMINAL string
* height - initial height of the terminal window (chars)
* width - initial width of the terminal window (chars)
*
* Return values: None
*/
void
terminfo(char * termtype, int height, int width);
/*
* V E R S I O N - Version String
*
* Version is called to get a user displayable version string for use
* as part of the SHOW NETWORK command.
*
* Parameters: None
*
* Return values:
* a string which will not be deleted by the caller.
*/
const char *
version(void);
/*
* E R R O R S T R - Error String
*
* Error string is called to retrieve a user displayable error message
* describing the type of error being reported by the function.
*
* Parameters:
* error - the error value reported by the DLL function.
*
* Return values:
* a string which will not be deleted by the caller.
*/
const char *
errorstr(int error);
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]
RSA Security, Inc., has a very good Frequently Asked Questions
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.
There are two parts to the exchange. A private key that is never disclosed, and a public key that may be viewed by all. A 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 which is 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.
Due to the patent issues surrounding the RSA algorithms, the Kermit Project does not maintain a library or distribute any binaries that are built with the RSA algorithms. This policy can change when the RSA patent expires.
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 in order 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 need 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 will need 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:fred@company.com 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 will need 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.
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 you will use 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
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
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 will not 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.
Generate the self-signed certificate you will use 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
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. 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 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.
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 in conjunction 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
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.
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
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 which ever 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 will result 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 will need 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 which may be used to access the account 'userid'.
OpenSSL sources may be retrieved from the web site:
http://www.openssl.org/
As of this writing the current release of OpenSSL is 0.9.6b and 0.9.7 is under development. Kermit 95 1.1.20 works OpenSSL binaries produced by compiling versions 0.9.4 or higher. 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..
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..
[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]