SECURITY (AUTHENTICATION AND ENCRYPTION) FOR TCP/IP CONNECTIONS IN KERMIT 

8 April 1998

CONTENTS

    1. INTRODUCTION
    2. DISCLAIMERS
    3. AVAILABILITY
    3.1. Kerberos in Kermit 95
    3.2. Secure Remote Password (SRP) in Kermit 95
    3.3. Kerberos in C-Kermit
    3.4. Secure Remote Password (SRP) in C-Kermit
    4. GLOSSARY
    5. AUTHENTICATION PROTOCOL OVERVIEWS
    5.1 KERBEROS
    5.2 SECURE REMOTE PASSWORD (SRP)
    6. AUTHENTICATION AND ENCRYPTION COMMANDS
    6.1. TELNET-Related Commands
    6.2. The SET AUTHENTICATION Command
    6.3. The AUTHENTICATE Command
    7. EFFECTS OF ENCRYPTION ON FILE TRANSFER PERFORMANCE
    8. MULTI-HOMED HOSTS
    9. OTHER NOTES
   10. KERBEROS VARIABLES
   11. KERBEROS FUNCTIONS
   12. SCRIPTING HINTS
   13. USING OTHER SECURITY METHODS WITH KERMIT

1. INTRODUCTION

  This document describes Kerberos(TM), Secure Remote Password (SRP)(TM)
  protocol 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.

Security is the current hot topic on the Internet, and security methods
abound.  Secure connection methods are supported indirectly by the methods
described in ckermit2.upd, Section 2.7.  This document describes security
methods that are, or can, be built into Kermit 95 and C-Kermit.  Presently
there are two: Kerberos and SRP.

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 newer and more flexible 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 and/or encryption can be negotiated and used.

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.

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 for use as an encryption key, and therefore encrypted
sessions can be established.  United States and Canadian residents may contact
the Kermit Project for encryption modules which can be used to provide secure
communications using one of the following encryption algorithms:

   cast128_cfb64   cast5_40_cfb64   des_cfb64
   cast128_ofb64   cast5_40_ofb64   des_ofb64

2. DISCLAIMERS

Current US law forbids export of Kerberos 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 in our tests, with any exceptions
that are noted below.

The Kermit Project does not and can not claim or warrant the external Kerberos
or SRP 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 protoco, and may on no account be
held liable for any damage resulting from its use.

Functional limitations:

 . Kermit's authentication and encryption options work only on Telnet
   connections.  Although Kerberized Rlogin sessions have been defined 
   they are not implemented in Kermit software at this time.

 . Authentication and encryption are not currently available with
   "set host *" (incoming) connections.

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

3. AVAILABILITY

Kerberos and Secure Remote Password support are available in Kermit 95 and in 
UNIX C-Kermit.
        
3.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.

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.

In addition, if the appropriate encryption patch (obtained from the Kermit
Project) is installed, two-way encryption will also be negotiated and used if
authentication was negotiated.  The encryption patch is available WITH EXPORT
RESTRICTIONS at:

  http://www.kermit-project.org/noexport.html

Notes on the MIT Leash distribution:

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 need to be customized for user settings if you are not
part of MIT.EDU, 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

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

3.2  Secure Remote Password protocol in Kermit 95

Beginning with version 1.1.16, Kermit 95 supports Telnet Authentication via
Secure Remote Password protocol without any additional software.

In addition, if the appropriate encryption DLL (obtained from the Kermit
Project) is installed, two-way encryption will also be negotiated and used if
authentication was negotiated.  Contact us for details.

3.3. Kerberos in C-Kermit

This section is current as of C-Kermit 6.1.193 Beta.02.

C-Kermit Kerberos support is presently is under development for C-Kermit 6.1,
in Beta test at this writing, only for the UNIX version, and is presently
limited to Kerberos 5.

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. Choose a Kerberos 5 installation (either MIT or Cygnus) and retrieve a
    source code kit from appropriate site:

      http://www.cygnus.com/techie/kerbnet/
      http://web.mit.edu/network/kerberos-form.html or
      http://web.mit.edu/kerberos/www/

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

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

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

      -DCK_AUTHENTICATION -DCK_KERBEROS -DCK_ENCRYPTION

    and that points to the appropriate include files, and links with the
    appropriate libraries.  Use the "linux+krb" entry as model.

Note that a special CONNECT-command module is used: ckucns.c, rather than the
normal ckucon.c.

Keep the Kerberos 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.

3.4. Secure Remote Password protocol in C-Kermit

This section is current as of C-Kermit 6.1.193 Beta.02.

C-Kermit SRP support is presently is under development for C-Kermit 6.1,
in Beta test at this writing, only for the UNIX version.

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 source code kit from:

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

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

 3. Build and install SRP on your system according to the instructions
    that come with the SRP distribution.

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

      -DCK_AUTHENTICATION -DCK_SRP -DCK_ENCRYPTION

    and that points to the appropriate include files, and links with the
    appropriate libraries.  Use the linux+srp makefile target as a model.

Note that a special CONNECT-command module is used: ckucns.c, rather than the
normal ckucon.c.

Keep the SRP 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.


4. KERBEROS GLOSSARY

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.

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 TGTs on
  that machine, e.g. for Telnetting from machine A to machine B and then
  from machien B to machine C.

Host
  A computer that can be accessed over a network.

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

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.

Proxyable 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 protocol 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 have to be registered in the Kerberos database at the host's
site.  Contact the site administrator for details.

Before authentication 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
AUTHENTICATE command, explained below.

Once a Ticket Getting Ticket (TGT) is retrieved, Kermit can use it to retrieve
additional tickets for each host (service) which you wish to connect to.
These service tickets may be used to authenticate you with the host auto-
matically during a specified time interval.  When authentication is 
successful, you are logged in to the host and neither a Login: or Password: 
prompt will appear when connecting.

In addition to 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) will attempt to negotiate
bidirectional encryption using either the DES-CFB64 or DES-OFB64 algorithms.
If one of these is negotiated, it will be used in the direction(s)
that were negotiated, depending on what the server agreed to.

When Kerberos V authentication is used, Kermit supports credential forwarding
by transferring your Ticket Getting Tickets to the host that you are
connecting to, so you can make additional authenticated connections from
that host to any others that will accept those tickets.

Successful operation of Kerberos requires that all machines have their dates
and times synchronized.


5.2 SECURE REMOTE PASSWORD (SRP) OVERVIEW

SRP requires no special configuration on the part of the user.  When Kermit
is used to connect to a host that supports SRP the user name will be 
transmitted automatically to the host and then a Password prompt will be
displayed at the Kermit command prompt.  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 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 or DES-OFB64 encryption algorithms.


6. AUTHENTICATION AND ENCRYPTION COMMANDS

In all Kermit commands:

  KERBEROS4 can be abbreviated KRB4 or K4
  KERBEROS5 can be abbreviated KRB5 or K5

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.

The CHECK KERBEROS command tells whether your version of Kermit has been built
to include the Kerberos commands described in this section (even if they don't
do anything).

IF AVAILABLE KERBEROS4 (or KRB4, or K4) tells whether Kerberos 4 is actually
available in your version of Kermit (e.g. if the Kerberos 4 DLLs are installed
on your Windows 95 PC).
 
IF AVAILABLE KERBEROS5 (KRB5, K5) tells whether Kerberos 5 is available in
your version of Kermit.

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

6.1. TELNET-Related Security Commands

SET TELNET 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.  ACCEPTED by default.

SET TELNET AUTHENTICATION TYPE { AUTOMATIC, KERBEROS4, KERBEROS5, SRP, NONE }
  AUTOMATIC allows the host to choose the preferred type of authentication.
  Other values allow a specific authentication method to be specified.
  AUTOMATIC is the default.    The list of options will vary depending
  on the authentication types selected at compilation time.

SET TELNET AUTHENTICATION FORWARDING { ON, OFF }
  Set this to ON to forward Kerberos V Ticket Getting Tickets to the host
  after authentication is complete, so you can make additional authenticated
  connections from there.  OFF by default.

SET TELNET ENCRYPTION { ACCEPTED, REFUSED, REQUESTED, REQUIRED }
  ACCEPT or REFUSE encryption bids, or actively REQUEST encryption in both
  directions.  REQUIRED refuses and closes the connection if encryption is
   not  successfully negotiated in both directions.  ACCEPTED is the default.

SET TELNET ENCRYPTION TYPE { AUTOMATIC, CAST128_CFB64, CAST128_OFB64, 
  CAST5_40_CFB64, CAST5_40_OFB64, DES_CFB64, DES_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.

SHOW TELNET
  Displays current TELNET settings, including authentication and
  encryption.

SET TERMINAL DEBUG ON (Keyboard verb \Kdebug, assigned to Alt-d by default)
  Display all AUTHENTICATION and ENCRYPTION negotiations in full detail.

6.2. The SET AUTHENTICATION Command (Kerberos Only)

The SET AUTHENTICATION command lets you set defaults for the AUTHENTICATE
command, so you don't always have to include all the switches if you give
more than one AUTHENTICATE command in one Kermit 95 session:

SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL <name>
  If no default is set, the current SET LOGIN USERID value is used.  SET LOGIN
  USERID is set to the operating systems current username when Kermit is
  started.
 
SET AUTHENTICATION { KERBEROS4, KERBEROS5 } REALM <name>
  If no default is set, the default realm configured for the Kerberos
  libraries is used.  Abbreviations accepted.

SET AUTHENTICATION KERBEROS5 CREDENTIALS-CACHE <filename>
  If no default is set, the default filename configured for the Kerberos
  libraries is used.

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

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 ckermit2.upd, section 1.5.  
The actions are INITIALIZE, DESTROY, and LIST-CREDENTIALS:

  AUTH {K4,K5} { INITIALIZE [switches], DESTROY, LIST-CREDENTIALS [switches] }

The INITIALIZE command is the most complex, and its format is different for
Kerberos 4 and Kerberos 5.  For Kerberos 4, the format is:

AUTH K4 INITIALIZE [ /INSTANCE:<name> /LIFETIME:<minutes> -
  /PASSWORD:<password> /REALM:<name> <principal> ]

All switches are optional.  Kerberos 4 INITIALIZE switches are as follows:

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

/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 can be easily compromised.

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

<principal>
  may be of the form:
  userid[.instance[.instance]]@[realm]  
  Can be omitted if it is the same as your username or SET LOGIN USERID
  value on the client system.

The format for Kerberos 5 is as follows:

AUTH K5 [ /CACHE:<filename> ] { INITIALIZE ..., DESTROY, LIST-CREDENTIALS ...}

The INITIALIZE command for Kerberos 5 can include a number of switches;
all are optional:

AUTHORIZE K5 [ /CACHE:<filename> INITITIALIZE /FORWARDABLE  /LIFETIME:<minutes>
  /PASSWORD:<password> /POSTDATE:<date-time> /PROXYABLE /REALM:<name> /RENEW
  /RENEWABLE:<minutes> /SERVICE:<name> /VALIDATE <principal> ]

Kerberos 5 INITIALIZE switches are:

/FORWARDABLE
  Requests forwardable tickets.

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

/PASSWORD:<string>
  Allows the inclusion of a password in a script file. 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.

/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 ckermit2.upd section 1.6
  for acceptable date-time formats.

/PROXYABLE
  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]  
  Can be omitted if it is the same as your username or SET LOGIN USERID
  value on the client system.

AUTHORIZE K5 LIST-CREDENTIALS [ /FLAGS /ENCRYPTION ]

Shows start time, expiration time, service or principal name, plus
the following additional information depending the switches:

/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

/ENCRYPTION displays the encryption used by each ticket (if applicable):
  DES-CBC-CRC
  DES-CBC-MD4
  DES-CBC-MD5
  DES3-CBC-SHA

6.4. OTHER SECURITY-RELATED COMMANDS

SET TCP ADDRESS [ <ip-address> ]
  Specify 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 }
  Mutual authentication requires that the host's IP address be resolved to a
  valid host name, and thus TCP REVERSE-DNS-LOOKUP must be SET to ON for
  Kerberos to work.  You can't get a ticket to a host that does not have a
  DNS entry.


7. 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 algorithm
being used.  Encrypted data streams are uncompressible, thus reducing
file-transfer throughput on PPP or SLIP modem connections.

8. MULTI-HOMED HOSTS

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.  The problem is that 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 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 will produce the following error: "Can't decode
authenticator (krb_rd_req)".


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

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 will 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 will appear to succeed but telnetd will close the
connection after TELNET negotiations are complete.  There are several
solutions to this problem:

 . Make sure the Windows login name is case identical to the Unix login name.

 . Use the SET LOGIN USERID <name> command to set the proper login name
   before connecting to the telnet server.

 . Specify the remote username in the <principal> of your AUTHENTICATE Kxxx
   INITIALIZE command.

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.


10. KERBEROS VARIABLES

\v(krb5cc)    - Current kerberos V credentials cache.
\v(krb5princ) - Current kerberos V principal name.
\v(krb5realm) - Current kerberos V realm name.

\v(krb4princ) - Current kerberos IV principal name.
\v(krb4realm) - Current kerberos IV realm name.


11. KERBEROS 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:

    (i)    it exists in the current cache file;
    (ii)   it is not expired;
    (iii)  it is not marked invalid (K5 only);
    (iv)   it was issued from the current IP address

  This value can be used in an IF or XIF 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.

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


12. SCRIPTING HINTS

Kermit does not automatically perform the function of KINIT but this 
automation can be scripted; for example:

  SET TELNET AUTHENTICATION REQUIRED
  SET HOST <host>:<port>
  INPUT 5 \v(prompt)
  XIF FAILURE {
      AUTHENTICATE K4 INIT ; (or K5)
      SET HOST <host>:<port>
      XIF FAILURE { do whatever on failure }
  }

or place the following in your K95CUSTOM.INI file to insure a valid 
Ticket Getting Ticket each time you start K95:

  XIF AVAILABLE KERBEROS4 {
    XIF NOT \Fkrbisvalid(4,krbtgt.\v(krb4realm)@\v(krb4realm)) {
      echo Kerberos 4 Ticket Getting Ticket is invalid!
      AUTH K4 INIT
    }
  }

  XIF AVAILABLE KERBEROS5 {
    XIF NOT \Fkrbisvalid(5,krbtgt/\v(krb5realm)@\v(krb5realm)) {
      echo Kerberos 5 Ticket Getting Ticket is invalid!
      AUTH K5 INIT
    }
  }


13. USING OTHER SECURITY METHODS WITH KERMIT

The Kerberos and SRP protocols when coupled with encryption algorithms
such as DES and CAST provide for a secure connection.  A secure connection 
is:

  . one in which both the client and host are able to authenticate
    the other's identity without the transfer of passwords; and

  . which provides for bidirectional encryption of data transmissions.

There are other protocols that can be used to create secure connections 
that are not currently implemented in Kermit such as Secure Sockets Layer 
(SSL), Secure Shell (SSH). The fact that SSL and/or SSH are not integrated 
into Kermit software does not mean that Kermit cannot be used over those 
systems.  Both SSL and SSH provide 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 6.1 and Kermit 95 1.1.16 via the PIPE command, provided they use
standard i/o for the keyboard and screen (see ckermit2.upd 2.7 for details.)

For SSL you can use either the SSLeay package on Unix or the Secure Sockets
Relay product from Medcom on Windows 95/NT to connect Kermit Telnet sessions
to SSL Telnetd.

NEC distributes an SSL Winsock shim at:

  ftp://ftp.nec.co.jp/pub/packages/sotools/

For SSH you can try the SSH distribution from Data Fellows.

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 at the NEC site listed above.

(End)
