security.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

 2. Obtain the C-Kermit Authentication and Encryption support modules from
    Columbia University.  These are not available by FTP due to export
    restrictions.  Contact [e-mail] for details.

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

    If you wish to support ADH ciphers you must define SSL_ALLOW_ADH when
    building OpenSSL.

 4. Add a new entry to the C-Kermit makefile for your platform, that adds
    the following CFLAGS:

      -DCK_AUTHENTICATION -DCK_SSL

    Use "krbmit" as the target for builds.

    Add the path to the OpenSSL header files using the -I switch.  The
    location of these files is host-specific.  For example:

      -I/usr/local/ssl/include

    Add the path to the OpenSSL libraries using the -L switch.  The
    location of these files is host-specific.  For example:

      -L/usr/local/ssl/lib

    Add the appropriate libraries:

      -lssl -lcrypto

    Make sure the new entry points to the appropriate include files, and
    links with the appropriate libraries.  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.

Keep the OpenSSL support modules private, and put the C-Kermit binary where
it can be used, but not where it can be accessed by anonymous ftp or by anyone
who is outside the USA or Canada.

When C-Kermit 7.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 a custom X509_to_user() function to
provide the certificate to local userid mapping.  An example function 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.  The X509_to_user() function is the last function
in the ck_ssl.c module.

3.2.4.  Shadow Passwords in C-Kermit 7.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 7.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 7.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 7.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

C-Kermit 7.0's support for PAM is limited to Interactive Login.  PAM is
not compatible with the Kermit Protocol's REMOTE LOGIN mechanism.

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.


5. OVERVIEW OF AUTHENTICATION PROTOCOLS

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 or Cygnus (such as Leash, KRB5, or
KerbNet), or with Kermit's built-in functionality, explained below.

Once a Ticket Granting Ticket (TGT) is retrieved, Kermit can use it to retrieve
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 and no Login: or Password: prompt does appear when
connecting.

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 using either the DES-CFB64 or DES-OFB64 algorithms.
If one of these 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.

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.


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 hosts support CAST-128-CFB64, CAST-128-OFB64, CAST-40-CFB64,
CAST-40-OFB64, DES-CFB64, DES-OFB64, DES3-CFB64, DES3-OFB64 encryption
algorithms.


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 14 for an introduction to the concept of certificates.)

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

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

Kermit supports both kinds of connections:

 . Pure SSLv3 connections via SET HOST <host> <port> /SSL

 . Pure TLSv1 connections via SET HOST <host> <port> /TLS

 . SSLv3 connections negotiated by Tim Hudson's Telnet AUTH SSL option

 . TLSv1 connections negotiated by the IETF TN3270E Working Group's
   TELNET START_TLS option

The SSL and TLS negotations provide the client with authentication of the
host computer when the host's X.509 certificate is verified.  Authentication
of the client may be performed by the use of an X.509 certificate issued to
the end user, 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 might want to use the file of root certificates at
http://www.e-softinc.com/cacerts.txt.  This file is produced by E-Soft, Inc.,
as part of its monthly survey on secure server usage.  After downloading,
this file can be used by Kermit via the command:

  SET AUTH SSL VERIFY-FILE <path>/cacerts.txt

When Kermit is used as an IKSD, client certificates can be used for automatic
login.  If a certificate-to-userid mapping function is provided, the IKSD
logs the user in automatically if the certificate is verified and the
specified userid exists 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.

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

Note: A Unix telnetd that supports START_TLS is available from