security.txt

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

SECURITY FEATURES FOR AUTHENTICATION AND ENCRYPTION OF TCP/IP CONNECTIONS
IN C-KERMIT 7.0 AND KERMIT 95 1.1.19

30 January 2000

CONTENTS

    1. INTRODUCTION
    2. DISCLAIMERS
    3. AVAILABILITY
    3.1  Authentication and Encryption 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  Authentication and Encryption 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. GLOSSARY
    5. AUTHENTICATION PROTOCOL OVERVIEWS
    5.1 KERBEROS
    5.2 SECURE REMOTE PASSWORD (SRP)
    5.3 NT LAN MANAGER (NTLM)
    5.4 SSLv3 and TLSv1
    6. AUTHENTICATION AND ENCRYPTION COMMANDS
    6.1. TELNET-Related Commands
    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. EFFECTS OF ENCRYPTION ON FILE TRANSFER PERFORMANCE
    8. MULTI-HOMED HOSTS AND NETWORK ADDRESS TRANSLATORS
    9. OTHER NOTES
   10. VARIABLES
   10.1 GENERAL AUTHENTICATION VARIABLES
   10.2 KERBEROS VARIABLES
   10.3 SSL/TLS VARIABLES
   11. FUNCTIONS
   12. SCRIPTING HINTS
   12.1. Kerberos Autoget
   12.2. Autodestruction of Kerberos credentials
   12.3. Automated Prompting for Usernames
   12.4. Password Inclusion in Script Files
   12.5  Using Kermit Scripts to Produce Secure Telnet Services
   13. USING OTHER SECURITY METHODS WITH KERMIT
   13.1  Implementing other security methods for Kermit 95
   14. AN INTRODUCTION TO CERTIFICATES AND CERTIFICATE AUTHORITIES WITH OPENSSL
   14.1  What Are Certificates, Private Keys, CSRs, CAs, and CRLs?
   14.2  RSA Certificates v. DSA Certificates
   14.3  Should You Be Your own Certificate Authority?
   14.4  Generating a DSA CA (self-signed) certificate
   14.5  Generating a DSA CSR
   14.6  Generating a RSA CA (self-signed) certificate
   14.7  Generating a RSA CSR
   14.8  Signing a CSR with your CA certificate
   14.9  Revoking a Certificate
   14.10 Generating a CRL


1. INTRODUCTION

  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.  All information presented here
  is preliminary and subject to review, change, or withdrawal prior to final
  release.  NOTE: The terms "Windows 95" and "Windows 9x" in this document
  refer to both Windows 95 and Windows 98; the term "Windows NT" refers to
  Windows NT 3.51 and later and to Windows 2000.

Security is a hot topic on the Internet, and security methods abound.  Secure
connection methods are supported indirectly by the methods described in
"Supplement to 'Using C-Kermit', Second Edition", file ckermit2.txt, Section
2.7.4.  This document describes authentication methods that can be built into
Kermit 95 and C-Kermit.  Presently these are: Kerberos, Secure Remote Password
(SRP), Secure Sockets Layer(SSL)/Transport Layer Security(TLS), and Microsoft
NT LAN Manager (NTLM).

A secure connection is one that provides:

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

 . Authentication of the host to the user; and:

 . A shared secret that can be used with an encryption algorithm to ensure
   the data transmitted over the connection is understood by only the
   client and host.

C-Kermit and Kermit 95 are capable of creating and accepting secure
connections via a variety of methods:

 . Incoming and outgoing secure connections may be established using Telnet
   protocol coupled with Kerberos(TM), Secure Remote Password (SRP)(TM),
   Secure Sockets Layer (SSL)/Transport Layer Security (TLS), and Microsoft
   NTLM.

 . Outgoing secure connections may be established using Rlogin protocol
   coupled with Kerberos (TM).

 . Incoming and outgoing secure connections may be established using
   Secure Sockets Layer (SSL)/Transport Layer Security (TLS) alone.

1.1. Kerberos

Kerberos(TM) 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 or
encryption keys in clear text over the network.  Kerberos protocols are
defined in Internet RFCs 1510, 1964, and others.  You can read more about
Kerberos at:

  http://web.mit.edu/kerberos/www/
  http://nii.isi.edu/info/kerberos/
  http://nii.isi.edu/publications/kerberos-neuman-tso.html

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.

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.

1.2. SRP

Secure Remote Password (SRP)(TM) protocol is a method, developed at Stanford
University, by which two parties communicating over a TCP/IP connection can
authenticate each other in a secure manner through a Zero Knowledge
Identification system.  SRP protocols have not yet been accepted as RFCs.
You can read more about SRP at:

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

Once authentication has been achieved with either Kerberos or SRP, a shared
secret is available which can be used to establish an encrypted session.

1.3. NTLM

NT Lan Manager (NTLM) authentication is only implemented in Kermit 95.
Its only use is to authenticate Kermit 95 to Microsoft's NT Services for
Unix Telnetd.  NTLM does not negotiate a shared secret and therefore
cannot be used to establish encrypted sessions.  Therefore, connections
made with NTLM should not be considered secure.

1.4. Encryption

Export of encryption software or algorithms is regulated by United States law
(see Section 2).  United States and Canadian residents may contact the Kermit
Project for encryption modules that can be used to provide secure
communications using one of the following encryption algorithms via the Telnet
Encryption Option:

   cast128_cfb64   cast5_40_cfb64   des_cfb64   des3_cfb64
   cast128_ofb64   cast5_40_ofb64   des_ofb64   des3_ofb64

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.  Authentication of the server (and optionally the
client) is performed by exchanging ITU-T X.509 certificate chains (see Section
14 below), 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.

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

TLS may be used in conjunction wth Telnet Authentication methods such as
Kerberos, Secure Remote Password, and NTLM to provide the highest level of
data privacy with the strongest forms of mutual authentication.

The Kermit modules used to implement SSL/TLS are available only to residents
of the United States and Canada due to the restrictions on the export of
software that provides "crypto with a hole" functionality.


2. DISCLAIMERS

Current US law forbids export of strong encryption software from the USA to
all countries except Canada.  Thus security modules 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 modules listed in this
document, has been verified to negotiate and conduct authenticated and
encrypted sessions with Kerberos and/or SRP 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 Kerberized 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 and/or SRP 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
either Kerberos or Secure Remote Password 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 7.0 license).

Functional limitations:

 . Kerberos authentication is available only on Telnet and Rlogin connections.

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

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

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

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


3. AVAILABILITY

3.1 Authentication and Encryption 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

Beginning with version 1.1.16, Kermit 95 supports Kerberos Telnet
Authentication when any of the following Kerberos IV or Kerberos V
implementations are installed on a Windows 95 or Windows NT workstation:

  Kerberos version 4:
    . MIT Leash distribution:
        http://web.mit.edu/is/help/mink/

  For version 5:
    . MIT distribution:
        http://web.mit.edu/kerberos/www/
    . Cygnus Solutions' KerbNet 1.2:
        http://www.cygnus.com/techie/kerbnet/

Both Kerberos IV and Kerberos V may be installed on the same PC, and the same
copy of Kermit 95 can use either Kerberos version to make Telnet connections.
As of Kermit 95 1.1.18 Kerberized Rlogin connections are supported if the
Kerberos DLLs export necessary functionality.

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's
Telnet server if the host is Kerberized and if you have not instructed
Kermit 95 to the contrary.

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

MIT's Leash 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.

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