SECURITY FEATURES FOR AUTHENTICATION AND ENCRYPTION
OF TCP/IP CONNECTIONS

In C-Kermit 8.0 and Kermit 95 1.1.21

Jeffrey Altman
The Kermit Project
Columbia University
http://www.columbia.edu/kermit/

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 ]


CONTENTS

    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 ]


1. INTRODUCTION

Security is the hot topic on the Internet and security systems and protocols abound. Secure connection methods are supported indirectly by the methods listed in Section 2.7.4 of Supplement to Using C-Kermit, Second Edition. This document describes the security methods that can be built into Kermit 95 and C-Kermit for establishing terminal and file transfer connections. Presently this list includes:

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:

1.1. Authentication Systems

This section describes the authentication systems supported by C-Kermit and Kermit 95.

1.1.1. Kerberos

Kerberos is a method, developed at Massachusetts Institute of Technology, by which two parties communicating over a TCP/IP connection can authenticate each other through a trusted 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:

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.

1.1.2. SRP

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:

  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.

1.1.3. NTLM

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 Pro, and the NT Services for Unix products. Kermit 95 can also use NTLM to authenticate incoming Telnet sessions when it is running on Windows NT/2000/XP. Kermit 95 when running on Windows 95/98/98SE/ME 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 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.

1.1.4. X.509 certificates

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 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.

1.2. Encryption

Export of commercial software incorporating encryption algorithms is regulated by United States law (see Section 2).

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.

1.2.1. Telnet Encryption

The following encryption algorithms can be negotiated via the Telnet Encryption option (RFC 2946) when used in conjunction with Kerberos IV; Kerberos V; or Secure Remote Password:

When the Telnet STARTTLS option is negotiated, SSL/TLS is used to provide encryption services for the Telnet session.

Encryption services for FTP sessions is provided on a per authentication method basis.

1.2.3 SSL/TLS Encryption

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 Section 15), which are then verified by the receiver. Unlike raw public keys, X.509 certificates may be revoked by issuing a certificate revocation list (CRL) which is to be checked by the receiver during verification of the certificate chain.

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

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

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 ]


2. DISCLAIMERS

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 ]


3. AVAILABILITY

3.1. Security in Kermit 95

Kermit 95 comes precompiled with support for Kerberos 4, Kerberos 5, Secure Remote Password, NT Lan Manager authentication, and OpenSSL's SSLv3 and TLSv1.

3.1.1. Kerberos in 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/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.

3.1.1.1. Notes on the Kerberos IV configuration files

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

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.

3.1.1.2. Notes on the Kerberos V configuration file

Kerberos V uses a single configuration file, KRB5.CONF (KRB5.INI on Windows). This file must be customized for the domains, realms, and hosts used in your network environment. For example:

[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
        }

3.1.2. Secure Remote Password protocol in Kermit 95

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/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.

3.1.3. NT LAN Manager Authentication in Kermit 95

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.

3.1.4. OpenSSL support for SSLv3 and TLSv1 in Kermit 95

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/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.

3.2. Security in C-Kermit 8.0

C-Kermit 8.0 may 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:

3.2.1. Kerberos in C-Kermit 8.0

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.

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

      http://web.mit.edu/kerberos/www/ or:
      http://web.mit.edu/network/kerberos-form.html
    

  2. Choose a Kerberos 4 installation (from MIT) and retrieve a source code kit from the appropriate site:

      http://web.mit.edu/kerberos/www/ or:
      http://web.mit.edu/network/kerberos-form.html
    

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

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

      -DCK_AUTHENTICATION -DCK_KERBEROS
    

    For Kerberos 4 include:

      -DKRB4 $(K4INC)
    

    For Kerberos 5 include:

      -DKRB5 $(K5INC)
    

    For Kerberos 5 with Kerberos 4 compatibility mode:

      -DKRB5 -DKRB524 -DKRB4 $(K5INC)
    

    If you desire DES and 3DES encryption include:

      -DCK_ENCRYPTION -DCK_DES
    

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

      $(K4LIB) -lkrb
    

    For Kerberos 5 include:

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

    For Kerberos 4 compatibility mode with Kerberos 5 include:

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

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

      -I/usr/kerberos/include
    

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

      -L/usr/kerberos/lib
    

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

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

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

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

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

3.2.2. Secure Remote Password protocol in C-Kermit

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.

  1. Retrieve the SRP 1.7.4 source code kit from:

      http://srp.stanford.edu/srp/
    

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

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

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

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

      -DCK_AUTHENTICATION -DCK_SRP $(SRPINC)
    

    If you built SRP with OpenSSL add:

      $(SSLINC)
    

    If you desire telnet encryption include:

      -DCK_ENCRYPTION
    

    For CAST encryption add:

      -DCK_CAST
    

    For DES and 3DES encryption add:

      -DCK_DES -DLIBDES
    

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

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

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

      $(SRPLIB) -lsrp -lgmp -lkrypto
    

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

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

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

      -I/usr/local/include
    

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

      -L/usr/local/lib
    

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

      -I/usr/local/ssl/include
    

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

      -L/usr/local/ssl/lib
    

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

    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.

3.2.3. OpenSSL support for SSLv3 and TLSv1 in C-Kermit 8.0.

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.

  1. Retrieve the OpenSSL 0.9.6b (or later) source code kit from:

      http://www.openssl.org/
    

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

    OpenSSL has many features that can be selected when it is configured prior to compiling the libraries. One feature 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 Kerberos 5 ciphers.

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

      -DCK_AUTHENTICATION -DCK_SSL $(SSLINC)
    

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

      -DZLIB
    

    Add the appropriate libraries to LIBS:

      $(SSLLIB) -lssl -lcrypto
    

    For ZLIB compression add to LIBS:

      -lzlib
    

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

      -I/usr/local/ssl/include
    

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

      -L/usr/local/ssl/lib
    

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

    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.

3.2.4. Shadow Passwords in C-Kermit 8.0.

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 in order to processes to determine the location of 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

3.2.5. Pluggable Authentication Module (PAM) support in C-Kermit 8.0

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 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 ]


4. KERBEROS GLOSSARY

Listed alphabetically, not topologically.

Entity
In this document, a user, host, or service.

Authentication
The process by which one entity proves its identity to another entity on the Internet.

Client
An entity that can obtain a ticket (see Ticket).

Credentials Cache
The location where Kerberos stores tickets. The credentials cache can be a file or a buffer in memory.

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

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

Host
A computer that can be accessed over a network.

KDC
Key Distribution Center, a machine that issues Kerberos tickets.

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

Postdated Ticket
A ticket that does not become valid until after a specified time. This allows for secure unattended operations.

Principal
A string that names a specific entity to which a set of credentials may be assigned. It generally has three parts, primary/instance@REALM:
  1. Primary: Identifies the user or service.
  2. Instance: Usually a hostname or REALM.
  3. REALM: Logical network served by a single Kerberos database and KDC.

Proxiable Ticket
A ticket that may be given to a service to allow the service to impersonate the user for whom the ticket has been issued.

Ticket
A temporary set of electronic credentials that verifies the identity of its owner to a particular service.

TGT
Ticket Granting Ticket. A special ticket that lets its owner obtain additional tickets within the same realm. A TGT is obtained during the initial authentication process.

[ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]


5. SECURITY PROTOCOL OVERVIEWS

The following sections attempt to provide an overview of how each of the supported authentication protocols operates.

5.1. Kerberos Overview

Before making a Kerberized connection, you have to 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. Contact the site administrator for details.

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.

5.2. Secure Remote Password (SRP) Overview

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 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.

5.3. NT LAN Manager (NTLM) Overview

Microsoft's native authentication method is NTLM. It is implemented in Windows 9x and NT and requires no configuration on the part of the user. When K95 is used on either Win9x or NT 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 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.

5.4. SSLv3 and TLSv1 Overview

(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 negotiated 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 negotiations provide the client with authentication of the host computer when the host's X.509 certificate is verified or when Kerberos 5 is used. 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 ]


6. SECURITY COMMANDS

Kermit has a full repertoire of commands for selecting and controlling security. Bear in mind that these are targeted primarily at the network or site manager and not at the ordinary user. In a typical application, a university creates a customized distribution for its user community that contains all the appropriate security (and other) setups, so end users get secure connections without doing anything special or even knowing that they have them.

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:

CHECK KERBEROS
tells whether your version of Kermit has been built to include the Kerberos support even if it cannot function on your system.

CHECK NTLM
Tells whether your version of Kermit has been built to include the NTLM support even if it cannot function on your system.

CHECK SRP
Tells whether your version of Kermit has been built to include the SRP support even if it cannot function on your system.

CHECK SSL/TLS
Tells whether your version of Kermit has been built to include the SSL/TLS support even if it cannot function on your system.

IF AVAILABLE ENCRYPTION
Tells whether telnet encryption is available in your version of Kermit (e.g. if the K95CRYPT.DLL (or K2CRYPT.DLL) file is installed on your PC).

IF AVAILABLE KERBEROS4 (or KRB4, or K4)
Tells whether Kerberos 4 is available in your version of Kermit (e.g. if the Kerberos 4 DLLs are installed on your PC).

IF AVAILABLE KERBEROS5 (KRB5, K5)
Tells whether Kerberos 5 is available in your version of Kermit.

IF AVAILABLE NTLM
Tells whether NT Lan Manager protocol is available in your version of Kermit.

IF AVAILABLE SRP
Tells whether Secure Remote Password protocol is available in your version of Kermit.

IF AVAILABLE { SSL, TLS }
Tells whether SSL/TLS protocol is available in your version of Kermit.

6.1. Security Commands Related to Establishing Connections

Kermit supports a wide variety of methods for establishing secure TCP/IP connections:
TELNET
The Telnet protocol may be used to establish the most secure connections with the greatest flexibility of choice of authentication method and privacy establishment. Kermit's Telnet implementation supports Kerberos 4, Kerberos 5, Secure Remote Password (SRP), NTLM, and X.509 certificates for client and server authentication. Privacy establishment may be performed with the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) cipher suites, or DES, CAST, or 3DES streaming ciphers.

FTP
FTP may be used to establish secure connections for both the command and data channels as described in Internet RFC 2228. Kermit's FTP implementation supports Kerberos 4, GSSAPI Kerberos 5, SRP, and SSL/TLS.

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

RLOGIN
The Remote Login protocol may be used with either Kerberos 4 or Kerberos 5 to establish authenticated connections. After authentication the DES streaming cipher may be used to provide privacy.

Secure Socket Layer (SSL) or Transport Layer Security (TLS)
The SSL and TLS protocols may be used by themselves to establish a private connection to a remote host. Authentication of the server (and perhaps the client) is performed via an exchange and verification of X.509 certificates or Kerberos 5 credentials. Kermit also provides support for use of Telnet protocol over a secure SSL or TLS tunnel.

Kerberos 5 User to User
The Kerberos 5 user to user protocol may be used to establish an authenticated and private connection between two end user operated copies of Kermit.

6.1.1. Commands Related to Secure Telnet Connections

The Telnet protocol is one of the most flexible protocols ever used on computer networks. Its flexibility provides it with both functionality and complexity. Kermit provides commands to manage every aspect of the telnet connection. These commands are described in the TELNET Reference. This section focuses on commands that are used to manage how secure connections are established using Telnet.

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.

SET TELOPT [ { /CLIENT, /SERVER } ] AUTHENTICATION { ACCEPTED, REFUSED, REQUESTED, REQUIRED }
ACCEPT or REFUSE authentication bids, or actively REQUEST authentication. REQUIRED refuses and closes the connection if authentication is not successfully negotiated when either making or accepting connections. The default is REQUESTED.

SET TELNET AUTHENTICATION TYPE { AUTOMATIC, KERBEROS4, KERBEROS5, NTLM, SRP, SSL, NONE }
AUTOMATIC is the default. Available options can vary depending on the features Kermit was built to support and the operating system configuration; type SET TELNET AUTHENTICATION TYPE ? for a list.

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

When Kermit is the Telnet server:
AUTOMATIC results in available authentication methods being offered to the telnet client in the following order: KERBEROS_V, KERBEROS_IV, SRP, SSL, NTLM

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

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

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

SET TELNET AUTHENTICATION HOW-FLAG { ANY, MUTUAL, ONE-WAY }
Specifies which values for the HOW-FLAG should be accepted as a client or offered as a server. The default is ANY.

SET TELNET AUTHENTICATION ENCRYPT-FLAG { ANY, NONE, TELOPT, TLS }
Specifies which values for the ENCRYPT-FLAG should be accepted as a client or offered as a server. The default is ANY.

The 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.

SET TELOPT [ { /CLIENT, /SERVER } ] ENCRYPTION { ACCEPTED, REFUSED, REQUESTED, REQUIRED } { ACCEPTED, REFUSED, REQUESTED, REQUIRED }
The first parameter specifies the Kermit-to-peer state. The second parameter specifies the peer-to-Kermit state. The default is ACCEPTED REQUESTED.

SET TELNET ENCRYPTION TYPE { AUTOMATIC, CAST128_CFB64, CAST128_OFB64, CAST5_40_CFB64, CAST5_40_OFB64, DES_CFB64, DES_OFB64, DES3_CFB64, DES3_OFB64, NONE }
AUTOMATIC allows the host to choose the preferred type of encryption. Other values allow a specific encryption method to be specified. AUTOMATIC is the default. The list of options varies depending on the encryption types selected at compilation time. An encryption method can be used only if there is enough key data available. Kerberos 4 can use only DES encryption because it provides a shared secret only 56 bits in length.

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.

SET TELOPT [ { /CLIENT, /SERVER } ] START_TLS { ACCEPTED, REFUSED, REQUESTED, REQUIRED }
ACCEPT or REFUSE a request to negotiate TLS, or actively REQUEST that TLS be negotiated. REQUIRED refuses and closes the connection if the peer refuses to negotiate TLS or the TLS negotiations end in failure. ACCEPTED by default when a client. REQUESTED by default when a server.

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

SET TELOPT [ {/CLIENT } ] FORWARD_X { ACCEPTED, REFUSED, REQUESTED, REQUIRED }
ACCEPT or REFUSE a request to negotiate FORWARD_X, or actively REQUEST that FORWARD_X be negotiated. REQUIRED refuses and closes the connection if the peer refuses to negotiate FORWARD_X or the FORWARD_X negotiations end in failure. ACCEPTED by default when a client. Kermit does not support FORWARD_X when it is a server.

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

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

When establishing a secure connection there are potentially three usernames associated with the connection: the name of the user on the local machine; the name 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.

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

All forms of authentication rely on some secret information that only the user (or service) being authenticated 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 language.

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

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

SET TELNET DEBUG ON
Displays all TELNET negotiations in full detail.

6.1.2. Commands Related to Secure FTP Connections

C-Kermit 8.0 and Kermit 95 1.1.21 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 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:

SET FTP AUTHTYPE list
Specifies an ordered list of authentication methods to be when FTP AUTOAUTHENTICATION is ON. The default list is: GSSAPI-KRB5, SRP, KERBEROS_V4, TLS, SSL. It should be noted that TLS and SSL can be used to secure an anonymous connection.
SET FTP AUTOAUTHENTICATION { ON, OFF }
Specifies whether or not authentication should be negotiated by the FTP OPEN command. Default is ON.
SET FTP AUTOENCRYPTION { ON, OFF }
Specifies whether encryption and message integrity (privacy) should be negotiated by the FTP OPEN command. Default is ON.
SET FTP AUTOLOGIN { ON, OFF }
Tells Kermit whether to try to automatically log you in (using the FTP USER command) during the FTP OPEN command. Default is ON.
SET FTP COMMAND-PROTECTION-LEVEL { CLEAR, CONFIDENTIAL, PRIVATE, SAFE }
Tells what level of protection is applied to the FTP command channel. CLEAR means no protection at all. CONFIDENTIAL means the messages are encrypted but not integrity protected. PRIVATE means the messages are encrypted and integrity protected. SAFE means the messages are integrity protected but not encrypted.
SET FTP CREDENTIAL-FORWARDING { ON, OFF }
Specifies whether end-user credentials are to be forwarded to the server if supported by the authentication method. At the moment only GSSAPI-KRB5 supports credentials forwarding.
SET FTP DATA-PROTECTION-LEVEL { CLEAR, CONFIDENTIAL, PRIVATE, SAFE }
Tells what level of protection is applied to the FTP data channel. CLEAR means no protection at all. CONFIDENTIAL means the messages are encrypted but not integrity protected. PRIVATE means the messages are encrypted and integrity protected. SAFE means the messages are integrity protected but not encrypted.
SET FTP SRP CIPHER cipher
Specifies a cipher to be used to encrypt FTP data if SRP security is negotiated. The default cipher is DES3_ECB.
SET FTP SRP HASH hash
Specifies a hash to be used to integrity protect FTP data if SRP security is negotiated. The default hash is SHA1.

6.1.3. Commands Related to Secure HTTP Connections

C-Kermit 8.0 and Kermit 95 1.1.21 provide support for secure HTTP requests via the use of SSL or TLS. Secure connections are established automatically when the destination service is https or the port number is 443. Alternatively, SSL or TLS may be utilized with arbitrary port numbers via use of a switch.

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.

6.2. The SET AUTHENTICATION Command

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

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

6.2.1. Kerberos Set Commands

SET AUTHENTICATION { KERBEROS5 } ADDRESSES {list of IP addresses}
When a list of IP addresses is specified, these addresses will be added to the contents of Kerberos 5 tickets retrieved via Kermit commands.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } AUTODESTROY { ON-CLOSE, ON-EXIT, NEVER }
When ON, Kermit destroys all credentials in the default credentials cache upon Kermit termination. Default is NEVER.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } AUTOGET { ON, OFF }
When ON, if the host offers Kerberos 4 or Kerberos 5 authentication and Kermit is configured to use that authentication method and there is no TGT, Kermit automatically attempts to retrieve one by prompting for the password (and principal if needed.) Default is ON.

SET AUTHENTICATION KERBEROS5 CREDENTIALS-CACHE cache-name
Specifies an alternative credentials cache. This is useful when you need to maintain two or more sets of credentials for different realms or roles. The default is specified by the environment variable KRB5CCNAME or as reported by the Kerberos 5 library.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } CHECK-ADDRESSES { ON, OFF }
When ON, Kermit uses the embedded IP address(es) in the ticket to determine validity. When OFF, IP addresses are ignored by Kermit. Default is ON.

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

SET AUTHENTICATION KERBEROS5 GET-K4-TGT { ON, OFF }
ON specifies that Kerberos 4 credentials should be requested each time Kerberos 5 credentials are requested with AUTH KERBEROS5 INIT. The default is OFF.

SET AUTHENTICATION KERBEROS4 INSTANCE instance
Allows a Kerberos 4 instance to be specified as a default (if needed).

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } LIFETIME minutes
Specifies the lifetime of the TGTs requested from the KDC. The default is 600 minutes (10 hours).

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

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

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

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

in the Kermit initialization file or connection script.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PROMPT PASSWORD prompt
Specifies a custom prompt to be used when prompting for a password. The Kerberos prompt strings may contain two "%s" replacement fields. The first %s is replaced by the principal name; the second by the realm.

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PROMPT PRINCIPAL prompt
Specifies a custom prompt to be used when prompting for the Kerberos principal name. No %s replacement fields may be included. Kermit prompts for a principal name when retrieving a TGT if the command:

  SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL {}

has been issued.

SET AUTHENTICATION KERBEROS5 PROXIABLE { ON, OFF }
When ON, specifies that Kerberos 5 credentials should be proxiable. The default is OFF.

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

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } REALM name
If no default is set, the default realm configured for the Kerberos libraries is used. Abbreviations are accepted.

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

6.2.2. SRP SET Commands

SET AUTHENTICATE SRP PROMPT PASSWORD text
Specifies a custom prompt to be used when prompting for a password. prompt may contain a single instance of "%s" which is replaced by the user's login name.

6.2.3. SSL/TLS (OpenSSL) SET Commands

In all of the following commands "SSL" and "TLS" are aliases.

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

Key Exchange Algorithms:
  • kRSA: RSA key exchange
  • kDHr: Diffie-Hellman key exchange (key from RSA cert)
  • kDHd: Diffie-Hellman key exchange (key from DSA cert)
  • kEDH: Ephemeral Diffie-Hellman key exchange (temporary key)
  • kKRB5: Kerberos 5

    Authentication Algorithm:
  • aNULL: No authentication
  • aRSA: RSA authentication
  • aDSS: DSS authentication
  • aDH: Diffie-Hellman authentication
  • aKRB5: Kerberos 5

    Cipher Encoding Algorithm:
  • eNULL: No encoding
  • DES: DES encoding
  • 3DES: Triple DES encoding
  • RC4: RC4 encoding
  • RC2: RC2 encoding
  • IDEA: IDEA encoding

    MAC Digest Algorithm:
  • MD5: MD5 hash function
  • SHA1: SHA1 hash function
  • SHA: SHA hash function (should not be used)

    Aliases:
  • ALL: all ciphers
  • SSLv2: all SSL version 2.0 ciphers (should not be used)
  • SSLv3: all SSL version 3.0 ciphers
  • EXP: all export ciphers (40-bit)
  • EXPORT56: all export ciphers (56-bit)
  • LOW: all low strength ciphers (no export)
  • MEDIUM: all ciphers with 128-bit encryption
  • HIGH: all ciphers using greater than 128-bit encryption
  • RSA: all ciphers using RSA key exchange
  • DH: all ciphers using Diffie-Hellman key exchange
  • EDH: all ciphers using Ephemeral Diffie-Hellman key exchange
  • ADH: all ciphers using Anonymous Diffie-Hellman key exchange
  • DSS: all ciphers using DSS authentication
  • KRB5: Kerberos 5
  • NULL: all ciphers using no encryption
  • Each item in the list may include a prefix modifier:

    "+"
    Move cipher(s) to the current location in the list
    "-"
    Remove cipher(s) from the list (may be added again by a subsequent list entry)
    "!"
    Kill cipher from the list (it may not be added again by a subsequent list entry)

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

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

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

    All algorithms including ADH and export but excluding patented 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.

    SET AUTHENTICATE { SSL, TLS } CRL-DIR directory
    Specifies a directory that contains certificate revocation files, where each file is named by the hash of the certificate issuer name. OpenSSL expects the hash symlinks to be made like this:

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

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

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

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

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

    SET AUTHENTICATE { SSL, TLS } CRL-FILE filename
    Specifies a file that contains certificate revocations used to reject the validation of certificates.

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

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

    SET AUTHENTICATE { SSL, TLS } DH-PARAM-FILE filename
    Specifies a file containing DH parameters which are used to generate temporary DH keys. If a DH parameter file is not provided Kermit uses a fixed set of parameters depending on the negotiated key length. Kermit provides DH parameters for key lengths of 512, 768, 1024, 1536, and 2048 bits.

    SET AUTHENTICATE { SSL, TLS } DSA-CERT-CHAIN-FILE filename
    Specifies a file containing a DSA certificate chain to be sent along with the DSA-CERT to the peer. This file must only be specified if Kermit is being used as a server and the DSA certificate was signed by an intermediary certificate authority.

    SET AUTHENTICATE { SSL, TLS } DSA-CERT-FILE filename
    Specifies a file containing a DSA certificate to be sent to the peer to authenticate the host or end user. The file may contain the matching DH private key instead of using the DSA-KEY-FILE command.

    SET AUTHENTICATE { SSL, TLS } DSA-KEY-FILE filename
    Specifies a file containing the private DH key that matches the DSA certificate specified with DSA-CERT-FILE. This command is only necessary if the private key is not appended to the certificate in the file specified by DSA-CERT-FILE.

    Note: When 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
    

    SET AUTHENTICATE { SSL, TLS } RANDOM-FILE filename
    Specifies a file containing random data to be used when initializing the Pseudo Random Number Generator (PRNG) engine. This file will be overwritten with new random data after the file is read.

    SET AUTHENTICATE { SSL, TLS } RSA-CERT-CHAIN-FILE filename
    Specifies a file containing a RSA certificate chain to be sent along with the RSA-CERT to the peer. This file must only be specified if Kermit is being used as a server and the RSA certificate was signed by an intermediary certificate authority.

    SET AUTHENTICATE { SSL, TLS } RSA-CERT-FILE filename
    Specifies a file containing a RSA certificate to be sent to the peer to authenticate the host or end user. The file may contain the matching RSA private key instead of using the RSA-KEY-FILE command.

    SET AUTHENTICATE { SSL, TLS } RSA-KEY-FILE filename
    Specifies a file containing the private RSA key that matches the RSA certificate specified with RSA-CERT-FILE. This command is only necessary if the private key is not appended to the certificate in the file specified by RSA-CERT-FILE.

    Note: When 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
    

    SET AUTHENTICATE { SSL, TLS } VERBOSE { ON, OFF }
    Specifies whether information about the authentication (the certificate chain) should be displayed upon making a connection.

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

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

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

    SET AUTHENTICATE { SSL, TLS } VERIFY-DIR directory
    Specifies a directory that contains root CA certificate files used to verify the certificate chains presented by the peer. Each file is named by a hash of the certificate.

    OpenSSL expects the hash symlinks to be made like this:

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

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

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

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

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

    SET AUTHENTICATE { SSL, TLS } VERIFY-FILE file
    Specifies a file that contains root CA certificates to be used for verifying certificate chains.

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

    6.3. The AUTHENTICATE Command (Kerberos Only)

    The AUTHENTICATE command obtains or destroys Kerberos tickets and lists information about them. The general format is:

    AUTHENTICATE { KERBEROS4, KERBEROS5 [ switches ] } action [ switches ]
    The use of command switches is described in Section 1.5 of the C-Kermit 7.0 Update Notes. The actions are INITIALIZE, DESTROY, and LIST-CREDENTIALS.

    The INITIALIZE command is the most complex of Kermit's security commands, and its format is different for Kerberos 4 and Kerberos 5:

    Kerberos 4:
    AUTH K4 INITIALIZE [ k4-switches ] [ principal ]

    Kerberos 5:
    AUTH K5 [ k5-switches ] { INITIALIZE ..., DESTROY, LIST-CREDENTIALS, ...}

    All switches are optional. The Kerberos 4 INITIALIZE switches are:

    /INSTANCE:name
    Allows an Instance to be specified (see Glossary).

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

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

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

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

    /REALM:name
    Allows an alternative Realm to be specified (see Glossary).

    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:

    /ADDRESSES:list-of-ip-addresses
    Specifies a list of IP addresses that should be placed in the Ticket Granting Ticket in addition to the local machine addresses.

    /FORWARDABLE
    Requests forwardable tickets.

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

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

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

    /NO-KERBEROS4
    Instructs Kermit to not attempt to retrieve Kerberos 4 credentials.

    /NOT-FORWARDABLE
    Requests non-forwardable tickets.

    /NOT-PROXIABLE
    Requests non-proxiable tickets.

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

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

    /PROXIABLE
    Requests proxiable tickets.

    /REALM:string
    Allows an alternative realm to be specified.

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

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

    /SERVICE:string
    Allows a service other than the ticket granting service to be specified.

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

    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.

    AUTHORIZE K5 LIST-CREDENTIALS [ switches ]
    Shows start time, expiration time, service or principal name, plus the following additional information depending the switches:

    /ADDRESSES
    Displays the hostnames and/or IP addresses embedded within the tickets.

    /ENCRYPTION
    Displays the encryption used by each ticket (if applicable):
    • DES-CBC-CRC
    • DES-CBC-MD4
    • DES-CBC-MD5
    • DES-CBC-RAW
    • DES-HMAC-SHA1
    • DES3-CBC-RAW
    • DES3-CBC-SHA
    • DES3-HMAC-SHA1

    /FLAGS
    provides the following information (if applicable) for each ticket:
    • F - Ticket is Forwardable
    • f - Ticket was Forwarded
    • P - Ticket is Proxiable
    • p - Ticket is a Proxy
    • D - Ticket may be Postdated
    • d - Ticket has been Postdated
    • i - Ticket is Invalid
    • R - Ticket is Renewable
    • I - Ticket is the Initial Ticket
    • H - Ticket has been authenticated by Hardware
    • A - Ticket has been Pre-authenticated

    6.4. OTHER SECURITY-RELATED COMMANDS

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

    SET TCP REVERSE-DNS-LOOKUP { ON, OFF }
    Specifies whether or not a Reverse DNS Lookup should be performed to determine the hostname assigned to the IP address used to connect to the host.

    For mutual authentication to succeed, the client and the server must agree on the name to be used for the server. It is common for servers to have more than one name. This is especially true for clusters of servers that provide the same function and are referenced by an alias. For 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 ]


    7. ESTABLISHING A SECURE CONNECTION

    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.

    7.1. Using the SET HOST 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:

    SET HOST [ switches ] hostname-or-address [ service ] [ protocol-switch ]
    Establishes a connection to the specified network host on the currently selected network type. For TCP/IP connections, the default service is TELNET and the default protocol is TELNET. Not all protocols have a default service name.

    The following switches are useful with secure connections:

    /CONNECT
    Enter CONNECT (terminal) mode automatically if the connection is successful.

    /SERVER
    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 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.

    7.2. Using TELNET protocol

    The TELNET command combines a number of commands related to secure telnet connections into a single interface.

    TELNET /AUTH:type /ENCRYPT:type /USERID:[name] /PASSWORD:[string] host port
    The TELNET command is a shortcut for making interactive connections. It is the equivalent of specifying:

      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:

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

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

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

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

    7.3. Using RLOGIN protocol

    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).

    RLOGIN /ENCRYPT /KERBEROS4 /KERBEROS5 hostname username
    The RLOGIN command is a shortcut for making interactive connections. It is the equivalent of specifying:

      SET LOGIN USERID ...
      SET HOST /CONNECT hostname service [ protocol-switch ]
    

    where the combinations of /ENCRYPT /KERBEROS4 /KERBEROS5 result in the following protocol-switches:

    /KERBEROS4
    means service klogin and protocol k4login

    /KERBEROS4 /ENCRYPT
    means service eklogin and protocol ek4login

    /KERBEROS5
    means service klogin and protocol k5login

    /KERBEROS5 /ENCRYPT
    means service eklogin and protocol ek5login

    7.4. Using FTP protocol

    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
    

    7.5. Using HTTP protocol

    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
    

    7.6. Using Only SSL or TLS

    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.

    7.7. Using Kerberos 5 User to User protocol

    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 ]


    8. EFFECTS OF ENCRYPTION ON FILE TRANSFER PERFORMANCE

    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 avoided.

    [ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]


    9. MULTI-HOMED HOSTS AND NETWORK ADDRESS TRANSLATORS

    Kermit is designed to allow authentication with hosts whose names resolve to multiple (randomized) IP addresses.

    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 ]


    10. OTHER NOTES

    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.

    [ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]


    11. VARIABLES

    11.1. General Authentication Variables

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

    \v(authstate)
    String indicating current state of authentication:

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

    \v(authtype)
    String indicating which telnet (or other) authentication method is in use.

    "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
    
    \v(secure)
    The numeric value 1 if the connection is encrypted and 0 otherwise.

    11.2. Kerberos Variables

    \v(krb5cc)
    Current kerberos V credentials cache.
    \v(krb5princ)
    Current kerberos V principal name.
    \v(krb5realm)
    Current kerberos V realm name.
    \v(krb5errno)
    Last Kerberos V errno
    \v(krb5errmsg)
    Last Kerberos V error message
    \v(krb4princ)
    Current kerberos IV principal name.
    \v(krb4realm)
    Current kerberos IV realm name.
    \v(krb4errno)
    Last Kerberos IV errno
    \v(krb4errmsg)
    Last Kerberos IV error message

    11.3. SSL/TLS Variables

    \v(x509_issuer)
    The issuer string from the peer's X.509 certificate
    \v(x509_subject)
    The subject string from the peer's X.509 certificate

    [ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]


    12. FUNCTIONS

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

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

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

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

    1. it exists in the current cache file;
    2. it is not expired;
    3. it is not marked invalid (K5 only);
    4. it was issued from the current IP address

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

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

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

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

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

    [ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]


    13. SCRIPTING HINTS

    13.1. Kerberos Autoget

    When developing scripts to be used without user interaction you should turn off the Kerberos AutoGet TGT feature with

      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
        }
      }
    

    13.2. Autodestruction of Kerberos Credentials

    When Kermit is used on a machine in a public lab and Kerberos is used for authentication it is often desireable to not have the Kerberos credentials survive the current session.

    SET AUTH { K4, K5} AUTODESTROY { ON-CLOSE, ON-EXIT }
    Automates the destruction of Kerberos credentials under the specified condition.

    13.3. Automated prompting for usernames

    To prevent Kermit from using the username reported by the local operating system for the remote userid and kerberos principal use:

      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.

    13.4. Password Inclusion in Script Files

    Although it is not recommended (since storing passwords openly in a file, especially on a PC, is a serious security risk), connections may be scripted without user interaction:

      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.

    13.5. Using Kermit Scripts to Produce Secure Telnet Services

    The following series of commands causes a Kermit script to accept only authenticated and encrypted connections:

      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 ]


    14. USING OTHER SECURITY METHODS WITH KERMIT

    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 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/
    

    14.1. Implementing Other Security Methods for Kermit 95

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

      SET NETWORK TYPE DLL dll-file
    

    The connection is then made with a SET HOST command

      SET HOST command-line
    

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

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

    [ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]


    15. AN INTRODUCTION TO CERTIFICATES AND CERTIFICATE AUTHORITIES WITH OPENSSL

    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 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.

    15.1. What Are Certificates, Private Keys, CSRs, CAs, and CRLs?

    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. 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.

    15.2. RSA certificates vs. DSA Certificates

    The important differences between RSA and DSA certificates are:

    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.

    15.3. Should You Be Your Own Certificate Authority?

    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 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 extensions 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 extensions 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_extensions ] 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.

    15.4. Generating a DSA CA (self-signed) Certificate

    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 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
    

    15.5. Generating a DSA CSR

    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
    

    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 commercial CAs if you do not wish to be your own CA.

    15.6. Generating a RSA CA (self-signed) certificate

    Change the current working directory to openssl/rsaCA/.

    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
    

    15.7. Generating a RSA CSR

    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. 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 commercial CAs if you do not wish to be your own CA.

    15.8. Signing a CSR with your CA certificate

    If you are signing a DSA certificate change directory to openssl/dsaCA/ and use a caname of "CA_DSA". If you are signing a 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 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
    

    15.9. Revoking a Certificate

    If you are revoking a DSA certificate change directory to openssl/dsaCA/ and use a caname of "CA_DSA". If you are revoking a 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.

    15.10. Generating a 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

    15.11. Mapping a Client Certificate to a User ID

    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 which ever one you choose to use in your environment.

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

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

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

    This method is safer than the uniqueIdentifier, but it is still placing a lot of trust in the Certificate Authority. If you are not issuing the certificates yourself you 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.

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

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

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

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

    15.11.1 Mapping a Client Certificate to a User ID in Kermit 95

    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 will require 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/
    

    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..

    15.11.2 Mapping a Client Certificate to a User ID in C-Kermit

    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..

    16. SECURE SHELL CLIENT FUNCTIONALITY

    Secure Shell support is being added to C-Kermit 8.0 and Kermit 95 1.1.21 through the integration of OpenSSH. This section will be completed when the code is publicly available.

    [ Top ] [ Case Study ] [ C-Kermit ] [ C-Kermit 8.0 ] [ Kermit Home ] [ Kermit 95 ] [ Kermit Home ]


    Kermit Security / Columbia University / kermit@columbia.edu / 19 November 2001