home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / k95 / security.txt < prev    next >
Text File  |  2020-01-01  |  135KB  |  3,512 lines
  1.             SECURITY FEATURES FOR AUTHENTICATION AND ENCRYPTION
  2.                            OF TCP/IP CONNECTIONS
  3.  
  4.                     In C-Kermit 7.0 and Kermit 95 1.1.20
  5.  
  6.                                Jeffrey Altman
  7.                              The Kermit Project
  8.                             Columbia University
  9.                       http://www.columbia.edu/kermit/
  10.  
  11.                                31 March 2000
  12.  
  13. This document describes Kerberos(TM), Secure Remote Password (SRP)(TM)
  14. protocol, Secure Sockets Layer (SSL)/Transport Layer Security (TLS), and
  15. other security implementations in, or to be used with, current or
  16. forthcoming releases of Kermit software. NOTE: The terms "Windows 95" and
  17. "Windows 9x" in this document refer to both Windows 95 and Windows 98; the
  18. term "Windows NT" refers to Windows NT 3.51 and later and to Windows 2000.
  19.  
  20.   ------------------------------------------------------------------------
  21.  
  22. CONTENTS
  23.  
  24.     1. INTRODUCTION
  25.     2. DISCLAIMERS
  26.     3. AVAILABILITY
  27.     3.1. Authentication and Encryption in Kermit 95
  28.     3.1.1. Kerberos in Kermit 95
  29.     3.1.2. Secure Remote Password (SRP) in Kermit 95
  30.     3.1.3. NTLM in Kermit 95
  31.     3.1.4. OpenSSL support for SSLv3 and TLSv1 in Kermit 95
  32.     3.2. Authentication and Encryption in C-Kermit
  33.     3.2.1. Kerberos in C-Kermit
  34.     3.2.2. Secure Remote Password (SRP) in C-Kermit
  35.     3.2.3. OpenSSL support for SSLv3 and TLSv1 in C-Kermit
  36.     3.2.4. Shadow Passwords in C-Kermit
  37.     3.2.5. Pluggable Authentication Modules (PAM) in C-Kermit
  38.     4. KERBEROS GLOSSARY
  39.     5. AUTHENTICATION PROTOCOL OVERVIEWS
  40.     5.1. Kerberos
  41.     5.2. Secure Remote Password (SRP)
  42.     5.3. NT LAN Manager (NTLM)
  43.     5.4. SSLv3 and TLSv1
  44.     6. AUTHENTICATION AND ENCRYPTION COMMANDS
  45.     6.1. Security Commands Related to Establishing Connections
  46.     6.1.1. Security Commands Related to Telnet Connections
  47.     6.2. The SET AUTHENTICATION Command
  48.     6.2.1. Kerberos settings
  49.     6.2.2. SRP settings
  50.     6.2.3. SSL and TLS settings
  51.     6.3. The AUTHENTICATE Command
  52.     7. MAKING A SECURE CONNECTION
  53.     7.1. Using TELNET protocol
  54.     7.2. Using RLOGIN protocol
  55.     7.3. Using Only SSL or TLS
  56.     7.4. Using Kerberos 5 User to User protocol
  57.     8. EFFECTS OF ENCRYPTION ON FILE TRANSFER PERFORMANCE
  58.     9. MULTI-HOMED HOSTS AND NETWORK ADDRESS TRANSLATORS
  59.     10. OTHER NOTES
  60.    11. VARIABLES
  61.    11.1. General Authentication Variables
  62.    11.2. Kerberos Variables
  63.    11.3. SSL/TLS Variables
  64.    12. FUNCTIONS
  65.    13. SCRIPTING HINTS
  66.    13.1. Kerberos Autoget
  67.    13.2. Autodestruction of Kerberos credentials
  68.    13.3. Automated Prompting for Usernames
  69.    13.4. Password Inclusion in Script Files
  70.    13.5. Using Kermit Scripts to Produce Secure Telnet Services
  71.    14. USING OTHER SECURITY METHODS WITH KERMIT
  72.    14.1. Implementing other security methods for Kermit 95
  73.    15. AN INTRODUCTION TO CERTIFICATES AND CERTIFICATE AUTHORITIES WITH OPENSSL
  74.    15.1. What Are Certificates, Private Keys, CSRs, CAs, and CRLs?
  75.    15.2. RSA Certificates v. DSA Certificates
  76.    15.3. Should You Be Your own Certificate Authority?
  77.    15.4. Generating a DSA CA (self-signed) certificate
  78.    15.5. Generating a DSA CSR
  79.    15.6. Generating a RSA CA (self-signed) certificate
  80.    15.7. Generating a RSA CSR
  81.    15.8. Signing a CSR with your CA certificate
  82.    15.9. Revoking a Certificate
  83.    15.10. Generating a CRL
  84.    15.11. Mapping a Client Certificate to a User ID
  85.    15.11.1. Mapping a Client Certificate to a User ID in Kermit 95
  86.    15.11.2. Mapping a Client Certificate to a User ID in C-Kermit
  87.    16.   The Kermit Secure FTP client for Microsoft Operating Systems
  88.  
  89. 1. INTRODUCTION
  90.  
  91. Security is the hot topic on the Internet, and security methods abound.
  92. Secure connection methods are supported indirectly by the methods listed in
  93. Section 2.7.4 of Supplement to Using C-Kermit, Second Edition. This
  94. document describes the authentication methods that can be built into Kermit
  95. 95 and C-Kermit. Presently these are:
  96.  
  97.    * Kerberos IV and V
  98.    * Secure Remote Password (SRP)
  99.    * Secure Sockets Layer(SSL)/Transport Layer Security(TLS)
  100.    * Microsoft NT LAN Manager (NTLM).
  101.  
  102. A secure connection is one that provides:
  103.  
  104.    * Authentication of the user to the host/service without the
  105.      transmission of the user's password;
  106.    * Authentication of the host to the user; and:
  107.    * A shared secret that can be used with an encryption algorithm to
  108.      ensure the data transmitted over the connection is understood by only
  109.      the client and host.
  110.  
  111. C-Kermit and Kermit 95 are capable of creating and accepting secure
  112. connections via a variety of methods:
  113.  
  114.    * Incoming and outgoing secure connections may be established between a
  115.      client and a server using Telnet protocol coupled with Kerberos(TM),
  116.      Secure Remote Password (SRP)(TM), Secure Sockets Layer (SSL)/Transport
  117.      Layer Security (TLS), and Microsoft NTLM.
  118.    * Outgoing secure connections may be established using Rlogin protocol
  119.      coupled with Kerberos (TM).
  120.    * Incoming and outgoing secure connections may be established using
  121.      Secure Sockets Layer (SSL)/Transport Layer Security (TLS) alone.
  122.    * Incoming and outgoing secure connections may be established between
  123.      two users with the Kerberos 5 User to User protocol. [Kermit 95 only]
  124.  
  125. 1.1. Kerberos
  126.  
  127. Kerberos(TM) is a method, developed at Massachusetts Institute of
  128. Technology, by which two parties communicating over a TCP/IP connection can
  129. authenticate each other through a trusted third party without sending
  130. passwords or encryption keys in clear text over the network. Kerberos
  131. protocols are defined in Internet RFCs 1510, 1964, and others. You can read
  132. more about Kerberos at:
  133.  
  134.    * http://web.mit.edu/kerberos/www/
  135.    * http://nii.isi.edu/info/kerberos/
  136.    * http://nii.isi.edu/publications/kerberos-neuman-tso.html
  137.  
  138. There are, in fact, two Kerberos protocols: Kerberos IV (4) and Kerberos V
  139. (5), the latter being the more flexible and secure protocol. The two are
  140. totally separate and incompatible. Any given site might support neither,
  141. either one, or both.
  142.  
  143. When both the client and server support the same version of Kerberos (4 or
  144. 5), then Kerberos authentication with or without encryption can be
  145. negotiated.
  146.  
  147. A "Kerberized" version of Kermit can make a connection to a non-Kerberized
  148. host, and a non-Kerberized host can accept a connection from a Kerberized
  149. version of Kermit, as long as neither side is configured to require
  150. Kerberos authentication.
  151.  
  152. 1.2. SRP
  153.  
  154. Secure Remote Password (SRP)(TM) protocol is a method, developed at
  155. Stanford University, by which two parties communicating over a TCP/IP
  156. connection can authenticate each other in a secure manner through a Zero
  157. Knowledge Identification system. SRP protocols have not yet been accepted
  158. as RFCs. You can read more about SRP at:
  159.  
  160.   http://srp.stanford.edu/srp/
  161.  
  162. Once authentication has been achieved with either Kerberos or SRP, a shared
  163. secret is available which can be used to establish an encrypted session.
  164.  
  165. 1.3. NTLM
  166.  
  167. NT Lan Manager (NTLM) authentication is implemented in Kermit 95 only. Its
  168. only use is to authenticate Kermit 95 to Microsoft's NT Services for Unix
  169. Telnet server. NTLM does not negotiate a shared secret and therefore cannot
  170. be used to establish encrypted sessions. Therefore, connections made with
  171. NTLM should not be considered secure.
  172.  
  173. 1.4. Encryption
  174.  
  175. Export of encryption software or algorithms is regulated by United States
  176. law (see Section 2). United States and Canadian residents may contact the
  177. Kermit Project for encryption modules that can be used to provide secure
  178. communications using one of the following encryption algorithms via the
  179. Telnet Encryption Option:
  180.  
  181.   cast128_cfb64   cast5_40_cfb64   des_cfb64   des3_cfb64
  182.   cast128_ofb64   cast5_40_ofb64   des_ofb64   des3_ofb64
  183.  
  184. Netscape's Secure Sockets Layer (SSL) and its IETF-approved successor,
  185. Transport Layer Security (TLS), provide for authentication and encryption
  186. of TCP/IP communications using a combination of public key and symmetric
  187. cryptographic algorithms. Authentication of the server (and optionally the
  188. client) is performed by exchanging ITU-T X.509 certificate chains (see
  189. Section 14), which are then verified by the receiver. Unlike raw public
  190. keys, X.509 certificates may be revoked by issuing a certificate revocation
  191. list (CRL) which is to be checked by the receiver during verification of
  192. the certificate chain.
  193.  
  194. The encryption provided by SSL/TLS is more secure than the encryption
  195. negotiatied by the Telnet Encryption Option. This additional security is
  196. provided by a combination of the use of longer encryption keys; the
  197. availability of stronger symmetric cryptographic algorithms; and the
  198. signing of each transmitted block with a message digest algorithm.
  199.  
  200. TLS may be used in conjunction wth Telnet Authentication methods such as
  201. Kerberos, Secure Remote Password, and NTLM to provide the highest level of
  202. data privacy with the strongest forms of mutual authentication.
  203.  
  204. The Kermit modules used to implement SSL/TLS are available only to
  205. residents of the United States and Canada due to the restrictions on the
  206. export of software that provides "crypto with a hole" functionality.
  207.  
  208.   ------------------------------------------------------------------------
  209.  
  210. 2. DISCLAIMERS
  211.  
  212.      The statements made with regard to US export law reflect the
  213.      situation in December 1999, which might have changed since then.
  214.      We will update this document, and our website in general, in
  215.      light of any new developments.
  216.  
  217. Current US law forbids export of strong encryption software from the USA to
  218. all countries except Canada. Thus security modules are not included with
  219. Kermit; they must be obtained separately from the sources listed below, in
  220. compliance with the terms and conditions given at those sites and with
  221. United States and international law. For an overview of this issue, see
  222. (for example):
  223.  
  224.   http://www.mozilla.org/crypto-faq.html
  225.  
  226. Kermit software, when combined with the security modules listed in this
  227. document, has been verified to negotiate and conduct authenticated and
  228. encrypted sessions with Kerberos and/or SRP services on Internet hosts at
  229. Columbia University and other test sites, with Kermit features such as
  230. interactive terminal access, file transfer, and scripting operating
  231. successfully over Kerberized connections, with any exceptions noted below.
  232.  
  233. The Kermit Project does not and can not claim or warrant the external
  234. Kerberos, SRP, OpenSSL or other third-party modules to be free of loopholes
  235. or bugs. Authentication via Kerberos and/or SRP is not unbreakable. Any
  236. encryption method can be broken. Any software that is used for
  237. authentication or encryption should be analyzed for weaknesses, backdoors,
  238. bugs, and loopholes by the site and/or end user before use.
  239.  
  240. The Kermit Project and Columbia University make no claim or warranty as to
  241. any particular level of security achievable by Kermit software in
  242. conjunction with either Kerberos or Secure Remote Password protocol, and
  243. may on no account be held liable for any damage resulting from its use (a
  244. more complete statement to this effect is found in the C-Kermit 7.0
  245. license).
  246.  
  247. Functional limitations:
  248.  
  249.    * Kerberos authentication is available only on Telnet and Rlogin
  250.      connections.
  251.    * Secure Remote Password authentication is available only on Telnet
  252.      connections.
  253.    * NTLM authentication is available only on Windows 95/98/NT/2000 and
  254.      only on Telnet connections.
  255.    * SSL/TLS may be used as its own connection protocol or on Telnet
  256.      connections.
  257.    * Kerberos support is not available in Kermit 95 for OS/2 due to lack of
  258.      Kerberos implementations for OS/2.
  259.  
  260.   ------------------------------------------------------------------------
  261.  
  262. 3. AVAILABILITY
  263.  
  264. 3.1. Authentication and Encryption in Kermit 95
  265.  
  266. Kermit 95 comes precompiled with support for Kerberos 4, Kerberos 5, Secure
  267. Remote Password, NT Lan Manager authentication, and OpenSSL's SSLv3 and
  268. TLSv1.
  269.  
  270. 3.1.1. Kerberos in Kermit 95
  271.  
  272. Beginning with version 1.1.16, Kermit 95 supports Kerberos Telnet
  273. Authentication when any of the following Kerberos IV or Kerberos V
  274. implementations are installed on a Windows 95 or Windows NT workstation:
  275.  
  276.      MIT Kerberos for Microsoft Operating Systems Release 2.0
  277.         * Supports Kerberos 4 and Kerberos 5:
  278.           http://web.mit.edu/kerberos/www/
  279.  
  280.      Naval Research Laboratories
  281.         * Supports Kerberos 5:
  282.           ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/README
  283.  
  284.      Cygnus Solutions' KerbNet 1.2
  285.         * Supports Kerberos 5: No longer under active development
  286.           http://www.cygnus.com/techie/kerbnet/
  287.  
  288. When Kerberos IV and/or Kerberos V are installed and the DLLs are located
  289. in the PATH, Kermit 95 attempts to negotiate authentication with the host's
  290. Telnet server if the host is Kerberized and if you have not instructed
  291. Kermit 95 to the contrary.
  292.  
  293. In addition, if the appropriate encryption patch (obtained from the Kermit
  294. Project) is installed, two-way encryption is also negotiated and used if
  295. authentication was negotiated. The encryption patch is available WITH
  296. EXPORT RESTRICTIONS at:
  297.  
  298.   http://www.kermit-project.org/noexport.html
  299.  
  300. Due to the length of the shared secret negotiated by Kerberos only 56-bit
  301. DES encryption can be used.
  302.  
  303. Per-PC configuration files may or may not be necessary at your
  304. installation. If your site's DNS servers supply Kerberos realm information,
  305. no configuration files are needed and you can skip ahead to Section 3.1.2.
  306.  
  307. 3.1.1.1. Notes on the Kerberos IV configuration files
  308.  
  309. Kerberos IV uses three configuration files which are placed into the
  310. \WINDOWS directory: LEASH.INI (user settings), KRB.CON and KRBREALM.CON.
  311. KRB.CON and KRBREALM.CON are used by Kerberos IV to map your host's domain
  312. name to a realm and then to determine the name of the Kerberos server for
  313. that realm. As distributed from MIT, these files are set up for MIT's
  314. realm, domain, and host information, so if you are not at MIT you'll need
  315. to substitute the information for your own site; for example:
  316.  
  317. KRB.CON:
  318.   CC.COLUMBIA.EDU
  319.   CC.COLUMBIA.EDU kerberos.cc.columbia.edu
  320.   KERMIT.COLUMBIA.EDU kerberos.cc.columbia.edu
  321.   COLUMBIA.EDU kerberos.cc.columbia.edu
  322.   .KERBEROS.OPTION. dns
  323.  
  324. The first line is the default Kerberos IV realm to be used. The subsequent
  325. lines list realms and the hostnames to be used to contact the KDC for that
  326. realm.
  327.  
  328. KRBREALM.CON:
  329.   .CC.COLUMBIA.EDU CC.COLUMBIA.EDU
  330.   CC.COLUMBIA.EDU CC.COLUMBIA.EDU
  331.   .COLUMBIA.EDU CC.COLUMBIA.EDU
  332.   COLUMBIA.EDU CC.COLUMBIA.EDU
  333.   .KERMIT.COLUMBIA.EDU CC.COLUMBIA.EDU
  334.   KERMIT.COLUMBIA.EDU CC.COLUMBIA.EDU
  335.  
  336. Each line specifies either a domain name prefaced with a "." or a host name
  337. and the Kerberos IV realm to which it belongs.
  338.  
  339. The Leash Kerberos IV implementation does not contain support for server
  340. side functionality. Therefore, K95 cannot authenticate incoming connections
  341. with Kerberos IV. It also does not include support for pre-authenticated
  342. ticket granting ticket requests.
  343.  
  344. 3.1.1.2. Notes on the Kerberos V configuration file
  345.  
  346. Kerberos V uses a single configuration file, KRB5.CONF (KRB5.INI on
  347. Windows). This file must be customized for the domains, realms, and hosts
  348. used in your network environment. For example:
  349.  
  350. [libdefaults]
  351.         default_realm = CC.COLUMBIA.EDU
  352.         default_tkt_enctypes = des-cbc-crc
  353.         default_tgs_enctypes = des-cbc-crc
  354.         ticket_lifetime = 600
  355.         dns_fallback = true
  356.  
  357. [domain_realm]
  358.         .cc.columbia.edu = CC.COLUMBIA.EDU
  359.         cc.columbia.edu = CC.COLUMBIA.EDU
  360.         .columbia.edu = CC.COLUMBIA.EDU
  361.         columbia.edu = CC.COLUMBIA.EDU
  362.  
  363. [realms]
  364.         CC.COLUMBIA.EDU = {
  365.                 kdc = kerberos.columbia.edu:88
  366.                 admin_server = kerberos.columbia.edu:749
  367.                 default_domain = cc.columbia.edu
  368.                 supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4
  369.                 supported_keytypes = des:normal des-cbc-crc:v4
  370.         }
  371.  
  372. 3.1.2. Secure Remote Password protocol in Kermit 95
  373.  
  374. Beginning with version 1.1.16, Kermit 95 supports Telnet Authentication via
  375. Secure Remote Password protocol without any additional software.
  376.  
  377. In addition, if the appropriate encryption patch (obtained from the Kermit
  378. Project) is installed, two-way encryption is also negotiated and used if
  379. authentication was negotiated. The encryption patch is available WITH
  380. EXPORT RESTRICTIONS at:
  381.  
  382.   http://www.kermit-project.org/noexport.html
  383.  
  384. Kermit 95 contains support for authenticating incoming connections using
  385. SRP. Unfortunately, there are no Windows based tools for creating the SRP
  386. password file. However, once a password and config file are created on Unix
  387. they can be copied to Windows. Use the SRP_ETC or ETC environment variables
  388. to specify where the tpasswd and tpasswd.conf files are stored.
  389.  
  390. 3.1.3. NT LAN Manager Authentication in Kermit 95
  391.  
  392. NTLM authentication is a feature of Windows 95/98, NT, and Windows 2000. It
  393. is used to authenticate Windows clients to Windows services. Telnet Auth
  394. NTLM is implemented in the Microsoft Telnet Daemon that ships with NT
  395. Services for Unix and with Windows 2000.
  396.  
  397. Windows 95/98 only contains support for the client whereas NT contains
  398. support for both client and server. Kermit 95 can authenticate incoming
  399. connections with NTLM when it is executing on NT.
  400.  
  401. 3.1.4. OpenSSL support for SSLv3 and TLSv1 in Kermit 95
  402.  
  403. OpenSSL security is available in Kermit 95 1.1.18 and later. OpenSSL
  404. sources may be retrieved from the web site:
  405.  
  406.   http://www.openssl.org/
  407.  
  408. As of this writing the current release of OpenSSL is 0.9.5a and 0.9.6 is
  409. under development. Kermit 95 works with the binaries produced by compiling
  410. versions 0.9.4 or higher. Patches for OpenSSL 0.9.4 to allow compilation
  411. under OS/2 are located at:
  412.  
  413.   http://www.geocities.com/SiliconValley/Hills/8057/files/openssl.html
  414.  
  415. On Windows, OpenSSL must be compiled and linked to use the NT DLL option
  416. without Debug information. Compiling the DLLs with support for debugging
  417. links the DLLs to an incompatible C Run Time Library DLL.
  418.  
  419. On OS/2, OpenSSL must be compiled to use the DLL version of the run time
  420. library.
  421.  
  422. For proper operation of OpenSSL and Kermit 95, the OpenSSL DLLs must be
  423. available in the PATH. In addition, the OPENSSL_CONF environment variable
  424. should also be defined appropriately.
  425.  
  426. OpenSSL does not define default locations for certificates and revocation
  427. lists therefore the appropriate SET AUTH { SSL, TLS } commands must be
  428. specified in the K95CUSTOM.INI (or IKSD.KSC) file in order for certificate
  429. verification to be performed.
  430.  
  431. Due to patent licensing restrictions on RSA and IDEA algorithms within the
  432. United States, any binaries that the Kermit Project might distribute to
  433. provide SSL/TLS support for Kermit 95 do not contain RSA key exchange; RSA
  434. authentication; or RC2, RC4, and IDEA ciphers.
  435.  
  436. If you wish to provide support for authentication of clients using public
  437. key certificates you must provide a custom X509_to_user() function to
  438. accomplish the certificate to local userid mapping. An example function
  439. that uses the /UID field of the Certificate Subject name follows:
  440.  
  441.   int
  442.   X509_to_user(X509 *peer_cert, char *userid, int len) {
  443.       int err;
  444.  
  445.       if (!(peer_cert && userid) || len <= 0)
  446.           return -1;
  447.  
  448.       /* Userid is in cert subject /UID */
  449.       err = X509_NAME_get_text_by_NID(X509_get_subject_name(peer_cert),
  450.                                        NID_uniqueIdentifier, userid, len);
  451.       if (err > 0)
  452.           return 0;
  453.       return -1;
  454.   }
  455.  
  456. This function must be compiled into a DLL called "X5092UID.DLL". It should
  457. be linked to the OpenSSL libraries and the DLL version of the run time
  458. library.
  459.  
  460. 3.2. Authentication and Encryption in C-Kermit 7.0
  461.  
  462. C-Kermit 7.0 may be compiled with support Kerberos 4, Kerberos 5, Secure
  463. Remote Password, and OpenSSL's SSLv3 and TLSv1.
  464.  
  465. 3.2.1. Kerberos in C-Kermit 7.0
  466.  
  467. Kerberos IV and Kerberos V support is available for Unix versions of
  468. C-Kermit 7.0. Kerberos support in C-Kermit is provided for both outgoing
  469. and incoming connections (SET HOST /SERVER * port /TELNET or the Internet
  470. Kermit Service).
  471.  
  472. Kerberized C-Kermit binaries are not available due to export restrictions
  473. (see Section 2); you must build your own binary from a combination of
  474. Columbia source code and Kerberos libraries from other sources.
  475.  
  476.   1. Retrieve a Kerberos 5 1.1 source code kit from the appropriate site:
  477.  
  478.        http://web.mit.edu/kerberos/www/ or:
  479.        http://web.mit.edu/network/kerberos-form.html
  480.  
  481.   2. Choose a Kerberos 4 installation (from MIT) and retrieve a source code
  482.      kit from the appropriate site:
  483.  
  484.        http://web.mit.edu/kerberos/www/ or:
  485.        http://web.mit.edu/network/kerberos-form.html
  486.  
  487.   3. Obtain the C-Kermit Authentication and Encryption support modules from
  488.      Columbia University. These are not available by FTP due to export
  489.      restrictions. Contact kermit-support@columbia.edu for details.
  490.  
  491.   4. Build and install Kerberos on your system according to the
  492.      instructions that come with the Kerberos distribution you have chosen.
  493.  
  494.   5. Add a new entry to the C-Kermit makefile for your platform, that adds
  495.      the following CFLAGS:
  496.  
  497.        -DCK_AUTHENTICATION -DCK_KERBEROS
  498.  
  499.      For Kerberos 4 include:
  500.  
  501.        -DKRB4
  502.  
  503.      For Kerberos 5 include:
  504.  
  505.        -DKRB5
  506.  
  507.      For Kerberos 4 compatibility mode with Kerberos 5:
  508.  
  509.        -DKRB5 -DKRB524 -DKRB4
  510.  
  511.      If you have the source file ck_crp.c and desire DES encryption
  512.      include:
  513.  
  514.        -DCK_ENCRYPTION -DCK_DES
  515.  
  516.      Use "krbmit" as the target for builds with ck_crp.c and
  517.      "krbmit-export" for builds without ck_crp.c.
  518.  
  519.      Add the path to the Kerberos header files using the -I switch. The
  520.      location of these files are host specific. For example:
  521.  
  522.        -I/usr/kerberos/include
  523.  
  524.      Add the path to the Kerberos libraries using the -L switch. The
  525.      location of these files are host specific. For example:
  526.  
  527.        -L/usr/kerberos/lib
  528.  
  529.      Add the appropriate libraries. For Kerberos 4 include:
  530.  
  531.        -lkrb
  532.  
  533.      For Kerberos 5 include:
  534.  
  535.        -lkrb5 -lcom_err -lcrypto
  536.  
  537.      For Kerberos 4 compatibility mode with Kerberos 5 include:
  538.  
  539.         -ldes425 -lkrb5 -lcom_err -lcrypto
  540.  
  541.      Make sure the new entry points to the appropriate include files, and
  542.      links with the appropriate libraries. Use the "linux+krb5",
  543.      "linux+krb5+krb4", and "sunos41gcc+krb4" makefile entries as models.
  544.  
  545. Note that the select() version of the CONNECT-command module (ckucns.c)
  546. must be used rather than the older fork() based (ckucon.c) version.
  547.  
  548. Keep the Kerberos support modules private, and put the C-Kermit binary
  549. where it can be used, but not where it can be accessed by anonymous ftp or
  550. by anyone who is outside the USA or Canada.
  551.  
  552. When C-Kermit 7.0 is built with Kerberos support and installed as an
  553. Internet Kermit Service Daemon (IKSD), Kerberos is offered for
  554. authenticating incoming connections if there is a valid keytab file
  555. providing local access to the key necessary for decrypting meesages encoded
  556. in the server's key.
  557.  
  558. 3.2.2. Secure Remote Password protocol in C-Kermit
  559.  
  560. Secure Remote Password (SRP) support is available for Unix versions of
  561. C-Kermit 7.0. SRP support in C-Kermit is provided for both outgoing and
  562. incoming connections (SET HOST /SERVER * port /TELNET or the Internet
  563. Kermit Service).
  564.  
  565. SRP C-Kermit binaries are not available due to export restrictions (see
  566. Section 2); you must build your own binary from a combination of Columbia
  567. source code and SRP libraries from other sources.
  568.  
  569.   1. Retrieve the SRP 1.5.0 source code kit from:
  570.  
  571.        http://srp.stanford.edu/srp/
  572.  
  573.   2. Obtain the C-Kermit Authentication and Encryption support modules from
  574.      Columbia University. These are not available by FTP due to export
  575.      restrictions. Contact kermit-support@columbia.edu for details.
  576.  
  577.   3. Build SRP with the GMP math library. Be sure to read the installation
  578.      instructions before installing because SRP replaces many standard Unix
  579.      system files and failure to follow the procedures may leave you locked
  580.      out of your system.
  581.  
  582.   4. Add a new entry to the C-Kermit makefile for your platform, that adds
  583.      the following CFLAGS:
  584.  
  585.        -DCK_AUTHENTICATION -DCK_SRP
  586.  
  587.      If you have the source file ck_crp.c include:
  588.  
  589.        -DCK_ENCRYPTION
  590.  
  591.      For CAST encryption (requires ck_crp.c) add:
  592.  
  593.        -DCK_CAST
  594.  
  595.      If using the Eric A. Young DES encryption library (available
  596.      separately and as a part of the OpenSSL project (requires ck_crp.c)
  597.      add:
  598.  
  599.        -DCK_DES -DLIBDES
  600.  
  601.      Use "srpmit" as the target for builds with ck_crp.c and
  602.      "srpmit-export" for builds without ck_crp.c.
  603.  
  604.      Add the path to the SRP header files using the -I switch. The location
  605.      of these files are host specific. For example:
  606.  
  607.        -I/usr/srp/include
  608.  
  609.      Add the path to the SRP libraries using the -L switch. The location of
  610.      these files are host specific. For example:
  611.  
  612.        -L/usr/srp/lib
  613.  
  614.      Add the appropriate libraries. (Include des only if you have the Eric
  615.      A. Young library):
  616.  
  617.        -lsrp -lgmp -ldes
  618.  
  619.      Make sure the new entry points to the appropriate include files, and
  620.      links with the appropriate libraries. Use the "linux+srp" and
  621.      "linux+krb5+krb4+srp" makefile entries as models.
  622.  
  623. Note that the select() version of the CONNECT-command module (ckucns.c)
  624. must be used rather than the older fork() based (ckucon.c) version.
  625.  
  626. Keep the SRP support modules private, and put the C-Kermit binary where it
  627. can be used, but not where it can be accessed by anonymous ftp or by anyone
  628. who is outside the USA or Canada.
  629.  
  630. When C-Kermit 7.0 is built with Kerberos support and installed as an
  631. Internet Kermit Service Daemon (IKSD), SRP is offered for authenticating
  632. incoming connections.
  633.  
  634. 3.2.3. OpenSSL support for SSLv3 and TLSv1 in C-Kermit 7.0.
  635.  
  636. OpenSSL support is available for Unix versions of C-Kermit 7.0. SSLv3 and
  637. TLSv1 support in C-Kermit is provided for both outgoing and incoming
  638. connections (SET HOST /SERVER * port /TELNET or the Internet Kermit
  639. Service).
  640.  
  641. OpenSSL C-Kermit binaries are not available due to export restrictions (see
  642. Section 2); you must build your own binary from a combination of Columbia
  643. source code and the OpenSSL libraries from other sources.
  644.  
  645.   1. Retrieve the OpenSSL 0.9.4 source code kit from:
  646.  
  647.        http://www.openssl.org/
  648.  
  649.   2. Obtain the C-Kermit Authentication and Encryption support modules from
  650.      Columbia University. These are not available by FTP due to export
  651.      restrictions. Contact kermit-support@columbia.edu for details.
  652.  
  653.   3. Build OpenSSL according to the installation instructions. Be aware
  654.      that OpenSSL includes support for algorithms which are covered by
  655.      patents or claimed as intellectual property in the United States (and
  656.      perhaps some other countries.) Use of these algorithms without the
  657.      proper licenses can make you liable to legal action. Be sure to read
  658.      the entire README file before building and installing OpenSSL.
  659.  
  660.      If you wish to support ADH ciphers you must define SSL_ALLOW_ADH when
  661.      building OpenSSL.
  662.  
  663.   4. Add a new entry to the C-Kermit makefile for your platform, that adds
  664.      the following CFLAGS:
  665.  
  666.        -DCK_AUTHENTICATION -DCK_SSL
  667.  
  668.      Use "krbmit" as the target for builds.
  669.  
  670.      Add the path to the OpenSSL header files using the -I switch. The
  671.      location of these files is host-specific. For example:
  672.  
  673.        -I/usr/local/ssl/include
  674.  
  675.      Add the path to the OpenSSL libraries using the -L switch. The
  676.      location of these files is host-specific. For example:
  677.  
  678.        -L/usr/local/ssl/lib
  679.  
  680.      Add the appropriate libraries:
  681.  
  682.        -lssl -lcrypto
  683.  
  684.      Make sure the new entry points to the appropriate include files, and
  685.      links with the appropriate libraries. Use the "linux+openssl" and
  686.      "linux+krb5+krb4+srp+openssl" makefile entries as models.
  687.  
  688. Note that the select() version of the CONNECT-command module (ckucns.c)
  689. must be used rather than the older fork() based (ckucon.c) version.
  690.  
  691. Keep the OpenSSL support modules private, and put the C-Kermit binary where
  692. it can be used, but not where it can be accessed by anonymous ftp or by
  693. anyone who is outside the USA or Canada.
  694.  
  695. When C-Kermit 7.0 is installed as an Internet Kermit Service (IKSD), TLSv1
  696. is offered for authenticating incoming connections via the Telnet START_TLS
  697. option.
  698.  
  699. If you wish to provide support for authentication of clients using public
  700. key certificates you must provide a custom X509_to_user() function to
  701. provide the certificate to local userid mapping. An example function which
  702. uses the /UID field of the Certificate Subject name may be activated by
  703. specifying:
  704.  
  705.   make entry KFLAGS=-DX509_UID_TO_USER
  706.  
  707. when compiling C-Kermit. The X509_to_user() function is the last function
  708. in the ck_ssl.c module.
  709.  
  710. 3.2.4. Shadow Passwords in C-Kermit 7.0.
  711.  
  712. Shadow password files are used in many versions of Unix to provide a
  713. greater level of security for user passwords stored on the local disk. The
  714. standard Unix password file must be world readable in order to processes to
  715. determine the location of the user's shell, home directory, and other
  716. permissions. By moving the passwords into a separate file that only stores
  717. passwords, access to the file can be restricted to only those processes
  718. that are authorized to perform authentication.
  719.  
  720. When C-Kermit 7.0 is used as the Internet Kermit Service on systems that
  721. are configured to use shadow passwords the following CFLAG must be added to
  722. the makefile entry:
  723.  
  724.   -DCK_SHADOW
  725.  
  726. 3.2.5. Pluggable Authentication Module (PAM) support in C-Kermit 7.0
  727.  
  728. PAM is implemented in many versions of Unix so system administrators can
  729. add new forms of authentication for interactive login (console, telnet,
  730. rlogin, ...) without requiring recompilation of each service.
  731.  
  732. When C-Kermit 7.0 is used as the Internet Kermit Service on systems that
  733. are configured to use PAM the following CFLAG must be added to the makefile
  734. entry:
  735.  
  736.   -DCK_PAM
  737.  
  738. and the following libraries may have to be included:
  739.  
  740.   -lpam -ldl
  741.  
  742. C-Kermit 7.0's support for PAM is limited to Interactive Login. PAM is not
  743. compatible with the Kermit Protocol's REMOTE LOGIN mechanism.
  744.  
  745.   ------------------------------------------------------------------------
  746.  
  747. 4. KERBEROS GLOSSARY
  748.  
  749. Listed alphabetically, not topologically.
  750.  
  751. Entity
  752.      In this document, a user, host, or service.
  753.  
  754. Authentication
  755.      The process by which one entity proves its identity to another entity
  756.      on the Internet.
  757.  
  758. Client
  759.      An entity that can obtain a ticket (see Ticket).
  760.  
  761. Credentials Cache
  762.      The location where Kerberos stores tickets. The credentials cache can
  763.      be a file or a buffer in memory.
  764.  
  765. Expiration
  766.      Invalidation of a ticket after a certain period of time. A ticket's
  767.      lifetime is chosen by the user when obtaining the ticket; the maximum
  768.      allowable lifetime for different kinds of tickets is set by the site
  769.      administrator.
  770.  
  771. Forwardable Tickets
  772.      Kerberos tickets that can be forwarded (copied) to a remote machine,
  773.      where they can be used, eliminating the need to obtain new Ticket
  774.      Granting Tickets (q.v.) on that machine, e.g. for Telnetting from
  775.      machine A to machine B and then from machine B to machine C.
  776.  
  777. Host
  778.      A computer that can be accessed over a network.
  779.  
  780. KDC
  781.      Key Distribution Center, a machine that issues Kerberos tickets.
  782.  
  783. Preauthenticated Ticket Granting Ticket Request
  784.      The client must include a time stamp encrypted with the user's
  785.      password when requesting the TGT from the KDC. This allows the KDC to
  786.      only deliver a TGT to a valid user. When preauthentication is not used
  787.      the TGT may be attacked offline to determine the user's password.
  788.  
  789. Postdated Ticket
  790.      A ticket that does not become valid until after a specified time. This
  791.      allows for secure unattended operations.
  792.  
  793. Principal
  794.      A string that names a specific entity to which a set of credentials
  795.      may be assigned. It generally has three parts, primary/instance@REALM:
  796.        1. Primary: Identifies the user or service.
  797.        2. Instance: Usually a hostname or REALM.
  798.        3. REALM: Logical network served by a single Kerberos database and
  799.           KDC.
  800.  
  801. Proxiable Ticket
  802.      A ticket that may be given to a service to allow the service to
  803.      impersonate the user for whom the ticket has been issued.
  804.  
  805. Ticket
  806.      A temporary set of electronic credentials that verifies the identity
  807.      of its owner to a particular service.
  808.  
  809. TGT
  810.      Ticket Granting Ticket. A special ticket that lets its owner obtain
  811.      additional tickets within the same realm. A TGT is obtained during the
  812.      initial authentication process.
  813.  
  814.   ------------------------------------------------------------------------
  815.  
  816. 5. OVERVIEW OF AUTHENTICATION PROTOCOLS
  817.  
  818. The following sections attempt to provide an overview of how each of the
  819. supported authentication protocols operates.
  820.  
  821. 5.1. Kerberos Overview
  822.  
  823. Before making a Kerberized connection, you have to know which Kerberos
  824. version, 4 or 5, is supported by the host or service you want to connect
  825. to, and you must be registered in the Kerberos database at the host's site.
  826. Contact the site administrator for details.
  827.  
  828. Before authentication to a specific service (such as Telnet) can succeed,
  829. you must login to the site's Kerberos Ticket Granting Server. Depending on
  830. the Kerberos implementation and installation options this may be done
  831. automatically when you log in to your operating system. Otherwise you can
  832. do it with external utilities from MIT or Cygnus (such as Leash, KRB5, or
  833. KerbNet), or with Kermit's built-in functionality, explained below.
  834.  
  835. Once a Ticket Granting Ticket (TGT) is retrieved, Kermit can use it to
  836. retrieve additional tickets for each host (service) you wish to connect to.
  837. These service tickets may be used to authenticate you with the host
  838. automatically during a specified time interval. When authentication is
  839. successful, you are logged in to the host and no Login: or Password: prompt
  840. does appear when connecting.
  841.  
  842. Besides providing credentials for use during authentication, the service
  843. ticket also contains a session key to be used for encrypting the
  844. communications. After the connection is authenticated, Kermit (if the
  845. necessary encryption capabilities are available) attempts to negotiate
  846. bidirectional encryption using either the DES-CFB64 or DES-OFB64
  847. algorithms. If one of these is negotiated, it is used in one or both
  848. directions, depending on what the server agreed to.
  849.  
  850. When Kerberos V authentication is used, Kermit supports credential
  851. forwarding by transferring your Ticket Granting Tickets to the host that
  852. you are connecting to, so you can make additional authenticated connections
  853. from that host to any others that accept those tickets. This provides a
  854. single sign-on capability to the network.
  855.  
  856. Successful operation of Kerberos requires that all machines have their
  857. dates and times synchronized. Be aware that PC clocks can drift, and this
  858. can cause authentication failures.
  859.  
  860. 5.2. Secure Remote Password (SRP) Overview
  861.  
  862. SRP requires no special configuration of the client. When Kermit is used to
  863. connect to a host that supports SRP, the user name is transmitted
  864. automatically to the host and then a Password prompt is displayed in the
  865. Kermit command screen. This indicates that the password will not be sent to
  866. the host over the communication channel. Instead the password is used as
  867. part of a negotiation in which authentication is either mutual or none at
  868. all.
  869.  
  870. The result of a mutual authentication is a shared secret which is used to
  871. generate two different keys for encrypting the incoming and outgoing data.
  872. SRP hosts support CAST-128-CFB64, CAST-128-OFB64, CAST-40-CFB64,
  873. CAST-40-OFB64, DES-CFB64, DES-OFB64, DES3-CFB64, DES3-OFB64 encryption
  874. algorithms.
  875.  
  876. 5.3. NT LAN Manager (NTLM) Overview
  877.  
  878. Microsoft's native authentication method is NTLM. It is implemented in
  879. Windows 9x and NT and requires no configuration on the part of the user.
  880. When K95 is used on either Win9x or NT it can be used as an NTLM Telnet
  881. client to authenticate to Microsoft's NT Services for Unix Telnet Server or
  882. to a K95 configured to accept incoming connections.
  883.  
  884. When K95 is used on NT it can be configured to accept incoming connections
  885. and authenticate NTLM Telnet clients.
  886.  
  887. NTLM is a weak form of authentication. It provides no shared secret and
  888. cannot be used as a means of securing a connection with encryption.
  889.  
  890. 5.4. SSLv3 and TLSv1 Overview
  891.  
  892.      (Also see Section 14 for an introduction to the concept of
  893.      certificates.)
  894.  
  895. Secure Sockets Layer Version 3 (SSLv3) and its successor Transport Layer
  896. Security Version 1 (TLSv1) were originally designed for use by Web
  897. browsers. They provide a framework for using public-key certificates to
  898. negotiate server and (optionally) client authentication and bidirectional
  899. encryption. The encryption provided by SSLv3 and TLSv1 is stronger than
  900. that provided by the Telnet Encryption option.
  901.  
  902. SSLv3 and TLSv1 connections may be negotiated in two different ways. First,
  903. the connection may be SSL/TLS-only, which is used when connecting to HTTPS
  904. services or SSL/TLS tunnels. SSL/TLS may also be negotiatied after the
  905. connection is established via negotiations performed in some other protocol
  906. (such as Telnet.)
  907.  
  908. Kermit supports both kinds of connections:
  909.  
  910.    * Pure SSLv3 connections via SET HOST host port /SSL
  911.    * Pure TLSv1 connections via SET HOST host port /TLS
  912.    * SSLv3 connections negotiated by Tim Hudson's Telnet AUTH SSL option
  913.    * TLSv1 connections negotiated by the IETF TN3270E Working Group's
  914.      TELNET START_TLS option
  915.  
  916. The SSL and TLS negotations provide the client with authentication of the
  917. host computer when the host's X.509 certificate is verified. Authentication
  918. of the client may be performed by the use of an X.509 certificate issued to
  919. the end user, or via one of the supported Telnet Authentication methods.
  920. Even though the data channel is encrypted, the transmission of passwords to
  921. the host should still be avoided to prevent theft by a compromised host.
  922.  
  923. For verification of certificates to be performed, the root certificates of
  924. the certificate authorities (CAs) must be available. If you are not acting
  925. as your own CA you might want to use the file of root certificates at:
  926.  
  927.   http://www.e-softinc.com/cacerts.txt
  928.  
  929. This file is produced by E-Soft, Inc., as part of its monthly survey on
  930. secure server usage. After downloading, this file can be used by Kermit via
  931. the command:
  932.  
  933.   SET AUTH SSL VERIFY-FILE /cacerts.txt
  934.  
  935. When Kermit is used as an IKSD, client certificates can be used for
  936. automatic login. If a certificate-to-userid mapping function is provided,
  937. the IKSD logs the user in automatically if the certificate is verified and
  938. the specified userid exists on the system. Kermit also supports the use of
  939. a ".tlslogin" file that allows a certificate to be used to login
  940. automatically to an account without a certificate-to-userid mapping
  941. function. When Kermit receives a username via the Telnet New-Environment
  942. variable after it has received and verified a client certificate, it looks
  943. in the home directory corresponding to the username for a file called
  944. ".tlslogin". If the file contains the certificate presented by the client,
  945. the client is logged in as the requested user without a password.
  946.  
  947. The method for negotiating Tim Hudson's Telnet AUTH SSL option is open to a
  948. "man-in-the-middle" attack which is capable of disabling the use of SSL
  949. before the negotiation is begun. It should only be used in conjunction
  950. with:
  951.  
  952.   SET TELNET AUTHENTICATION TYPE SSL
  953.   SET TELOPT AUTHENTICATION REQUIRED
  954.  
  955. When using IKSD with START_TLS you should create an /etc/iksd.conf file and
  956. place within it commands pointing to the certificate and key files:
  957.  
  958.   set auth tls rsa-cert-file /usr/local/ssl/certs/telnetd-rsa.pem
  959.   set auth tls rsa-key-file  /usr/local/ssl/certs/telnetd-rsa-key.pem
  960.   set auth tls dsa-cert-file /usr/local/ssl/certs/telnetd-dsa.pem
  961.   set auth tls dsa-key-file  /usr/local/ssl/certs/telnetd-dsa-key.pem
  962.  
  963. as well as the list of ciphers that you are willing to accept:
  964.  
  965.   set auth tls cipher 3DES:DSS
  966.  
  967. Note: A Unix telnetd that supports START_TLS is available from:
  968.  
  969.   ftp://ftp.runestig.com/pub/starttls/inetutils-1.3.2-tls.tar.gz
  970.  
  971. This telnetd supports verification of certificate chains for both client
  972. and server including support for certificate revocation lists.
  973.  
  974.   ------------------------------------------------------------------------
  975.  
  976. 6. AUTHENTICATION AND ENCRYPTION COMMANDS
  977.  
  978. Kermit has a full repertoire of commands for selecting and controlling
  979. security. Bear in mind that these are targeted primarily at the network or
  980. site manager and not at the ordinary user. In a typical application, a
  981. university that has a site license for Kermit 95 creates a customized
  982. installation CD for its user community that contains all the appropriate
  983. security (and other) setups, so end users get secure connections without
  984. doing anything special or even knowning that they have them.
  985.  
  986. In all Kermit commands:
  987.  
  988.    * KERBEROS4 can be abbreviated KRB4 or K4
  989.    * KERBEROS5 can be abbreviated KRB5 or K5
  990.  
  991. Some of Kermit's Kerberos-related commands are rather complex, but remember
  992. that you don't have to memorize them, or any other Kermit commands. Use "?"
  993. at any point to feel your way through the command, or type HELP for the
  994. desired command to see a brief explanation. Basic commands:
  995.  
  996. CHECK KERBEROS
  997.      tells whether your version of Kermit has been built to include the
  998.      Kerberos support even if it cannot function on your system.
  999.  
  1000. CHECK NTLM
  1001.      Tells whether your version of Kermit has been built to include the
  1002.      NTLM support even if it cannot function on your system.
  1003.  
  1004. CHECK SRP
  1005.      Tells whether your version of Kermit has been built to include the SRP
  1006.      support even if it cannot function on your system.
  1007.  
  1008. CHECK SSL/TLS
  1009.      Tells whether your version of Kermit has been built to include the
  1010.      SSL/TLS support even if it cannot function on your system.
  1011.  
  1012. IF AVAILABLE ENCRYPTION
  1013.      Tells whether telnet encryption is available in your version of Kermit
  1014.      (e.g. if the K95CRYPT.DLL (or K2CRYPT.DLL) file is installed on your
  1015.      PC).
  1016.  
  1017. IF AVAILABLE KERBEROS4 (or KRB4, or K4)
  1018.      Tells whether Kerberos 4 is available in your version of Kermit (e.g.
  1019.      if the Kerberos 4 DLLs are installed on your PC).
  1020.  
  1021. IF AVAILABLE KERBEROS5 (KRB5, K5)
  1022.      Tells whether Kerberos 5 is available in your version of Kermit.
  1023.  
  1024. IF AVAILABLE NTLM
  1025.      Tells whether NT Lan Manager protocol is available in your version of
  1026.      Kermit.
  1027.  
  1028. IF AVAILABLE SRP
  1029.      Tells whether Secure Remote Password protocol is available in your
  1030.      version of Kermit.
  1031.  
  1032. IF AVAILABLE { SSL, TLS }
  1033.      Tells whether SSL/TLS protocol is available in your version of Kermit.
  1034.  
  1035. 6.1. Security Commands Related to Establishing Connections
  1036.  
  1037. Kermit supports a wide variety of methods for establishing secure TCP/IP
  1038. connections:
  1039.  
  1040. TELNET
  1041.      The Telnet protocol may be used to establish the most secure
  1042.      connections with the greatest flexibility of choice of authentication
  1043.      method and privacy establishment. Kermit's Telnet implementation
  1044.      supports Kerberos 4, Kerberos 5, Secure Remote Password (SRP), NTLM,
  1045.      and X.509 certificates for client and server authentication. Privacy
  1046.      establishment may be performed with the Secure Sockets Layer (SSL) or
  1047.      Transport Layer Security (TLS) cipher suites, or DES, CAST, or 3DES
  1048.      streaming ciphers.
  1049.  
  1050. RLOGIN
  1051.      The Remote Login protocol may be used with either Kerberos 4 or
  1052.      Kerberos 5 to establish authenticated connections. After
  1053.      authentication the DES streaming cipher may be used to provide
  1054.      privacy.
  1055.  
  1056. Secure Socket Layer (SSL) or Transport Layer Security (TLS)
  1057.      The SSL and TLS protocols may be used by themselves to establish a
  1058.      private connection to a remote host. Authentication of the server (and
  1059.      perhaps the client) is performed via an exchange and verification of
  1060.      X.509 certificates. Kermit also provides support for use of Telnet
  1061.      protocol over a secure SSL or TLS tunnel.
  1062.  
  1063. Kerberos 5 User to User
  1064.      The Kerberos 5 user to user protocol may be used to establish an
  1065.      authenticated and private connection between two end user operated
  1066.      copies of Kermit. [Kermit 95 only]
  1067.  
  1068. 6.1.1. Commands Related to Secure Telnet Connections
  1069.  
  1070. The Telnet protocol is one of the most flexible protocols ever used on
  1071. computer networks. Its flexibility provides it with both functionality and
  1072. complexity. Kermit provides commands to manage every aspect of the telnet
  1073. connection. These commands are described in the TELNET Reference. This
  1074. section focuses on commands that are used to manage how secure connections
  1075. are established using Telnet.
  1076.  
  1077. Four Telnet Options can be negotiated between a Telnet client and a Telnet
  1078. server which affect secure connections: AUTH, ENCRYPT, START_TLS, and
  1079. FORWARD_X. When people talk about Telnet not being secure they are
  1080. referring to telnet clients and servers which are not capable of
  1081. negotiating any of these four options.
  1082.  
  1083. When a Telnet session begins it starts in an insecure state. Only after the
  1084. initial negotiations are complete will the session be secure. Security in
  1085. Telnet can be established using many combinations of different Telnet
  1086. Options and authentication and encryption methods.
  1087.  
  1088. The AUTH option negotiates whether authentication will be used for the
  1089. current session, and if so, which type of authentication. The
  1090. authentication type is determined by the server offering an ordered list of
  1091. types and the client choosing the first type that it supports. Most forms
  1092. of authentication generate a shared secret taht can be used with the
  1093. ENCRYPT option the provide privacy on the connection. The how and encrypt
  1094. flags are used to specify an authentication mode and whether encryption is
  1095. required for this connection. The AUTH option may be negotiated in
  1096. conjunction with either the START_TLS or ENCRYPT options, but not both.
  1097.  
  1098. SET TELOPT [ { /CLIENT, /SERVER } ] AUTHENTICATION { ACCEPTED, REFUSED,
  1099. REQUESTED, REQUIRED }
  1100.      ACCEPT or REFUSE authentication bids, or actively REQUEST
  1101.      authentication. REQUIRED refuses and closes the connection if
  1102.      authentication is not successfully negotiated when either making or
  1103.      accepting connections. The default is REQUESTED.
  1104.  
  1105. SET TELNET AUTHENTICATION TYPE { AUTOMATIC, KERBEROS4, KERBEROS5, NTLM,
  1106. SRP, SSL, NONE }
  1107.      AUTOMATIC allows the host to choose the preferred type of
  1108.      authentication. Other values allow a specific authentication method to
  1109.      be specified. AUTOMATIC is the default. The list of options varies
  1110.      depending on the authentication types selected at compilation time.
  1111.      When combined with SET TELOPT AUTH REQUIRED, a specific authentication
  1112.      method can be required.
  1113.  
  1114. SET TELNET AUTHENTICATION HOW-FLAG { ANY, MUTUAL, ONE-WAY }
  1115.      Specifies which values for the HOW-FLAG should be accepted as a client
  1116.      or offered as a server. The default is ANY.
  1117.  
  1118. SET TELNET AUTHENTICATION ENCRYPT-FLAG { ANY, NONE, TELOPT }
  1119.      Specifies which values for the ENCRYPT-FLAG should be accepted as a
  1120.      client or offered as a server. The default is ANY.
  1121.  
  1122. The ENCRYPT option is used to negotiate whether streaming ciphers will be
  1123. used to protect the privacy of the connection, and if so, which encryption
  1124. type to use in each direction. The encryption type is determined by each
  1125. side offering the list of types it can use to receive data. The sender then
  1126. chooses the first type from the provided list that it supports. The ENCRYPT
  1127. option cannot be negotiated without the AUTH option. Whenever both
  1128. START_TLS and ENCRYPT are both available, START_TLS is used since TLS
  1129. provides both privacy and integrity protection to the data stream.
  1130.  
  1131. SET TELOPT [ { /CLIENT, /SERVER } ] ENCRYPTION { ACCEPTED, REFUSED,
  1132. REQUESTED, REQUIRED } { ACCEPTED, REFUSED, REQUESTED, REQUIRED }
  1133.      The first parameter specifies the Kermit-to-peer state. The second
  1134.      parameter specifies the peer-to-Kermit state. The default is ACCEPTED
  1135.      REQUESTED.
  1136.  
  1137. SET TELNET ENCRYPTION TYPE { AUTOMATIC, CAST128_CFB64, CAST128_OFB64,
  1138. CAST5_40_CFB64, CAST5_40_OFB64, DES_CFB64, DES_OFB64, DES3_CFB64,
  1139. DES3_OFB64, NONE }
  1140.      AUTOMATIC allows the host to choose the preferred type of encryption.
  1141.      Other values allow a specific encryption method to be specified.
  1142.      AUTOMATIC is the default. The list of options varies depending on the
  1143.      encryption types selected at compilation time. An encryption method
  1144.      can be used only if there is enough key data available. Kerberos can
  1145.      use only DES encryption because it provides a shared secret only 56
  1146.      bits in length.
  1147.  
  1148. The START_TLS option negotiates whether the current session will be
  1149. protected by Transport Layer Security (TLS), the same protocol used to
  1150. secure all of the HTTP Web sites on the Internet. TLS uses X.509
  1151. certificates to authenticate the server and optionally authenticate the
  1152. client. START_TLS can be used in conjunction with AUTH to allow Kerberos,
  1153. Secure Remote Password, or other authentication methods to be used to
  1154. authenticate the client. START_TLS can not be used in conjunctions with the
  1155. ENCRYPT option. Nor is there any need to since the protection provided by
  1156. TLS is stronger than all of the streaming ciphers supported by the ENCRYPT
  1157. option.
  1158.  
  1159. SET TELOPT [ { /CLIENT, /SERVER } ] START_TLS { ACCEPTED, REFUSED,
  1160. REQUESTED, REQUIRED }
  1161.      ACCEPT or REFUSE a request to negotiate TLS, or actively REQUEST that
  1162.      TLS be negotiated. REQUIRED refuses and closes the connection if the
  1163.      peer refuses to negotiate TLS or the TLS negotiations end in failure.
  1164.      ACCEPTED by default when a client. REQUESTED by default when a server.
  1165.  
  1166. After the Telnet session is established and protected, it is possible to
  1167. use it to protect the data associated with X Windows System clients started
  1168. on the remote host via the Telnet session. The FORWARD_X option is used to
  1169. negotiate and implement the protection of X Windows Systems data.
  1170.  
  1171. SET TELOPT [ {/CLIENT } ] FORWARD_X { ACCEPTED, REFUSED, REQUESTED,
  1172. REQUIRED }
  1173.      ACCEPT or REFUSE a request to negotiate FORWARD_X, or actively REQUEST
  1174.      that FORWARD_X be negotiated. REQUIRED refuses and closes the
  1175.      connection if the peer refuses to negotiate FORWARD_X or the FORWARD_X
  1176.      negotiations end in failure. ACCEPTED by default when a client. Kermit
  1177.      does not support FORWARD_X when it is a server.
  1178.  
  1179. After a Telnet session is authenticated and protected it is possible to
  1180. forward the credentials used to authenticate the session to the host. When
  1181. credentials are forwarded to the host you do not need to enter your
  1182. password when making additional connections from it. This is referred to as
  1183. Single Sign-On. Credentials forwarding is currently only supported when the
  1184. authentication method is Kerberos 5.
  1185.  
  1186. SET TELNET AUTHENTICATION FORWARDING { ON, OFF }
  1187.      When Kermit is the client, set this to ON to forward forwardable
  1188.      Kerberos V Ticket Granting Tickets to the host after authentication is
  1189.      complete, so you can make additional authenticated connections from
  1190.      there. When Kermit is the server, set this to ON to accept forwardable
  1191.      Kerberos V TGTs from the client. OFF by default.
  1192.  
  1193. When establishing a secure connection there are potentially three usernames
  1194. associated with the connection: the name of the user on the local machine;
  1195. the name the user authenticates as (ie, the Kerberos principal name or
  1196. X.509 certificate name); and the name the user wants to login as. The login
  1197. name can be set with either of these commands.
  1198.  
  1199. SET TELNET ENVIRONMENT USER name
  1200. SET LOGIN USERID name
  1201.      If a name is given, it sent to host during Telnet negotiations; if
  1202.      this switch is given but the string is omitted, no user ID is sent to
  1203.      the host. If this command is not given, your current USERID value,
  1204.      \v(userid), is sent. When a userid is sent to the host it is a request
  1205.      to login as the specified user.
  1206.  
  1207. All forms of authentication rely on some secret information that only the
  1208. user (or service) being authenticated either knows or has in their
  1209. possession. Before Kermit can authenticate as the user it must acquire this
  1210. secret information. This is usually done by prompting the user for the
  1211. necessary information at the time of authentication. But what if you need
  1212. to automate the process? The SET LOGIN PASSWORD command can be used to
  1213. specify the password to Kermit prior to establishing the connection.
  1214. However, we strongly advise that this command be used in only conjunction
  1215. with a script that prompts for the password and then establishes the
  1216. automated connection at a later date and time. Storing a password in a
  1217. script file defeats all of the hard work you have put into securing your
  1218. systems.
  1219.  
  1220. SET LOGIN PASSWORD password
  1221.      If a password is given, it is treated as the password to be used (if
  1222.      required) by any Telnet Authentication protocol (Kerberos Ticket
  1223.      retrieval, Secure Remote Password (SRP), or X.509 certificate private
  1224.      key decryption.) If no password is specified a prompt is issued to
  1225.      request the password if one is required for the negotiated
  1226.      authentication method.
  1227.  
  1228. If things go wrong when establishing a secure connection it is useful to be
  1229. able to watch the telnet negotiations. Even when things are working
  1230. perfectly it can be fun to watch all of the action.
  1231.  
  1232. SET TELNET DEBUG ON
  1233.      Displays all TELNET negotiations in full detail.
  1234.  
  1235. 6.2. The SET AUTHENTICATION Command
  1236.  
  1237. The SET AUTHENTICATION command lets you configure the behavior of Kermit's
  1238. authentication methods and set defaults for the AUTHENTICATE commands so
  1239. you don't always have to include all the switches if you give more than one
  1240. AUTHENTICATE command in one Kermit session.
  1241.  
  1242. If you always use the same setup, you can put the appropropriate SET
  1243. AUTHENTICATION commands in your Kermit customization file: K95CUSTOM.INI
  1244. (Windows) or .mykermrc (UNIX).
  1245.  
  1246. 6.2.1. Kerberos Set Commands
  1247.  
  1248. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } AUTODESTROY { ON-CLOSE,
  1249. ON-EXIT, NEVER }
  1250.      When ON, Kermit destroys all credentials in the default credentials
  1251.      cache upon Kermit termination. Default is NEVER.
  1252.  
  1253. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } AUTOGET { ON, OFF }
  1254.      When ON, if the host offers Kerberos 4 or Kerberos 5 authentication
  1255.      and Kermit is configured to use that authentication method and there
  1256.      is no TGT, Kermit automatically attempts to retrieve one by prompting
  1257.      for the password (and principal if needed.) Default is ON.
  1258.  
  1259. SET AUTHENTICATION KERBEROS5 CREDENTIALS-CACHE filename
  1260.      Specifies an alternative credentials cache. This is useful when you
  1261.      need to maintain two or more sets of credentials for different realms
  1262.      or roles. The default is specified by the environment variable
  1263.      KRB5CCNAME or as reported by the Kerberos 5 library.
  1264.  
  1265. SET AUTHENTICATION KERBEROS5 FORWARDABLE { ON, OFF }
  1266.      ON specifies that Kerberos 5 credentials should be forwardable to the
  1267.      host. If SET TELNET AUTHENTICATION FORWARDING is ON, forwardable
  1268.      credentials are sent to the host. Default is OFF.
  1269.  
  1270. SET AUTHENTICATION KERBEROS5 GET-K4-TGT { ON, OFF }
  1271.      ON specifies that Kerberos 4 credentials should be requested each time
  1272.      Kerberos 5 credentials are requested with AUTH KERBEROS5 INIT. The
  1273.      default is OFF.
  1274.  
  1275. SET AUTHENTICATION KERBEROS4 INSTANCE instance
  1276.      Allows a Kerberos 4 instance to be specified as a default (if needed).
  1277.  
  1278. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } LIFETIME minutes
  1279.      Specifies the lifetime of the TGTs requested from the KDC. The default
  1280.      is 600 minutes (10 hours).
  1281.  
  1282. SET AUTHENTICATION KERBEROS5 NO-ADDRESSES { ON, OFF } [K95 only]
  1283.      Kerberos 5 tickets contain a list of all of the IP addresses
  1284.      associated with the computer used to acquire them. This allows the
  1285.      recipient of a ticket to check whether it came from the machine to
  1286.      which it was issued, and makes stolen Kerberos tickets useless.
  1287.      Network Address Translators and other Proxy services have the side
  1288.      effect of changing the IP address from which a connection appears to
  1289.      originate. This causes the IP address check to fail and for Kerberos 5
  1290.      tickets to be rejected as invalid. When ON, the NO-ADDRESSES command
  1291.      prevents the inclusion of IP addresses in Kerberos 5 tickets retrieved
  1292.      with Kermit's AUTHENTICATE KERBEROS5 INIT command enabling the tickets
  1293.      to be accepted from any host.
  1294.  
  1295. SET AUTHENTICATION KERBEROS4 PREAUTH { ON, OFF }
  1296.      Allows Kerberos 4 preauthenticated TGT requests to be turned off. The
  1297.      default is ON. Only use if absolutely necessary. We recommend that
  1298.      preauthenticated requests be required for all tickets returned by a
  1299.      KDC to a requestor.
  1300.  
  1301. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL name
  1302.      When Kermit starts, it attempts to set the principal name to that
  1303.      stored in the current credentials cache. If no credential cache
  1304.      exists, the current SET LOGIN USERID value is used. SET LOGIN USERID
  1305.      is set to the operating systems current username when Kermit is
  1306.      started. To force Kermit to prompt the user for the principal name
  1307.      when requesting TGTs, place:
  1308.  
  1309.        SET AUTH K4 PRINCIPAL {}
  1310.        SET AUTH K5 PRINCIPAL {}
  1311.  
  1312.      in the Kermit initialization file or connection script.
  1313.  
  1314. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PROMPT PASSWORD prompt
  1315.      Specifies a custom prompt to be used when prompting for a password.
  1316.      The Kerberos prompt strings may contain two "%s" replacement fields.
  1317.      The first %s is replaced by the principal name; the second by the
  1318.      realm.
  1319.  
  1320. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PROMPT PRINCIPAL prompt
  1321.      Specifies a custom prompt to be used when prompting for the Kerberos
  1322.      principal name. No %s replacement fields may be included. Kermit
  1323.      prompts for a principal name when retrieving a TGT if the command:
  1324.  
  1325.        SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL {}
  1326.  
  1327.      has been issued.
  1328.  
  1329. SET AUTHENTICATION KERBEROS5 PROXIABLE { ON, OFF }
  1330.      When ON, specifies that Kerberos 5 credentials should be proxiable.
  1331.      The default is OFF.
  1332.  
  1333. SET AUTHENTICATION KERBEROS5 RENEWABLE minutes
  1334.      When minutes is greater than the ticket lifetime a TGT may be renewed
  1335.      with AUTH K5 INIT /RENEW instead of granting a new ticket as long as
  1336.      the ticket is not expired and it's within the renewable lifetime.
  1337.      Default is 0 (zero) minutes.
  1338.  
  1339. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } REALM name
  1340.      If no default is set, the default realm configured for the Kerberos
  1341.      libraries is used. Abbreviations are accepted.
  1342.  
  1343. SET AUTHENTICATION { KERBEROS4, KERBEROS5 } SERVICE-NAME name
  1344.      This command specifies the service ticket name used to authenticate to
  1345.      the host when Kermit is used as a client; or the service ticket name
  1346.      accepted by Kermit when it is acting as the host. If no default is
  1347.      set, the default service name for Kerberos 4 is "rcmd" and for
  1348.      Kerberos 5 is "host".
  1349.  
  1350. 6.2.2. SRP SET Commands
  1351.  
  1352. SET AUTHENTICATE SRP PROMPT PASSWORD text
  1353.      Specifies a custom prompt to be used when prompting for a password.
  1354.      prompt may contain a single instance of "%s" which is replaced by the
  1355.      user's login name.
  1356.  
  1357. 6.2.3. SSL and TLS (OpenSSL) SET Commands
  1358.  
  1359. In all of the following commands "SSL" and "TLS" are aliases.
  1360.  
  1361. SET AUTHENTICATE { SSL, TLS } CIPHER-LIST list-of-ciphers
  1362.      This command applies to both SSL and TLS. A colon-separated list of
  1363.      any of the following (case-sensitive) options is accepted, depending
  1364.      on the options chosen when OpenSSL was compiled:
  1365.  
  1366.      Key Exchange Algorithms:
  1367.         * kRSA: RSA key exchange
  1368.         * kDHr: Diffie-Hellman key exchange (key from RSA cert)
  1369.         * kDHd: Diffie-Hellman key exchange (key from DSA cert)
  1370.         * kEDH: Ephemeral Diffie-Hellman key exchange (temporary key)
  1371.  
  1372.      Authentication Algorithm:
  1373.         * aNULL: No authentication
  1374.         * aRSA: RSA authentication
  1375.         * aDSS: DSS authentication
  1376.         * aDH: Diffie-Hellman authentication
  1377.  
  1378.      Cipher Encoding Algorithm:
  1379.         * eNULL: No encodiing
  1380.         * DES: DES encoding
  1381.         * 3DES: Triple DES encoding
  1382.         * RC4: RC4 encoding
  1383.         * RC2: RC2 encoding
  1384.         * IDEA: IDEA encoding
  1385.  
  1386.      MAC Digest Algorithm:
  1387.         * MD5: MD5 hash function
  1388.         * SHA1: SHA1 hash function
  1389.         * SHA: SHA hash function (should not be used)
  1390.  
  1391.      Aliases:
  1392.         * ALL: all ciphers
  1393.         * SSLv2: all SSL version 2.0 ciphers (should not be used)
  1394.         * SSLv3: all SSL version 3.0 ciphers
  1395.         * EXP: all export ciphers (40-bit)
  1396.         * EXPORT56: all export ciphers (56-bit)
  1397.         * LOW: all low strength ciphers (no export)
  1398.         * MEDIUM: all ciphers with 128-bit encryption
  1399.         * HIGH: all ciphers using greater than 128-bit encryption
  1400.         * RSA: all ciphers using RSA key exchange
  1401.         * DH: all ciphers using Diffie-Hellman key exchange
  1402.         * EDH: all ciphers using Ephemeral Diffie-Hellman key exchange
  1403.         * ADH: all ciphers using Anonymous Diffie-Hellman key exchange
  1404.         * DSS: all ciphers using DSS authentication
  1405.         * NULL: all ciphers using no encryption
  1406.  
  1407.      Each item in the list may include a prefix modifier:
  1408.  
  1409.      "+"
  1410.           Move cipher(s) to the current location in the list
  1411.      "-"
  1412.           Remove cipher(s) from the list (may be added again by a
  1413.           subsequent list entry)
  1414.      "!"
  1415.           Kill cipher from the list (it may not be added again by a
  1416.           subsequent list entry)
  1417.  
  1418.      If no modifier is specified the entry is added to the list at the
  1419.      current position. "+" may also be used to combine tags to specify
  1420.      entries such as "RSA+RC4" describes all ciphers that use both RSA and
  1421.      RC4.
  1422.  
  1423. For example, all available ciphers not including ADH key exchange:
  1424.  
  1425.   ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
  1426.  
  1427. All algorithms including ADH and export but excluding patented algorithms:
  1428.  
  1429.   HIGH:MEDIUM:LOW:EXPORT56:EXP:ADH:!kRSA:!aRSA:!RC4:!RC2:!IDEA
  1430.  
  1431. The OpenSSL command:
  1432.  
  1433.   openssl ciphers -v list-of-ciphers
  1434.  
  1435. may be used to list all of the ciphers and the order described by a
  1436. specific list-of-ciphers.
  1437.  
  1438. SET AUTHENTICATE { SSL, TLS } CRL-DIR directory
  1439.      Specifies a directory that contains certificate revocation files,
  1440.      where each file is named by the hash of the certificate issuer name.
  1441.      OpenSSL expects the hash symlinks to be made like this:
  1442.  
  1443.        ln -s crl.pem `openssl crl -hash -noout -in crl.pem`.r0
  1444.  
  1445.      Since all file systems do not have symlinks you can use the following
  1446.      command in Kermit to copy the crl.pem file to the hash file name:
  1447.  
  1448.        copy crl.pem {\fcommand(openssl crl -hash -noout -in crl.pem).r0}
  1449.  
  1450.      This produces a hash based on the issuer field in the CRL such that
  1451.      the issuer field of a Cert may be quickly mapped to the correct CRL.
  1452.  
  1453. SET AUTHENTICATE { SSL, TLS } CRL-FILE filename
  1454.      Specifies a file that contains a list of certificate revocations.
  1455.  
  1456. SET AUTHENTICATE { SSL, TLS } DEBUG { ON, OFF }
  1457.      Tells whether debug information should be displayed about the SSL/TLS
  1458.      connection. When DEBUG is ON, the VERIFY command does not terminate
  1459.      connections when set to FAIL-IF-NO-PEER-CERT and a certificate is
  1460.      presented that cannot be successfully verified; instead each error is
  1461.      displayed but the connection automatically continues.
  1462.  
  1463. SET AUTHENTICATE { SSL, TLS } DH-PARAM-FILE filename
  1464.      Specifies a file containing DH parameters which are used to generate
  1465.      temporary DH keys. If a DH parameter file is not provided Kermit uses
  1466.      a fixed set of parameters depending on the negotiated key length.
  1467.      Kermit provides DH parameters for key lengths of 512, 768, 1024, 1536,
  1468.      and 2048 bits.
  1469.  
  1470. SET AUTHENTICATE { SSL, TLS } DSA-CERT-FILE filename
  1471.      Specifies a file containing a DSA certificate to be sent to the peer
  1472.      to authenticate the host or end user. The file may contain the
  1473.      matching DH private key instead of using the DSA-KEY-FILE command.
  1474.  
  1475. SET AUTHENTICATE { SSL, TLS } DSA-KEY-FILE filename
  1476.      Specifies a file containing the private DH key that matches the DSA
  1477.      certificate specified with DSA-CERT-FILE. This command is only
  1478.      necessary if the private key is not appended to the certificate in the
  1479.      file specified by DSA-CERT-FILE.
  1480.  
  1481. Note: When Kermit is running as an IKSD it cannot support encrypted private
  1482. keys. If your private key file is encrypted you can use the following
  1483. command to unencrypt it (provided you know that pass phrase):
  1484.  
  1485.   openssl dsa -in encrypted-key-file -out unencrypted-key-file
  1486.  
  1487. SET AUTHENTICATE { SSL, TLS } RANDOM-FILE filename
  1488.      Specifies a file containing random data to be used when initializing
  1489.      the Pseudo Random Number Generator (PRNG) engine. This file will be
  1490.      overwritten with new random data after the file is read.
  1491.  
  1492. SET AUTHENTICATE { SSL, TLS } RSA-CERT-FILE filename [K95 only]
  1493.      Specifies a file containing a RSA certificate to be sent to the peer
  1494.      to authenticate the host or end user. The file may contain the
  1495.      matching RSA private key instead of using the RSA-KEY-FILE command.
  1496.  
  1497. SET AUTHENTICATE { SSL, TLS } RSA-KEY-FILE filename
  1498.      Specifies a file containing the private RSA key that matches the RSA
  1499.      certificate specified with RSA-CERT-FILE. This command is only
  1500.      necessary if the private key is not appended to the certificate in the
  1501.      file specified by RSA-CERT-FILE.
  1502.  
  1503. Note: When Kermit is running as an IKSD it cannot support encrypted private
  1504. keys. If your private key file is encrypted you can use the following
  1505. command to unencrypt it (provided you know that pass phrase):
  1506.  
  1507.   openssl rsa -in encrypted-key-file -out unencrypted-key-file
  1508.  
  1509. SET AUTHENTICATE { SSL, TLS } VERBOSE { ON, OFF }
  1510.      Specifies whether information about the authentication (the
  1511.      certificate chain) should be displayed upon making a connection.
  1512.  
  1513. SET AUTHENTICATE { SSL, TLS } VERIFY { NO, PEER-CERT, FAIL-IF-NO-PEER-CERT
  1514. }
  1515.      Specifies whether certificates should be requested from the peer;
  1516.      whether they should be verified when they are presented; and whether
  1517.      they should be required. When set to NO (the default for IKSD), Kermit
  1518.      does not request that the peer send a certificate and if one is
  1519.      presented it is ignored. When set to PEER-CERT (the default when not
  1520.      IKSD), Kermit requests a certificate be sent by the peer. If the
  1521.      certificate is presented, it is verified. Any errors during the
  1522.      verification process result in queries to the end user. When set to
  1523.      FAIL-IF-NO-PEER-CERT, Kermit asks the peer to send a certificate. If
  1524.      the certificate is not presented or fails to verify successfully, the
  1525.      connection is terminated without querying the user.
  1526.  
  1527.      If an anonymous cipher (i.e., ADH) is desired the NO setting must be
  1528.      used; otherwise the receipt of the peer certificate request is
  1529.      interpreted as a protocol error and the negotiation fails.
  1530.  
  1531.      If you wish to allow the peer to authenticate using either an X.509
  1532.      certificate to userid mapping function or via use of a ~/.tlslogin
  1533.      file, you must use either PEER-CERT or FAIL-IF-NO-PEER-CERT.
  1534.      Otherwise, any certificates that are presented are ignored. In other
  1535.      words, use NO if you want to disable the ability to use certificates
  1536.      to authenticate a peer.
  1537.  
  1538. SET AUTHENTICATE { SSL, TLS } VERIFY-DIR directory
  1539.      Specifies a directory that contains root CA certificate files used to
  1540.      verify the certificate chains presented by the peer. Each file is
  1541.      named by a hash of the certificate.
  1542.  
  1543.      OpenSSL expects the hash symlinks to be made like this:
  1544.  
  1545.        ln -s cert.pem `openssl x509 -hash -noout -in cert.pem`.0
  1546.  
  1547.      Since all file systems do not have symlinks you can use the following
  1548.      command in Kermit to copy the cert.pem file to the hash file name:
  1549.  
  1550.        copy cert.pem {\fcommand(openssl x509 -hash -noout -in cert.pem).0}
  1551.  
  1552.      This produces a hash based on the subject field in the cert such that
  1553.      the certificate may be quickly found.
  1554.  
  1555. SET AUTHENTICATE { SSL, TLS } VERIFY-FILE file
  1556.      Specifies a file that contains root CA certificates to be used for
  1557.      verifying certificate chains.
  1558.  
  1559. 6.3. The AUTHENTICATE Command (Kerberos Only)
  1560.  
  1561. The AUTHENTICATE command obtains or destroys Kerberos tickets and lists
  1562. information about them. The general format is:
  1563.  
  1564. AUTHENTICATE { KERBEROS4, KERBEROS5 [ switches ] } action [ switches ]
  1565.      The use of command switches is described in Section 1.5 of the
  1566.      C-Kermit 7.0 Update Notes. The actions are INITIALIZE, DESTROY, and
  1567.      LIST-CREDENTIALS.
  1568.  
  1569. The INITIALIZE command is the most complex of Kermit's security commands,
  1570. and its format is different for Kerberos 4 and Kerberos 5:
  1571.  
  1572. Kerberos 4:
  1573.      AUTH K4 INITIALIZE [ k4-switches ] [ principal ]
  1574.  
  1575. Kerberos 5:
  1576.      AUTH K5 [ k5-switches ] { INITIALIZE ..., DESTROY, LIST-CREDENTIALS,
  1577.      ...}
  1578.  
  1579. All switches are optional. The Kerberos 4 INITIALIZE switches are:
  1580.  
  1581. /INSTANCE:name
  1582.      Allows an Instance to be specified (see Glossary).
  1583.  
  1584. /LIFETIME:number
  1585.      Specifies the requested lifetime in minutes for the ticket. If no
  1586.      lifetime is specified, 600 minutes is used. If the lifetime is greater
  1587.      than the maximum supported by the ticket granting service, the
  1588.      resulting lifetime is shortened accordingly.
  1589.  
  1590. /NOT-PREAUTH
  1591.      Instructs Kermit to send a ticket granting ticket (TGT) request to the
  1592.      KDC without any preauthentication data.
  1593.  
  1594. /PASSWORD:string
  1595.      Allows the inclusion of a password in a script file. If no /PASSWORD
  1596.      switch is included, you are prompted on a separate line. The password
  1597.      switch is provided for use by automated scripts. However, we strongly
  1598.      recommend that it not be used because clear-text passwords are easily
  1599.      compromised.
  1600.  
  1601. /PREAUTH
  1602.      Instructs Kermit to send a preauthenticated ticket granting ticket
  1603.      (TGT) request to the KDC instead of a plaintext request. The default
  1604.      when supported by the Kerberos libraries.
  1605.  
  1606. /REALM:name
  1607.      Allows an alternative Realm to be specified (see Glossary).
  1608.  
  1609. principal may be of the form:
  1610.  
  1611.   userid[.instance[.instance]]@[realm]
  1612.  
  1613. and can be omitted if it is the same as your username or SET LOGIN USERID
  1614. value on the client system.
  1615.  
  1616. The INITIALIZE command for Kerberos 5 can include a number of switches; all
  1617. are optional:
  1618.  
  1619. /ADDRESSES:list-of-ip-addresses
  1620.      Specifies a list of IP addresses that should be placed in the Ticket
  1621.      Granting Ticket in addition to the local machine addresses.
  1622.  
  1623. /FORWARDABLE
  1624.      Requests forwardable tickets.
  1625.  
  1626. /KERBEROS4
  1627.      Instructs Kermit to get Kerberos 4 tickets in addition to Kerberos 5
  1628.      tickets. If Kerberos 5 tickets are not supported by the server, a mild
  1629.      warning is printed and Kerberos 4 tickets are requested.
  1630.  
  1631. /LIFETIME:number
  1632.      Specifies the requested lifetime in minutes for the ticket. If no
  1633.      lifetime is specified, 600 minutes is used. If the lifetime is greater
  1634.      than the maximum supported by the ticket granting service, the
  1635.      resulting lifetime is shortened.
  1636.  
  1637. /NO-ADDRESSES [K95 only]
  1638.      Instructs Kermit to not include a list of local IP addresses in the
  1639.      ticket retrieved from the KDC.
  1640.  
  1641. /NO-KERBEROS4
  1642.      Instructs Kermit to not attempt to retrieve Kerberos 4 credentials.
  1643.  
  1644. /NOT-FORWARDABLE
  1645.      Requests non-forwardable tickets.
  1646.  
  1647. /NOT-PROXIABLE
  1648.      Requests non-proxiable tickets.
  1649.  
  1650. /PASSWORD:string
  1651.      Allows the inclusion of a password in a script. If no password is
  1652.      specified you are prompted for one. The password switch is provided
  1653.      for use by automated scripts. However, we strongly recommend that it
  1654.      not be used because clear-text passwords can be easily compromised.
  1655.      See Chapter 19 of Using C-Kermit.
  1656.  
  1657. /POSTDATE:date-time
  1658.      Requests a postdated ticket, valid starting at date-time. Postdated
  1659.      tickets are issued with the invalid flag set, and need to be fed back
  1660.      to the KDC before use with the /VALIDATE switch. See Section 1.6 of
  1661.      the C-Kermit 7.0 Update Notes for acceptable date-time formats.
  1662.  
  1663. /PROXIABLE
  1664.      Requests proxiable tickets.
  1665.  
  1666. /REALM:string
  1667.      Allows an alternative realm to be specified.
  1668.  
  1669. /RENEW
  1670.      Requests renewal of a renewable Ticket Granting Ticket. Note that an
  1671.      expired ticket cannot be renewed even if it is within its renewable
  1672.      lifetime.
  1673.  
  1674. /RENEWABLE:number
  1675.      Requests renewable tickets, with a total lifetime of number minutes.
  1676.  
  1677. /SERVICE:string
  1678.      Allows a service other than the ticket granting service to be
  1679.      specified.
  1680.  
  1681. /VALIDATE
  1682.      Requests that the Ticket Granting Ticket in the cache (with the
  1683.      invalid flag set) be passed to the KDC for validation. If the ticket
  1684.      is within its requested time range, the cache is replaced with the
  1685.      validated ticket.
  1686.  
  1687. principal may be of the form:
  1688.  
  1689.   userid[/instance][@realm]
  1690.  
  1691. and can be omitted if it is the same principal as stored in the current
  1692. ticket cache at the time Kermit started; or the current username if a
  1693. ticket cache did not exist.
  1694.  
  1695. Note: Kerberos 5 always attempts to retrieve a Ticket Granting Ticket (TGT)
  1696. using the preauthenticated TGT request.
  1697.  
  1698. AUTHORIZE K5 LIST-CREDENTIALS [ switches ]
  1699.      Shows start time, expiration time, service or principal name, plus the
  1700.      following additional information depending the switches:
  1701.  
  1702.      /ADDRESSES
  1703.           Displays the hostnames and/or IP addresses embedded within the
  1704.           tickets.
  1705.  
  1706.      /ENCRYPTION
  1707.           Displays the encryption used by each ticket (if applicable):
  1708.              + DES-CBC-CRC
  1709.              + DES-CBC-MD4
  1710.              + DES-CBC-MD5
  1711.              + DES3-CBC-SHA
  1712.  
  1713.      /FLAGS
  1714.           provides the following information (if applicable) for each
  1715.           ticket:
  1716.              + F - Ticket is Forwardable
  1717.              + f - Ticket was Forwarded
  1718.              + P - Ticket is Proxiable
  1719.              + p - Ticket is a Proxy
  1720.              + D - Ticket may be Postdated
  1721.              + d - Ticket has been Postdated
  1722.              + i - Ticket is Invalid
  1723.              + R - Ticket is Renewable
  1724.              + I - Ticket is the Initial Ticket
  1725.              + H - Ticket has been authenticated by Hardware
  1726.              + A - Ticket has been Pre-authenticated
  1727.  
  1728. 6.4. OTHER SECURITY-RELATED COMMANDS
  1729.  
  1730. SET TCP ADDRESS [ ip-address ]
  1731.      Specifies the IP address of the computer that C-Kermit is running on.
  1732.      Normally this is not necessary. The exceptions would be if the host is
  1733.      multihomed (e.g. one host pointed to by many IP addresses, or one of
  1734.      many hosts pointed to by a "common" IP address) or has multiple
  1735.      physical network adapters, with a different address for each adapter,
  1736.      AND you want C-Kermit to either (a) accept an incoming TCP connection
  1737.      ("set host *") or (b) get a Kerberos ticket.
  1738.  
  1739. SET TCP REVERSE-DNS-LOOKUP { ON, OFF }
  1740.      Specifies whether or not a Reverse DNS Lookup should be performed to
  1741.      determine the hostname assigned to the IP address used to connect to
  1742.      the host.
  1743.  
  1744. For mutual authentication to succeed, the client and the server must agree
  1745. on the name to be used for the server. It is common for servers to have
  1746. more than one name. This is especially true for clusters of servers that
  1747. provide the same function and are referenced by an alias. For instance
  1748. www.foo.com might be an alias for three machines www-1.foo.com,
  1749. www-2.foo.com, and www-3.foo.com. If the hosts are configured to use
  1750. separate credentials for authentication it will be necessary to know which
  1751. host is actually in use since "www.foo.com" is not equal to
  1752. "www-1.foo.com".
  1753.  
  1754. On the other hand, since DNS is not a secure service, using an additional
  1755. lookup to verify the name associated with a particular IP address increases
  1756. the susceptibility that the authentication may be forged by an attacker.
  1757.  
  1758. For the highest level of security, Reverse DNS Lookups should be turned
  1759. OFF.
  1760.  
  1761.   ------------------------------------------------------------------------
  1762.  
  1763. 7. MAKING A SECURE CONNECTION
  1764.  
  1765. All TCP/IP connections established by Kermit are initiated either with the
  1766. SET HOST command or a protocol-specific command such as TELNET or RLOGIN.
  1767. When using the SET HOST command to establish a secure connection, several
  1768. switches are available between SET HOST and the hostname, plus a protocol
  1769. switch at the end:
  1770.  
  1771. SET HOST [ switches ] hostname-or-address [ service ] [ protocol-switch ]
  1772.      Establishes a connection to the specified network host on the
  1773.      currently selected network type. For TCP/IP connections, the default
  1774.      service is TELNET and the default protocol is TELNET. Not all
  1775.      protocols have a default service name.
  1776.  
  1777. The following switches are useful with secure connections:
  1778.  
  1779. /CONNECT
  1780.      Enter CONNECT (terminal) mode automatically if the connection is
  1781.      successful.
  1782.  
  1783. /SERVER
  1784.      Enter server mode automatically if the connection is successful.
  1785.  
  1786. /USERID:[name]
  1787.      This switch is equivalent to SET LOGIN USERID or SET TELNET
  1788.      ENVIRONMENT USER . If a string is given, it sent to host during Telnet
  1789.      negotiations; if this switch is given but the string is omitted, no
  1790.      user ID is sent to the host. If this switch is not given, your current
  1791.      USERID value, \v(userid), is sent. When a userid is sent to the host
  1792.      it is a request to login as the specified user.
  1793.  
  1794. /PASSWORD:[string]
  1795.      This switch is equivalent to SET LOGIN PASSWORD. If a string is given,
  1796.      it is treated as the password to be used (if required) by any Telnet
  1797.      Authentication protocol (Kerberos Ticket retrieval, Secure Remote
  1798.      Password, or X.509 certificate private key decryption.) If no password
  1799.      switch is specified a prompt is issued to request the password if one
  1800.      is required for the negotiated authentication method.
  1801.  
  1802. The protocol-switches used with secure connections are:
  1803.  
  1804. /RLOGIN
  1805.      Use Rlogin protocol even if this is not an Rlogin port.
  1806.  
  1807. /TELNET
  1808.      Send initial Telnet negotiations even if this is not a Telnet port.
  1809.  
  1810. /K4LOGIN
  1811.      Use Kerberos IV klogin protocol even if this is not a klogin port.
  1812.  
  1813. /EK4LOGIN
  1814.      Use Kerberos IV Encrypted login protocol even if this is not an
  1815.      eklogin port.
  1816.  
  1817. /K5LOGIN
  1818.      Use Kerberos V klogin protocol even if this is not a klogin port.
  1819.  
  1820. /EK5LOGIN
  1821.      Use Kerberos V Encrypted login protocol even if this is not an eklogin
  1822.      port.
  1823.  
  1824. /K5USER2USER
  1825.      Use Kerberos V User to User protocol.
  1826.  
  1827. /SSL
  1828.      Perform SSL negotiations.
  1829.  
  1830. /SSL-TELNET
  1831.      Perform SSL negotiations and if successful start Telnet negotiations.
  1832.  
  1833. /TLS
  1834.      Perform TLS negotiations.
  1835.  
  1836. /TLS-TELNET
  1837.      Perform TLS negotiations and if successful start Telnet negotiations.
  1838.  
  1839. 7.1. Using TELNET protocol
  1840.  
  1841. The TELNET command combines a number of commands related to secure telnet
  1842. connections into a single interface.
  1843.  
  1844. TELNET /AUTH:type /ENCRYPT:type /USERID:[name] /PASSWORD:[string] host port
  1845.      The TELNET command is a shortcut for making interactive connections.
  1846.      It is the equivalent of specifying:
  1847.  
  1848.        SET TELOPT AUTH ...
  1849.        SET TELNET AUTH TYPE ...
  1850.        SET TELOPT ENCRYPT ...
  1851.        SET TELNET ENCRYPT TYPE ...
  1852.        SET LOGIN USERID ...
  1853.        SET LOGIN PASSWORD ...
  1854.        SET HOST /CONNECT host port /TELNET
  1855.  
  1856.      where:
  1857.  
  1858.      /AUTH:type
  1859.           is equivalent to SET TELNET AUTH TYPE type and SET TELOPT AUTH
  1860.           REQUIRED with the following exceptions. If the type is AUTO, then
  1861.           SET TELOPT AUTH REQUESTED is executed and if the type is NONE,
  1862.           then SET TELOPT AUTH REFUSED is executed.
  1863.  
  1864.      /ENCRYPT:type
  1865.           Is equivalent to SET TELNET ENCRYPT TYPE type and SET TELOPT
  1866.           ENCRYPT REQUIRED REQUIRED with the following exceptions. If the
  1867.           type is AUTO then SET TELOPT AUTH REQUESTED REQUESTED is executed
  1868.           and if the type is NONE then SET TELOPT ENCRYPT REFUSED REFUSED
  1869.           is executed.
  1870.  
  1871.      /USERID:[name]
  1872.           This switch is equivalent to SET LOGIN USERID name or SET TELNET
  1873.           ENVIRONMENT USER name. If a string is given, it sent to host
  1874.           during Telnet negotiations; if this switch is given but the
  1875.           string is omitted, no user ID is sent to the host. If this switch
  1876.           is not given, your current USERID value, \v(userid), is sent.
  1877.           When a userid is sent to the host it is a request to login as the
  1878.           specified user.
  1879.  
  1880.      /PASSWORD:[string]
  1881.           This switch is equivalent to SET LOGIN PASSWORD. If a string is
  1882.           given, it is treated as the password to be used (if required) by
  1883.           any Telnet Authentication protocol (Kerberos Ticket retrieval,
  1884.           Secure Remote Password, or X.509 certificate private key
  1885.           decryption.) If no password switch is specified a prompt is
  1886.           issued to request the password if one is required for the
  1887.           negotiated authentication method.
  1888.  
  1889. 7.2. Using RLOGIN protocol
  1890.  
  1891. The RLOGIN (Remote Login) protocol unlike the Telnet protocol is not at all
  1892. flexible and it supports no option mechanism. Authentication and privacy is
  1893. not really part of the RLOGIN protocol. When we refer to authenticated and
  1894. encrypted RLOGIN we are really referring to one of four other protocols
  1895. derived from RLOGIN: Kerberos 4 Remote Login (K4LOGIN); Kerberos 4
  1896. Encrypted Remote Login (EK4LOGIN); Kerberos 5 Remote Login (K5LOGIN); and
  1897. Kerberos 5 Encrypted Remote Login (EK5LOGIN).
  1898.  
  1899. RLOGIN /ENCRYPT /KERBEROS4 /KERBEROS5 hostname username
  1900.      The RLOGIN command is a shortcut for making interactive connections.
  1901.      It is the equivalent of specifying:
  1902.  
  1903.        SET LOGIN USERID ...
  1904.        SET HOST /CONNECT hostname service [ protocol-switch ]
  1905.  
  1906.      where the combinations of /ENCRYPT /KERBEROS4 /KERBEROS5 result in the
  1907.      following protocol-switches:
  1908.  
  1909.      /KERBEROS4
  1910.           means service klogin and protocol k4login
  1911.  
  1912.      /KERBEROS4 /ENCRYPT
  1913.           means service eklogin and protocol ek4login
  1914.  
  1915.      /KERBEROS5
  1916.           means service klogin and protocol k5login
  1917.  
  1918.      /KERBEROS5 /ENCRYPT
  1919.           means service eklogin and protocol ek5login
  1920.  
  1921. 7.3. Using Only SSL or TLS
  1922.  
  1923. Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
  1924. were designed to secure e-commerce transactions (HTTP) over the Internet.
  1925. Their use is becoming widespread as a means for securing other protocols
  1926. such as FTP, IMAP, POP3, LDAP, NNTP, and even insecure versions of Telnet.
  1927. Kermit provides the ability to establish SSL and TLS connections which can
  1928. then be used to transfer data, script HTTP sessions, or use Telnet protocol
  1929. without the START_TLS option.
  1930.  
  1931. Kermit provides four protocol-switches for establishing SSL or TLS
  1932. connections: /SSL, /TLS, /SSL-TELNET, and /TLS-TELNET. Unlike other
  1933. protocols such as TELNET and RLOGIN there are no standard services (IP
  1934. ports) assigned to these protocols. Use of these protocols assumes prior
  1935. knowledge of the ports to connect to on the remote host. There are also no
  1936. shortcut commands for use with these protocols. Use the SET HOST command as
  1937. described above when making connections.
  1938.  
  1939. The SET AUTHENTICATION { SSL, TLS } ... commands are used to configure the
  1940. certificates, certificate authorities, and verification options used during
  1941. connection establishment.
  1942.  
  1943. 7.4. Using Kerberos 5 User to User protocol
  1944.  
  1945. The Kerberos 5 authentication implemented in the Telnet protocol is a
  1946. client to server authentication protocol. It requires that the parties to
  1947. the authentication be an end user principal and a service principal. The
  1948. Kerberos 5 User to User protocol is specificly designed to allow two end
  1949. user principals to authenticate one another. The shared secret generated
  1950. during the authentication is then used to ensure the privacy of the data
  1951. transmitted on the connection.
  1952.  
  1953. There is no shortcut command provided for Kerberos 5 User to User protocol;
  1954. nor is there a default service. To establish a connection between two
  1955. Kermit processes using Kerberos 5 User to User protocol:
  1956.  
  1957.    * each user must have retrieved a valid Kerberos 5 TGT
  1958.    * one user must issue a SET HOST * port /K5USER2USER command
  1959.    * one user must issue a SET HOST hostname port /K5USER2USER command
  1960.  
  1961.   ------------------------------------------------------------------------
  1962.  
  1963. 8. EFFECTS OF ENCRYPTION ON FILE TRANSFER PERFORMANCE
  1964.  
  1965. Encryption and the subsequent decryption of a data stream can result in 10%
  1966. to 60% reduction in file transfer performance depending on the encryption
  1967. algorithm. Encrypted data streams are uncompressible, thus reducing
  1968. throughput on PPP connections.
  1969.  
  1970.   ------------------------------------------------------------------------
  1971.  
  1972. 9. MULTI-HOMED HOSTS AND NETWORK ADDRESS TRANSLATORS
  1973.  
  1974. Kermit is designed to allow authentication with hosts whose names resolve
  1975. to multiple (randomized) IP addresses.
  1976.  
  1977. However, this does not always work on Windows 95 or Windows NT 3.5x due to
  1978. their caching of DNS information. For instance, at Columbia University the
  1979. CUNIX name resolves to one of six machines, each with a different name,
  1980. such as HOSTA, HOSTB, etc. When telneting to CUNIX, you might be given IP
  1981. address 128.59.35.136. But even though the DNS servers are properly
  1982. configured to return the proper name (e.g. HOSTB) for that IP address,
  1983. Windows 95 returns CUNIX because it retrieves the information from its
  1984. internal cache instead of performing another network call. This means that
  1985. instead of retrieving a Kerberos 4 ticket for the service:
  1986.  
  1987.   rcmd.hostb@CC.COLUMBIA.EDU
  1988.  
  1989. we get a ticket for:
  1990.  
  1991.   rcmd.cunix@CC.COLUMBIA.EDU
  1992.  
  1993. This use of the wrong ticket produces the following error:
  1994.  
  1995.   Can't decode authenticator (krb_rd_req)
  1996.  
  1997. Kerberos 4 has no problems with NATs but fails with Multihomed systems.
  1998. Why? A K4 ticket has room for only a single IP address and that IP address
  1999. is assigned not by the client but by the KDC. The result is that when K4 is
  2000. used from behind a NAT the IP address that is placed into the ticket is the
  2001. IP address of the NAT, not the IP address of the client machine. This means
  2002. the ticket is good only on the far side of the NAT and not on the near
  2003. side. It also means that when a K4 ticket is used with a multihomed host
  2004. that the ticket is good only on the interface that was used to acquire the
  2005. ticket in the first place.
  2006.  
  2007. Kerberos 5 has no problems with multihomed hosts because the ticket
  2008. supports multiple IP addresses and those IP addresses are inserted into the
  2009. ticket by the client, not by the KDC. However, this also means that K5
  2010. fails when it is used through a NAT. The address in the ticket is the
  2011. private IP address and not the address that the KDC sees. This can be
  2012. worked around if the client uses a kinit that allows a list of additional
  2013. IP addresses to be specified for inclusion in the TGT. Kermit supports this
  2014. capability with the
  2015.  
  2016.   AUTH K5 INIT /ADDRESSES:{list-of-addresses}
  2017.  
  2018. command. The problem with this solution is that, although it is secure, in
  2019. most cases the end user does not know which IP address is assigned to the
  2020. far side of the NAT. In this situation it is necessary to remove all IP
  2021. addresses from the TGT. Kermit provides the AUTH K5 INIT /NO-ADDRESSES and
  2022. SET AUTH K5 NO-ADDRESSES ON commands for this purpose. However, this
  2023. solution is less secure since a TGT with no specified IP addresses can be
  2024. used from any machine. Stolen TGTs are therefore extremely useful to a
  2025. thief. We strongly advise that removing the IP address information from
  2026. Kerberos 5 tickets not be performed on computers using file based caches as
  2027. they are particularly vulnerable to theft.
  2028.  
  2029.   ------------------------------------------------------------------------
  2030.  
  2031. 10. OTHER NOTES
  2032.  
  2033. In Kermit 95, the authentication type and encryption levels are displayed
  2034. in the terminal-screen status Line as follows:
  2035.  
  2036.   K4  - Kerberos IV
  2037.   K5  - Kerberos V
  2038.   NTLM- NT Lan Manager
  2039.   SRP - Secure Remote Password
  2040.  
  2041.   pp  - No encryption
  2042.   Ep  - Encryption to host, plaintext from host
  2043.   pD  - Plaintext to host, encryption from host
  2044.   ED  - Encryption both directions
  2045.   SSL - Secure Sockets Layer (both directions)
  2046.   TLS - Transport Layer Security (both directions)
  2047.  
  2048. Encrypted sessions become unreadable if even one bit of data is inserted
  2049. into or deleted from the data stream. One damaged bit results in nine
  2050. damaged bytes but subsequent bytes remain readable. But since TCP/IP is a
  2051. reliable transport by definition, none of this should occur.
  2052.  
  2053. Windows login names are not case-sensitive. However, Unix login names are.
  2054. If the Unix login name is "fred" but Windows was logged in using the name
  2055. "Fred", authentication appears to succeed but telnetd closes the connection
  2056. after Telnet negotiations are complete. There are several solutions to this
  2057. problem:
  2058.  
  2059.    * Make sure the Windows login name is case identical to the Unix login
  2060.      name. (If Windows has recorded the login in the registry as "Fred" it
  2061.      won't matter if you login to Windows using "fred". The only way to
  2062.      correct this problem is to edit the Registry.)
  2063.  
  2064.    * Use the SET LOGIN USERID name command to set the proper login name
  2065.      before connecting to the telnet server.
  2066.  
  2067.    * Use the SET AUTHENTICATE { KERBEROS4, KERBEROS5 } PRINCIPAL name
  2068.      command to set the proper principal name before connecting to the
  2069.      telnet server.
  2070.  
  2071.    * Specify the remote username in the principal of your AUTHENTICATE Kxxx
  2072.      INITIALIZE command.
  2073.  
  2074. Kermit adjusts the case of the name if and only if a case insensitive
  2075. comparison of the SET LOGIN USERID name and the name in the authentication
  2076. ticket shows no differences.
  2077.  
  2078.   ------------------------------------------------------------------------
  2079.  
  2080. 11. VARIABLES
  2081.  
  2082. 11.1. General Authentication Variables
  2083.  
  2084. \v(authname)
  2085.      Only valid when Kermit is accepting a connection. This variable
  2086.      contains the name of the user that has been authenticated as opposed
  2087.      to \v(userid) which contains the name the user chose to login as. This
  2088.      distinction is important for \v(authstate) = "user" since this means
  2089.      that although we were able to authenticate the user as \v(authname) we
  2090.      could not verify that she has authorization to access the account of
  2091.      \v(userid).
  2092.  
  2093. \v(authstate)
  2094.      String indicating current state of authentication:
  2095.  
  2096.      "rejected" - Rejected or otherwise not authenticated
  2097.      "unknown"  - Anonymous connection
  2098.      "other"    - We know him, but not his name
  2099.      "user"     - We know his name
  2100.      "valid"    - We know him, and he needs no password
  2101.  
  2102. \v(authtype)
  2103.      String indicating which telnet (or other) authentication method is in
  2104.      use.
  2105.  
  2106.      "NULL"              - No authentication
  2107.      "KERBEROS_V4"       - Kerberos 4
  2108.      "KERBEROS_V5"       - Kerberos 5
  2109.      "SRP"               - Secure Remote Password
  2110.      "NTLM"              - NT Lan Manager
  2111.      "X_509_CERTIFICATE" - X.509 certificate
  2112.  
  2113. 11.2. Kerberos Variables
  2114.  
  2115. \v(krb5cc)
  2116.      Current kerberos V credentials cache.
  2117. \v(krb5princ)
  2118.      Current kerberos V principal name.
  2119. \v(krb5realm)
  2120.      Current kerberos V realm name.
  2121. \v(krb5errno)
  2122.      Last Kerberos V errno
  2123. \v(krb5errmsg)
  2124.      Last Kerberos V error message
  2125. \v(krb4princ)
  2126.      Current kerberos IV principal name.
  2127. \v(krb4realm)
  2128.      Current kerberos IV realm name.
  2129. \v(krb4errno)
  2130.      Last Kerberos IV errno
  2131. \v(krb4errmsg)
  2132.      Last Kerberos IV error message
  2133.  
  2134. 11.3. SSL/TLS Variables
  2135.  
  2136. \v(x509_issuer)
  2137.      The issuer string from the peer's X.509 certificate
  2138. \v(x509_subject)
  2139.      The subject string from the peer's X.509 certificate
  2140.  
  2141.   ------------------------------------------------------------------------
  2142.  
  2143. 12. FUNCTIONS
  2144.  
  2145. All Kerberos functions require the Kerberos version number, 4 or 5, as the
  2146. first argument (n).
  2147.  
  2148. \fkrbtickets(n)
  2149.      The number of active Kerberos n (4 or 5) tickets. This resets the
  2150.      ticket list used by \fkrbnextticket(n).
  2151.  
  2152. \fkrbnextticket(n)
  2153.      The next ticket in the Kerberos n (4 or 5) ticket list that was set up
  2154.      by the most recent invocation of \fkrbtickets(n).
  2155.  
  2156. \fkrbisvalid(n,name)
  2157.      The name is a ticket name, as returned by \fkrbnextticket(n). Returns
  2158.      1 if the ticket is valid, 0 if not valid. A ticket is valid if all the
  2159.      following conditions are true:
  2160.  
  2161.        1. it exists in the current cache file;
  2162.        2. it is not expired;
  2163.        3. it is not marked invalid (K5 only);
  2164.        4. it was issued from the current IP address
  2165.  
  2166.      This value can be used in an IF statement, e.g.:
  2167.  
  2168.          if \fkrbisvalid(4,krbtgt.FOO.BAR.EDU@FOO.BAR.EDU) ...
  2169.  
  2170. \fkrbtimeleft(n,name)
  2171.      The name is a ticket name, as returned by \fkrbnextticket(n). Returns
  2172.      the number of seconds remaining in the ticket's lifetime.
  2173.  
  2174. \fkrbflags(n,name)
  2175.      The name is a ticket name, as returned by \fkrbnextticket(n). Returns
  2176.      the flags string as reported with AUTH K5 LIST /FLAGS. This string can
  2177.      be searched for a particular flag using the \findex() function when
  2178.      SET CASE is ON (for case sensitive searches). Flag strings are only
  2179.      available for K5 tickets.
  2180.  
  2181. Kerberos 5 functions operate against the current credential-cache file as
  2182. set by SET AUTHORIZATION K5 CREDENTIALS-FILE filename.
  2183.  
  2184.   ------------------------------------------------------------------------
  2185.  
  2186. 13. SCRIPTING HINTS
  2187.  
  2188. 13.1. Kerberos Autoget
  2189.  
  2190. When developing scripts to be used without user interaction you should turn
  2191. off the Kerberos AutoGet TGT feature with
  2192.  
  2193.   SET AUTHENTICATION KERBEROS4 AUTOGET OFF
  2194.   SET AUTHENTICATION KERBEROS5 AUTOGET OFF
  2195.  
  2196. When autoget mode is disabled, Kermit does not automatically perform the
  2197. function of KINIT. Instead this automation can be scripted; for example:
  2198.  
  2199.   SET TELOPT AUTHENTICATION REQUIRED
  2200.   SET HOST host:port /TELNET
  2201.   IF FAILURE {
  2202.       AUTHENTICATE K4 INIT ; (or K5)
  2203.       SET HOST host:port
  2204.       IF FAILURE { do whatever on failure }
  2205.   }
  2206.  
  2207. or place the following in your K95CUSTOM.INI file to insure a valid Ticket
  2208. Granting Ticket each time you start K95:
  2209.  
  2210.   IF AVAILABLE KERBEROS4 {
  2211.     IF NOT \Fkrbisvalid(4,krbtgt.\v(krb4realm)@\v(krb4realm)) {
  2212.       echo Kerberos 4 Ticket Granting Ticket is invalid!
  2213.       AUTH K4 INIT
  2214.     }
  2215.   }
  2216.  
  2217.   IF AVAILABLE KERBEROS5 {
  2218.     IF NOT \Fkrbisvalid(5,krbtgt/\v(krb5realm)@\v(krb5realm)) {
  2219.       echo Kerberos 5 Ticket Granting Ticket is invalid!
  2220.       AUTH K5 INIT
  2221.     }
  2222.   }
  2223.  
  2224. 13.2. Autodestruction of Kerberos Credentials
  2225.  
  2226. When Kermit is used on a machine in a public lab and Kerberos is used for
  2227. authentication it is often desireable to not have the Kerberos credentials
  2228. survive the current session.
  2229.  
  2230. SET AUTH { K4, K5} AUTODESTROY { ON-CLOSE, ON-EXIT }
  2231.      Automates the destruction of Kerberos credentials under the specified
  2232.      condition.
  2233.  
  2234. 13.3. Automated prompting for usernames
  2235.  
  2236. To prevent Kermit from using the username reported by the local operating
  2237. system for the remote userid and kerberos principal use:
  2238.  
  2239.   SET LOGIN USERID {}
  2240.   SET AUTHENTICATION KERBEROS4 PRINCIPAL {}
  2241.   SET AUTHENTICATION KERBEROS5 PRINCIPAL {}
  2242.  
  2243. This forces Kermit to prompt the user for the userid and principal when
  2244. requesting credentials.
  2245.  
  2246. 13.4. Password Inclusion in Script Files
  2247.  
  2248. Although it is not recommended (since storing passwords openly in a file,
  2249. especially on a PC, is a serious security risk), connections may be
  2250. scripted without user interaction:
  2251.  
  2252.   SET HOST /PASSWORD:password /USERID:user host port /TELNET
  2253.  
  2254. The security risk can be avoided if the script prompts for the password:
  2255.  
  2256.   ASKQ \%p Password:
  2257.   SET HOST PASSWORD:\%p /USERID:user host port /TELNET
  2258.   UNDEF \%p
  2259.  
  2260. Of course, if the /PASSWORD switch is not specified Kermit prompts for the
  2261. password automatically when the host requests the use of authentication.
  2262.  
  2263. 13.5. Using Kermit Scripts to Produce Secure Telnet Services
  2264.  
  2265. The following series of commands causes a Kermit script to accept only
  2266. authenticated and encrypted connections:
  2267.  
  2268.   SET TELOPT /SERVER AUTH REQUIRE
  2269.   SET TELOPT /SERVER ENCRYPT REQUIRE REQUIRE
  2270.   SET HOST * port /TELNET
  2271.   IF FAILURE { do appropriate error handling }
  2272.  
  2273. The \v(authstate) variable tells the script which level of authentication
  2274. has been achieved. If the value is "valid" that means that the account
  2275. specified by \v(userid) has been authenticated and authorized for use by
  2276. \v(authname). If the value of \v(authstate) is "user" then \v(authname) has
  2277. been authenticated but she does not have known authorization to access the
  2278. account \v(userid). This usually means that some additional verification is
  2279. needed.
  2280.  
  2281.   IF EQ "\v(authstate)" "valid" {
  2282.     proceed without further authorization
  2283.   }
  2284.   IF EQ "\v(authstate)" "user" {
  2285.     perform further authorization before providing service
  2286.   }
  2287.  
  2288. It is important to realize that when a Kermit script is used in this
  2289. manner, the Telnet negotiations provide authentication of the user and
  2290. potentially encryption of the data communication. There is no facility in a
  2291. Kermit script to change the ownership of the currently running process from
  2292. the user that started it to the user ID of the authenticated user. This
  2293. means that the script the authenticated user is accessing has all of the
  2294. privileges of the process executer and not the authenticated user.
  2295.  
  2296. Another important fact to remember is that secure access to an insecure
  2297. environment is not secure. If you are using Windows 95 or 98 to run
  2298. scripts, while it is possible to use Kerberos or SRP to authenticate the
  2299. incoming clients, the insecure nature of the Windows environment means that
  2300. it is impossible for the Kerberos service key tables and SRP password
  2301. databases to be protected from tampering; the security in this case is no
  2302. stronger than than the security of Windows 9x.
  2303.  
  2304.   ------------------------------------------------------------------------
  2305.  
  2306. 14. USING OTHER SECURITY METHODS WITH KERMIT
  2307.  
  2308. Other protocols can be used to create secure connections that are not
  2309. currently implemented in Kermit, such as Secure Shell (SSH). The fact that
  2310. SSH is not integrated into Kermit software does not mean that Kermit cannot
  2311. be used in conjunction with it. SSH provides for tunneling, which allows a
  2312. localhost proxy to be configured to take insecure connections on the local
  2313. machine and connect them via secure connections to remote hosts.
  2314.  
  2315. Secure connection clients can be used as the communication channel in
  2316. C-Kermit 7.0 and Kermit 95 1.1.16 via the PTY (Unix only) and PIPE
  2317. commands. See Section 2.7 of the C-Kermit 7.0 Update Notes for details.
  2318.  
  2319. Firewalls based on access lists, proxies, and SOCKS do not provide secure
  2320. connections. However, they do restrict the ports that may be used to
  2321. communicate between the Internet and the Intranet which makes it more
  2322. difficult for someone to break into the Intranet from outside. They do not
  2323. protect the network from internal attacks nor do they protect a connection,
  2324. once made, from eavesdropping or hijacking. They may be used in conjunction
  2325. with secure connection systems but should not be used as a replacement for
  2326. them. (The Windows 95 and NT versions of Kermit 95 do not support SOCKS;
  2327. the OS/2 version has built-in support for SOCKS4. C-Kermit can be built as
  2328. a SOCKS client if you have a SOCKS library; otherwise you can run
  2329. SOCKSified Telnet or Rlogin clients through C-Kermit with the PIPE
  2330. command.)
  2331.  
  2332. NEC distributes a SOCKS5 Winsock shim for Windows 9x/NT at:
  2333.  
  2334.   ftp://ftp.nec.co.jp/pub/packages/sotools/
  2335.  
  2336. 14.1. Implementing Other Security Methods for Kermit 95
  2337.  
  2338. Kermit 95 provides an interface that allows it to use a DLL to provide an
  2339. alternative mechanism for implementing secure communication methods. The
  2340. DLL is loaded via a network type command:
  2341.  
  2342.   SET NETWORK TYPE DLL dll-file
  2343.  
  2344. The connection is then made with a SET HOST command
  2345.  
  2346.   SET HOST command-line
  2347.  
  2348. where the command-line is passed to the DLL after the normal Kermit quoting
  2349. rules are applied.
  2350.  
  2351. /* Kermit 95 - External Network DLL specification
  2352.  * July 16 1998
  2353.  * Jeffrey Altman <jaltman@columbia.edu>
  2354.  *
  2355.  * The following specification defines a set of functions to be exported from
  2356.  * a DLL in order for the DLL to work with Kermit 95 version 1.1.17 or higher.
  2357.  *
  2358.  * The DLL is loaded by Kermit 95 via use of the command:
  2359.  *   SET NETWORK TYPE DLL dllname
  2360.  *
  2361.  * Notes:
  2362.  *   The functions specified here must be thread safe.  It is possible
  2363.  *   for multiple threads to be calling any combination of functions
  2364.  *   simultaneously.
  2365.  *
  2366.  *   The 1.1.17 interface does not provide for the ability of the
  2367.  *   DLL to query the user with echoing input, nor is the a method
  2368.  *   for querying the values of Kermit variables such as 'userid'
  2369.  *   or Kermit version number.  This will be added in a later release.
  2370.  */
  2371.  
  2372. /*
  2373.  * N E T O P E N - Network Open
  2374.  *
  2375.  * The network open function is called by Kermit 95 when a new connection
  2376.  * is desired.  Usually in response to:
  2377.  *    SET HOST command_line
  2378.  *
  2379.  * Parameters:
  2380.  *   command_line - the command line specified in the SET HOST command
  2381.  *                  after quoting rules and variables have been applied.
  2382.  *   termtype     - a string representing either the currently selected
  2383.  *                  terminal type or a user specified string as per
  2384.  *                  SET TELNET TERMINAL string
  2385.  *   height       - initial height of the terminal window (chars)
  2386.  *   width        - initial width of the terminal window (chars)
  2387.  *   readpass     - a pointer to a function to be used to read a password
  2388.  *                  without echoing
  2389.  *
  2390.  * Return values:
  2391.  *   0   on success
  2392.  *   < 0 on failure
  2393.  *
  2394.  *   return codes should be defined such that they can be passed to
  2395.  *   errorstr() to retrieve an appropriate error message for the user.
  2396.  */
  2397.  
  2398. int
  2399. netopen(char * command_line, char * termtype, int height, int width,
  2400.         int (* readpass)(char * prompt,char * buffer, int length));
  2401. /*
  2402.  * N E T C L O S - Network Close
  2403.  *
  2404.  * The network close function is called by Kermit 95 when the user requests
  2405.  * a disconnect or in response to fatal error.
  2406.  *
  2407.  * Parameters: None
  2408.  *
  2409.  * Return values:
  2410.  *   0   on success
  2411.  *   < 0 on failure
  2412.  *
  2413.  *   return codes should be defined such that they can be passed to
  2414.  *   errorstr() to retrieve an appropriate error message for the user.
  2415.  */
  2416.  
  2417. int
  2418. netclos(void) ;
  2419.  
  2420. /*
  2421.  * N E T T C H K - Network Terminal I/O Check
  2422.  *
  2423.  * The network terminal i/o check function is called regularly by Kermit 95
  2424.  * to poll the status of the connection and to retrieve the number of input
  2425.  * characters waiting to be processed.  Because it is called frequently this
  2426.  * function should be designed to be low cost.
  2427.  *
  2428.  * Parameters: None
  2429.  *
  2430.  * Return values:
  2431.  *   >= 0 number of characters waiting in the input queue
  2432.  *   < 0  indicates a fatal error on the connection and the connection
  2433.  *        should be closed.
  2434.  *
  2435.  *   return codes should be defined such that they can be passed to
  2436.  *   errorstr() to retrieve an appropriate error message for the user.
  2437.  */
  2438.  
  2439. int
  2440. nettchk(void);
  2441.  
  2442. /*
  2443.  * N E T F L U I - Network Flush Input
  2444.  *
  2445.  * The network flush input function should clear the connection's input
  2446.  * queue.
  2447.  *
  2448.  * Parameters: None
  2449.  *
  2450.  * Return values:
  2451.  *   0    indicates success
  2452.  *   < 0  indicates an error
  2453.  *
  2454.  *   return codes should be defined such that they can be passed to
  2455.  *   errorstr() to retrieve an appropriate error message for the user.
  2456.  */
  2457.  
  2458. int
  2459. netflui(void);
  2460.  
  2461. /*
  2462.  * N E T B R E A K - Network Break
  2463.  *
  2464.  * The network break signal is called in response to a user initiated
  2465.  * break command.  For example, on a serial device this should result in
  2466.  * a Break signal and on a Telnet connection a Break Command is sent.
  2467.  * For connection types without an equivalent simply return 0.
  2468.  *
  2469.  * Parameters: None
  2470.  *
  2471.  * Return values:
  2472.  *   0    indicates success
  2473.  *   < 0  indicates an error
  2474.  *
  2475.  *   return codes should be defined such that they can be passed to
  2476.  *   errorstr() to retrieve an appropriate error message for the user.
  2477.  */
  2478.  
  2479. int
  2480. netbreak(void);
  2481.  
  2482. /*
  2483.  * N E T I N C - Network Input Character
  2484.  *
  2485.  * The network input character is used to read the next character from
  2486.  * the input queue.
  2487.  *
  2488.  * Parameters:
  2489.  *   timeout - 0   indicates no timeout, block until the next character
  2490.  *                 is available;
  2491.  *             > 0 indicates a timeout value in seconds;
  2492.  *             < 0 indicates a timeout value in milliseconds;
  2493.  *
  2494.  * Return values:
  2495.  *   >= 0 is interpreted as a valid character
  2496.  *   -1   is a timeout [errorstr() is not called]
  2497.  *   < -1 is a fatal error
  2498.  *
  2499.  *   return codes < -1 should be defined such that they can be passed to
  2500.  *   errorstr() to retrieve an appropriate error message for the user.
  2501.  */
  2502.  
  2503. int
  2504. netinc(int timeout);
  2505.  
  2506. /*
  2507.  * N E T X I N - Network Extended Input
  2508.  *
  2509.  * The network extended input is called to read a large number of waiting
  2510.  * input characters.  It will never be called with a number larger than
  2511.  * reported as available and waiting by nettchk().  The function may return
  2512.  * fewer characters than is requested.  This function should not block.
  2513.  *
  2514.  * Parameters:
  2515.  *   count  - number of characters to be read
  2516.  *   buffer - buffer of length count to be used to store the data
  2517.  *
  2518.  * Return values:
  2519.  *   >= 0  the number of characters actually returned by the function
  2520.  *   < 0  indicates an error
  2521.  *
  2522.  *   return codes should be defined such that they can be passed to
  2523.  *   errorstr() to retrieve an appropriate error message for the user.
  2524.  */
  2525.  
  2526. int
  2527. netxin(int count, char * buffer);
  2528.  
  2529. /*
  2530.  * N E T T O C - Network Terminal Output Character
  2531.  *
  2532.  * The network terminal output character transmits a single character
  2533.  *
  2534.  * Parameters:
  2535.  *   c - a single character to be output
  2536.  *
  2537.  * Return values:
  2538.  *   0    indicates success
  2539.  *   < 0  indicates an error
  2540.  *
  2541.  *   return codes should be defined such that they can be passed to
  2542.  *   errorstr() to retrieve an appropriate error message for the user.
  2543.  */
  2544.  
  2545. int
  2546. nettoc(int c);
  2547.  
  2548. /*
  2549.  * N E T T O L - Network Terminal Output Line
  2550.  *
  2551.  * The network terminal output line is used to output one or more
  2552.  * characters.
  2553.  *
  2554.  * Parameters:
  2555.  *   buffer - contains the characters to be output
  2556.  *   count  - the number of characters to be output from buffer
  2557.  *
  2558.  * Return values:
  2559.  *   >= 0 the number of characters actually output.  The function
  2560.  *        should make its best attempt to transmit all 'count'
  2561.  *        characters.
  2562.  *   < 0  indicates a fatal error
  2563.  *
  2564.  *   return codes should be defined such that they can be passed to
  2565.  *   errorstr() to retrieve an appropriate error message for the user.
  2566.  */
  2567.  
  2568. int
  2569. nettol(char * buffer, int count);
  2570.  
  2571. /*
  2572.  * T T V T - Terminal to Virtual Terminal Mode
  2573.  *
  2574.  * Terminal to Virtual Terminal Mode is called to notify the DLL that
  2575.  * Kermit 95 is about to enter terminal mode communications.  This means
  2576.  * either the CONNECT or DIAL commands will be sending output.  In most
  2577.  * cases, this will be either printable text or escape sequences.
  2578.  *
  2579.  * Parameters: None
  2580.  *
  2581.  * Return values:
  2582.  *   0    indicates success
  2583.  *   < 0  indicates an error
  2584.  *
  2585.  *   return codes should be defined such that they can be passed to
  2586.  *   errorstr() to retrieve an appropriate error message for the user.
  2587.  */
  2588.  
  2589. int
  2590. ttvt(void);
  2591.  
  2592. /*
  2593.  * T T P K T - Terminal to Packet Mode
  2594.  *
  2595.  * Terminal to Packet Mode is called to notify the DLL that
  2596.  * Kermit 95 is about to enter file transfer operations.
  2597.  *
  2598.  * Parameters: None
  2599.  *
  2600.  * Return values:
  2601.  *   0    indicates success
  2602.  *   < 0  indicates an error
  2603.  *
  2604.  *   return codes should be defined such that they can be passed to
  2605.  *   errorstr() to retrieve an appropriate error message for the user.
  2606.  */
  2607.  
  2608. int
  2609. ttpkt(void);
  2610.  
  2611. /*
  2612.  * T T R E S - Terminal Restore Mode
  2613.  *
  2614.  * Terminal Restore Mode is called to notify the DLL that it should
  2615.  * Kermit 95 restore to default settings.
  2616.  *
  2617.  * Parameters: None
  2618.  *
  2619.  * Return values:
  2620.  *   0    indicates success
  2621.  *   < 0  indicates an error
  2622.  *
  2623.  *   return codes should be defined such that they can be passed to
  2624.  *   errorstr() to retrieve an appropriate error message for the user.
  2625.  */
  2626.  
  2627. int
  2628. ttres(void);
  2629.  
  2630. /*
  2631.  * T E R M I N F O - Terminal Information
  2632.  *
  2633.  * The terminal information function is called whenever the terminal
  2634.  * type or window size is changed.
  2635.  *
  2636.  * Parameters:
  2637.  *   termtype     - a string representing either the currently selected
  2638.  *                  terminal type or a user specified string as per
  2639.  *                  SET TELNET TERMINAL string
  2640.  *   height       - initial height of the terminal window (chars)
  2641.  *   width        - initial width of the terminal window (chars)
  2642.  *
  2643.  * Return values: None
  2644.  */
  2645.  
  2646. void
  2647. terminfo(char * termtype, int height, int width);
  2648.  
  2649. /*
  2650.  * V E R S I O N - Version String
  2651.  *
  2652.  * Version is called to get a user displayable version string for use
  2653.  * as part of the SHOW NETWORK command.
  2654.  *
  2655.  * Parameters: None
  2656.  *
  2657.  * Return values:
  2658.  *   a string which will not be deleted by the caller.
  2659.  */
  2660.  
  2661. const char *
  2662. version(void);
  2663.  
  2664. /*
  2665.  * E R R O R S T R - Error String
  2666.  *
  2667.  * Error string is called to retrieve a user displayable error message
  2668.  * describing the type of error being reported by the function.
  2669.  *
  2670.  * Parameters:
  2671.  *   error - the error value reported by the DLL function.
  2672.  *
  2673.  * Return values:
  2674.  *   a string which will not be deleted by the caller.
  2675.  */
  2676.  
  2677. const char *
  2678. errorstr(int error);
  2679.  
  2680.   ------------------------------------------------------------------------
  2681.  
  2682. 15. AN INTRODUCTION TO CERTIFICATES AND CERTIFICATE AUTHORITIES WITH
  2683. OPENSSL
  2684.  
  2685. This is a brief introduction to certificates, certificate authorities and
  2686. how to use them. The information presented here is highly technical and can
  2687. be skipped unless:
  2688.  
  2689.    * you are a system administrator and want to learn how to secure your
  2690.      host, or
  2691.    * you want to know how to use client certificates to authenticate to a
  2692.      host
  2693.  
  2694. RSA Security, Inc., has a very good Frequently Asked Questions
  2695.  
  2696.   http://www.rsasecurity.com/rsalabs/faq/questions.html
  2697.  
  2698. The FAQ covers many topics related to cryptography as well as how public
  2699. key certificates work and how they are to be used.
  2700.  
  2701. 15.1. What Are Certificates, Private Keys, CSRs, CAs, and CRLs?
  2702.  
  2703. Public key (asymetric) cryptography defines a class of algorithms for key
  2704. exchange that include RSA and Diffie-Hellman (DH). These algorithms provide
  2705. a mechanism to create a shared secret that can be used for encrypting
  2706. future communications. Anyone listening to the exchange would be no closer
  2707. to figuring out the value of the shared secret than if they were to take a
  2708. guess.
  2709.  
  2710. There are two parts to the exchange. A private key that is never disclosed,
  2711. and a public key that may be viewed by all. A X.509 certificate is a
  2712. standard package for distributing a public key with identifying features
  2713. such that the authenticity and validity of the public key may be verified
  2714. by a recipient.
  2715.  
  2716. The authenticity and validity of a certificate is provided by a combination
  2717. of information provided within the certificates (the subject, the issuer,
  2718. dates of validity, ...) as well as the trust that is placed in the
  2719. certificate issuer (the Certificate Authority, or CA). The CA signs each of
  2720. the certificates that it issues with its own certificate. With a copy of
  2721. the CA's certificate it is possible to validate all of the certificates
  2722. that were signed by the CA's private key.
  2723.  
  2724. A user who wants to have a certificate signed by a CA creates a Certificate
  2725. Signing Request (CSR). The CSR is an unsigned certificate which is
  2726. presented to the CA along with information verifying the identity and
  2727. desired use for the certificate. The CA signs the CSR producing a
  2728. certificate that is valid for a specific time frame which is then returned
  2729. to the user.
  2730.  
  2731. If the private key of the certificate were to be compromised the CA may
  2732. revoke the certificate. The CA publishes a Certificate Revocation List
  2733. (CRL) on a periodic basis containing a list of all certificates that would
  2734. otherwise be valid if they were not revoked. It is the responsibility of
  2735. the verifier to check not only the authenticity of the certificate but also
  2736. whether or not it has been revoked by the issuer.
  2737.  
  2738. 15.2. RSA certificates vs. DSA Certificates
  2739.  
  2740. The important differences between RSA and DSA certificates are:
  2741.  
  2742.    * The RSA algorithms are faster than DSA.
  2743.  
  2744.    * The RSA algorithms are supported by all the major browsers whereas DSA
  2745.      are not.
  2746.  
  2747.    * The RSA algorithms are patented in the United States (until Sept 29,
  2748.      2000) which requires payments of licensing fees for producers of
  2749.      software utilizing them, whereas DSA is free.
  2750.  
  2751.    * The RSA private and public key pairs may be used for encrypting data
  2752.      as well as signing. DSA private and public key pairs may only be used
  2753.      for signing. Therefore, products incorporating DSA algorithms are
  2754.      easier to export from the United States.
  2755.  
  2756. Due to the patent issues surrounding the RSA algorithms, the Kermit Project
  2757. does not maintain a library or distribute any binaries that are built with
  2758. the RSA algorithms. This policy can change when the RSA patent expires.
  2759.  
  2760. 15.3. Should You Be Your Own Certificate Authority?
  2761.  
  2762. There are many companies that believe that providing CA services is big
  2763. business. These include but are not limited to:
  2764.  
  2765.    * Verisign
  2766.    * Thawte Consulting
  2767.    * CertiSign Cerificadora Digital Ltda.
  2768.    * IKS GmbH
  2769.    * Uptime Commerce Ltd.
  2770.    * BelSign NV/SA
  2771.  
  2772. The root CA certificates of these companies certificates are included most
  2773. of the popular browsers. This provides an ease-of-use advantage to the
  2774. recipients of certificates they sign since the root certificates do not
  2775. need to be otherwise distributed in order to authenticate the signed
  2776. certificates.
  2777.  
  2778. On the other hand, as is pointed out by C. Ellison and B. Schneier in their
  2779. paper, Ten Risks of PKI: What You're Not Being Told About Public Key
  2780. Infrastructure:
  2781.  
  2782.   http://www.counterpane.com/pki-risks.html
  2783.  
  2784. using the commercial CA services it makes it difficult to decide whether or
  2785. not a certificate should be trusted for a particular purpose, especially if
  2786. you want to use certificates to authenticate an end user to a system for
  2787. remote access. In this situation it is necessary to not only be able to
  2788. authenticate a certificate but be able to know that the information within
  2789. the certificate, such as the uniqueIdentifier used for the User ID, is
  2790. tightly controlled and in fact unique in your environment.
  2791.  
  2792. If you choose to be your own CA you will need to configure your
  2793. environment. Create the following directory trees to store the DSA and RSA
  2794. CAs.
  2795.  
  2796.    openssl/dsaCA/certs/
  2797.    openssl/dsaCA/crl/
  2798.    openssl/dsaCA/private/
  2799.    openssl/dsaCA/newcerts/
  2800.    openssl/dsaCA/requests/
  2801.    openssl/rsaCA/certs/
  2802.    openssl/rsaCA/crl/
  2803.    openssl/rsaCA/private/
  2804.    openssl/rsaCA/newcerts/
  2805.    openssl/rsaCA/requests/
  2806.  
  2807. Place the openssl.cnf file into the openssl directory. Edit it to meet the
  2808. requirements of your organization. Create two sections, [ CA_DSA ] and [
  2809. CA_RSA ]:
  2810.  
  2811.   [ CA_DSA ]
  2812.  
  2813.   dir             = openssl_path/dsaCA/    # Where everything is kept
  2814.   certs           = $dir/certs             # Where the issued certs are kept
  2815.   crl_dir         = $dir/crl               # Where the issued crl are kept
  2816.   database        = $dir/index.txt         # database index file.
  2817.   new_certs_dir   = $dir/newcerts          # default place for new certs.
  2818.  
  2819.   certificate     = $dir/certs/cacert.pem  # The CA certificate
  2820.   serial          = $dir/ca.srl            # The current serial number
  2821.   crl             = $dir/crl.pem           # The current CRL
  2822.   private_key     = $dir/private/cakey.pem # The private key
  2823.   RANDFILE        = $dir/private/.rand     # private random number file
  2824.  
  2825.   x509_extensions = x509v3_extensions      # The extentions to add to the cert
  2826.   default_days    = 365                    # how long to certify for
  2827.   default_crl_days= 30                     # how long before next CRL
  2828.   default_md      = sha1                   # which md to use.
  2829.   preserve        = no                     # keep passed DN ordering
  2830.  
  2831.   [ CA_RSA ]
  2832.  
  2833.   dir             = openssl_path/rsaCA/    # Where everything is kept
  2834.   certs           = $dir/certs             # Where the issued certs are kept
  2835.   crl_dir         = $dir/crl               # Where the issued crl are kept
  2836.   database        = $dir/index.txt         # database index file.
  2837.   new_certs_dir   = $dir/newcerts          # default place for new certs.
  2838.  
  2839.   certificate     = $dir/certs/cacert.pem  # The CA certificate
  2840.   serial          = $dir/ca.srl            # The current serial number
  2841.   crl             = $dir/crl.pem           # The current CRL
  2842.   private_key     = $dir/private/cakey.pem # The private key
  2843.   RANDFILE        = $dir/private/.rand     # private random number file
  2844.  
  2845.   x509_extensions = x509v3_extensions      # The extentions to add to the cert
  2846.   default_days    = 365                    # how long to certify for
  2847.   default_crl_days= 30                     # how long before next CRL
  2848.   default_md      = sha1                   # which md to use.
  2849.   preserve        = no                     # keep passed DN ordering
  2850.  
  2851. If you wish to use the uniqueIdentifier field to perform certificate to
  2852. user ID mapping, add it after the emailAddress field.
  2853.  
  2854. If you wish to use the subjectAltName field to perform certificate to user
  2855. ID mapping, you will need to add a [ x509v3_externsions ] section:
  2856.  
  2857.   [ x509v3_extensions ]
  2858.  
  2859.   subjectAltName                  = email:copy
  2860.  
  2861. Other formats of the subjectAltName field are:
  2862.  
  2863.   subjectAltName                 = email:copy
  2864.   subjectAltName                 = issuerl:copy
  2865.   subjectAltName                 = email:fred@company.com
  2866.   subjectAltName                 = DNS:www.company.com
  2867.   subjectAltName                 = IP:100.99.98.97
  2868.   subjectAltName                 = RID:2.99999.1
  2869.  
  2870. Other x509v3 extensions include:
  2871.  
  2872.   nsCaRevocationUrl              = http://www.domain.com/ca-crl.pem
  2873.   nsComment                      = "This is a comment"
  2874.  
  2875. To avoid the need to specify the location of the openssl.cnf file, set the
  2876. environment variable OPENSSL_CNF to be equal to the full path of the file.
  2877. If you do not create this environment variable you will need to include the
  2878. option:
  2879.  
  2880.   -config path/openssl.cnf
  2881.  
  2882. to each openssl command.
  2883.  
  2884. Create the file that stores the next available serial number for each CA:
  2885.  
  2886.    openssl/dsaCA/ca.srl
  2887.    openssl/rsaCA/ca.srl
  2888.  
  2889. The format of this file is a hex value followed by a LF (0x0A) character.
  2890. The value "01" is an appropriate initial value.
  2891.  
  2892. Create an empty file to store the index of signed certificates:
  2893.  
  2894.    openssl/dsaCA/index.txt
  2895.    openssl/rsaCA/index.txt
  2896.  
  2897. Now you are ready to create the DSA and RSA CA certificates for your
  2898. organization.
  2899.  
  2900. 15.4. Generating a DSA CA (self-signed) Certificate
  2901.  
  2902. Change the current working directory to openssl/dsaCA/.
  2903.  
  2904. Generate the DSA parameters to be used when generating the keys for use
  2905. with your certificates:
  2906.  
  2907.   openssl dsaparam 1024 -out dsa1024.pem
  2908.  
  2909. Generate the self-signed certificate you will use as the CA certificate for
  2910. your organization:
  2911.  
  2912.   openssl req -x509 -newkey dsa:dsa1024.pem -days days \
  2913.     -keyout private/cakey.pem -out certs/cacert.pem
  2914.  
  2915. The days parameter should be replaced by the number of days you want this
  2916. certificate to remain valid. All certificates signed by this certificate
  2917. become invalid when this certificate expires.
  2918.  
  2919. Be sure to not forget the pass-phrase you use to protect the private key of
  2920. the CA certificate. If you do not wish to encrypt the CA's private key you
  2921. may specify the -nodes option. But this is highly discouraged.
  2922.  
  2923. You can check the contents of the CA certificate with the command:
  2924.  
  2925.   openssl x509 -text -in certs/cacert.pem
  2926.  
  2927. 15.5. Generating a DSA CSR
  2928.  
  2929. Change the current working directory to openssl/dsaCA/.
  2930.  
  2931. If you have not already created a set of DSA parameters, you must generate
  2932. a set:
  2933.  
  2934.   openssl dsaparam 1024 -out dsa1024.pem
  2935.  
  2936. It is safe to reuse the DSA parameters.
  2937.  
  2938. Generate the DSA certificate request:
  2939.  
  2940.   openssl req -newkey dsa:dsa1024.pem -keyout private/name-key.pem \
  2941.     -out requests/name-req.pem
  2942.  
  2943. name should be replaced by something that identifies the files. Perhaps the
  2944. hostname or userid for which the certificate is being generated.
  2945.  
  2946. If you are generating a CSR for use as a host certificate, be sure to
  2947. specify the fully qualified domain name as reported by the DNS as the
  2948. Common Name for the certificate. Otherwise, it will not be recognized as
  2949. belonging to the host it is installed on by its clients.
  2950.  
  2951. Be sure not to forget the pass-phrase you use to protect the private key of
  2952. the CA certificate. The certificate (after signing) is unusable without it.
  2953. Use the -nodes option if you wish to store the key unencrypted.
  2954.  
  2955. You can check the contents of the CSR with the command:
  2956.  
  2957.   openssl req -text -in requests/name-req.pem
  2958.  
  2959. The CSR now stored in requests/name-req.pem may be sent to one of the
  2960. commerical CAs if you do not wish to be your own CA.
  2961.  
  2962. 15.6. Generating a RSA CA (self-signed) certificate
  2963.  
  2964. Change the current working directory to openssl/rsaCA/.
  2965.  
  2966. Generate the self-signed certificate you will use as the CA certificate for
  2967. your organization:
  2968.  
  2969.   openssl req -x509 -newkey rsa:1024 -days days \
  2970.     -keyout private/cakey.pem -out certs/cacert.pem
  2971.  
  2972. The days parameter should be replaced by the number of days you want this
  2973. certificate to remain valid. All certificates signed by this certificate
  2974. become invalid when this certificate expires.
  2975.  
  2976. Be sure not to forget the pass-phrase you use to protect the private key of
  2977. the CA certificate. If you do not wish to encrypt the CA's private key you
  2978. may specify the -nodes option. But this is highly discouraged.
  2979.  
  2980. You can check the contents of the CA certificate with the command:
  2981.  
  2982.   openssl x509 -text -in certs/cacert.pem
  2983.  
  2984. 15.7. Generating a RSA CSR
  2985.  
  2986. Change the current working directory to openssl/rsaCA/.
  2987.  
  2988.   openssl req -newkey rsa:1024 -keyout private/name-key.pem \
  2989.     -out requests/name-req.pem
  2990.  
  2991. name should be replaced by something that identifies the files. Perhaps the
  2992. hostname or userid for which the certificate is being generated.
  2993.  
  2994. If you are generating a CSR for use as a host certificate be sure to
  2995. specify the fully qualified domain name as reported by the DNS as the
  2996. Common Name for the certificate. Otherwise, it is not recognized as
  2997. belonging to the host it is installed on by its clients.
  2998.  
  2999. Be sure not to forget the pass-phrase you use to protect the private key of
  3000. the CA certificate. The certificate (after signing) is unusable without it.
  3001. Use the -nodes option if you wish to store the key unencrypted.
  3002.  
  3003. You can check the contents of the CSR with the command:
  3004.  
  3005.   openssl req -text -in requests/name-req.pem
  3006.  
  3007. The CSR now stored in requests/name-req.pem may be sent to one of the
  3008. commerical CAs if you do not wish to be your own CA.
  3009.  
  3010. 15.8. Signing a CSR with your CA certificate
  3011.  
  3012. If you are signing a DSA certificate change directory to openssl/dsaCA/ and
  3013. use a caname of "CA_DSA". If you are signing a RSA certificate change
  3014. directory to openssl/rsaCA/ and use a caname of "CA_RSA":
  3015.  
  3016.   openssl ca -name caname -in requests/name-req.pem \
  3017.     -out certs/name.pem -days days
  3018.  
  3019. The days parameter should be replaced by the number of days you want the
  3020. signed certificate to remain valid. If you want to specify a specific date
  3021. range you can replace the -days parameters with:
  3022.  
  3023.  -startdate YYMMDDHHMMSSZ  - certificate validity notBefore
  3024.  -enddate YYMMDDHHMMSSZ    - certificate validity notAfter
  3025.  
  3026. The file certs/name.pem now contains a signed certificate that may be used
  3027. by a host or client for authentication in conjunction with its matching
  3028. private key (private/name-key.pem.)
  3029.  
  3030. An alternative method of signing the CSR is to use the command:
  3031.  
  3032.   openssl x509 -req -in requests/name-req.pem -CA certs/cacert.pem \
  3033.     -CAkey private/cakey.pem -out certs/name.pem -days days \
  3034.     -CAserial ca.srl -CAcreateserial
  3035.  
  3036. The "openssl x509" command provides greater functionality at the expense of
  3037. ease of use. The X509 may be used to assign X.509v3 certificate extensions
  3038. with the -extfile and -extensions switches. It may also be used to produce
  3039. certificates that may only be used for specific purposes.
  3040.  
  3041. You can check the contents of the CA certificate with the command:
  3042.  
  3043.   openssl x509 -text -in certs/name.pem
  3044.  
  3045. 15.9. Revoking a Certificate
  3046.  
  3047. If you are revoking a DSA certificate change directory to openssl/dsaCA/
  3048. and use a caname of "CA_DSA". If you are revoking a RSA certificate change
  3049. directory to openssl/rsaCA/ and use a caname of "CA_RSA".
  3050.  
  3051.   openssl ca -name caname -revoke -in certs/name.pem
  3052.  
  3053. marks the certificate as being revoked in the index.txt file. It is
  3054. necessary to revoke a certificate with a given subject name if you wish to
  3055. generate a new certificate with an identical subject name. Once a
  3056. certificate is revoked it is listed in the next generated CRL.
  3057.  
  3058. 15.10. Generating a CRL
  3059.  
  3060. If you are generating a CRL for your DSA certificates change directory to
  3061. openssl/dsaCA/ and use a caname of "CA_DSA". If you are generating a CRL
  3062. for your RSA certificate change directory to openssl/rsaCA/ and use a
  3063. caname of "CA_RSA":
  3064.  
  3065.   openssl ca -name caname -gencrl -out crl/date-crl.pem
  3066.  
  3067. date should be replaced by the date the crl was generated.
  3068.  
  3069. You can check the contents of the CRL with the command:
  3070.  
  3071.   openssl crl -in crl/date-crl.pem -text
  3072.  
  3073. The current CRL should be placed somewhere it is publicly and easily
  3074. accessible. For instance, by HTTP or FTP. The CRL is signed by the CA
  3075. certificate
  3076.  
  3077. 15.11. Mapping a Client Certificate to a User ID
  3078.  
  3079. Kermit can be configured to perform a mapping from an X.509 client
  3080. certificate to a User ID. This is primarily of use when Kermit is installed
  3081. as an Internet Kermit Service. When a mapping is enabled, the client
  3082. certificate may be used to authenticate and automatically login a user to
  3083. their account or resources.
  3084.  
  3085. Unfortunately, it is not possible to build a function in to Kermit to
  3086. provide the mapping from Certificate to User ID that would be secure and/or
  3087. applicable to every installation. There are several commonly used
  3088. approaches to certificate to user mapping. Kermit can be customized to use
  3089. which ever one you choose to use in your environment.
  3090.  
  3091. Map the X.509 uniqueIdentifier field to the User ID
  3092.      The uniqueIdentifier field of the X.509 client certificate can include
  3093.      the userid of the end user. For instance, John Doe's uniqueIdentifier
  3094.      might be jdoe. A mapping function can extract the contents of this
  3095.      field and return it as the User ID.
  3096.  
  3097.      The problem with this approach is the uniqueIdentifier may not be very
  3098.      unique. Let us assume that you do not want to go through the trouble
  3099.      of managing your own Certificate Authority because it is too much
  3100.      work. So you refer all of your clients to request X.509 certificates
  3101.      from one of the commercial Certificate Authorities. It is possible
  3102.      that another site is doing exactly the same thing and that this other
  3103.      site has a user Jane Doe with User ID jdoe. In this circumstance,
  3104.      simply verifying the certificate against the CA certificate and
  3105.      extracting the uniqueIdentifier will result in a security hole since
  3106.      Jane Doe would be able to gain access to John Doe's account.
  3107.  
  3108. Map the X.509 subjectAltName to the User ID
  3109.      The subjectAltName field of the X.509 client certificate can include
  3110.      the e-mail address of the user instead of simply the userid of the
  3111.      user. In the case of John Doe, his subjectAltName would be
  3112.      jdoe@mydomain.com whereas Jane Doe's subjectAltName would be
  3113.      jdoe@someotherdomain.com. A mapping function using the subjectAltName
  3114.      can extract the contents of the subjectAltName, verify the domain is
  3115.      correct and then return the User ID.
  3116.  
  3117.      This method is safer than the uniqueIdentifier, but it is still
  3118.      placing a lot of trust in the Certificate Authority. If you are not
  3119.      issuing the certificates yourself you will need to trust that the CA
  3120.      has a legitimate method for verifying that the e-mail address belongs
  3121.      to the user for whom the CA is signing a certificate.
  3122.  
  3123. Map the entire certificate to the User ID
  3124.      Instead of trusting the contents of one of the fields within the
  3125.      certificate you can require that your user's submit their certificates
  3126.      for registration prior to use. The mapping function can then lookup
  3127.      the certificate in a local database or an LDAP server to retrieve the
  3128.      User ID. Of the methods described, this is the most secure.
  3129.  
  3130. 15.11.1 Mapping a Client Certificate to a User ID in Kermit 95
  3131.  
  3132. X.509 to User ID mapping functions are implemented in Kermit 95 via the use
  3133. of a user compiled Dynamic Link Library (DLL), X5092UID.DLL. To build this
  3134. DLL you will require a C compiler such as Microsoft's Visual C++ and
  3135. OpenSSL 0.9.4 (or higher) compiled and installed. The DLL will contain a
  3136. single function with the following prototype:
  3137.  
  3138.   /* X509_to_user() returns 0 if valid userid in 'userid', else -1 */
  3139.   int X509_to_user(X509 *peer_cert, char *userid, int len);
  3140.  
  3141. Contact Kermit Support to request additional information.
  3142.  
  3143. 15.11.2 Mapping a Client Certificate to a User ID in C-Kermit
  3144.  
  3145. X.509 to User ID mapping functions are implemented in C-Kermit in one of
  3146. two ways.
  3147.  
  3148.    * If you want to use the uniqueIdentifier field you can specify
  3149.      KFLAGS=-DX509_UID_TO_USER at compile time.
  3150.    * Otherwise, you need to customize the X509_to_user() function in the
  3151.      ck_ssl.c source file to implement your verification method. A template
  3152.      for using the subjectAltName field is provided in the ck_ssl.c file.
  3153.  
  3154.   ------------------------------------------------------------------------
  3155.  
  3156. 16. THE KERMIT SECURE FTP CLIENT FOR MICROSOFT OPERATING SYSTEMS
  3157.  
  3158. The encryption patch to Kermit 95 1.1.20 includes a new version of the
  3159. command line FTP client: KFTP.EXE. This FTP client includes support for
  3160. authenticated and encrypted file transfers using Kerberos 4,
  3161. GSSAPI-Kerberos 5, Secure Remote Password (SRP), Secure Sockets Layer
  3162. (SSL), and Transport Layer Security (TLS).
  3163.  
  3164. 16.1. KFTP command line options
  3165.  
  3166. Usage: kftp.exe [-v] [-d] [-i] [-n] [-g] [-k realm] [-f] [-x] [-u] [-t] [-c
  3167. cipher] [-h hash] [-z
  3168. {debug,ssl,!ssl,nossl,secure,certsok,verify,cert=,key=}] [host]
  3169.  
  3170. [-v]
  3171.      turn on verbose mode
  3172.  
  3173. [-d]
  3174.      turn on socket debugging
  3175.  
  3176. [-i]
  3177.      turn off interactive mode
  3178.  
  3179. [-n]
  3180.      turn off autologin mode
  3181.  
  3182. [-g]
  3183.      turn off glob mode
  3184.  
  3185. [-k realm]
  3186.      specify the realm to be used with Kerberos 4 authentication
  3187.  
  3188. [-f]
  3189.      forward Kerberos 5 credentials to the host when using GSSAPI
  3190.      authentication
  3191.  
  3192. [-x]
  3193.      turn on autoencrypt mode
  3194.  
  3195. [-t]
  3196.      turn on trace mode
  3197.  
  3198. [-c cipher]
  3199.      specify the cipher to be used for encryption with SRP authentication
  3200.  
  3201.          NONE
  3202.          BLOWFISH_ECB
  3203.          BLOWFISH_CBC
  3204.          BLOWFISH_CFB64
  3205.          BLOWFISH_OFB64
  3206.          CAST5_ECB
  3207.          CAST5_CBC
  3208.          CAST5_CFB64
  3209.          CAST5_OFB64
  3210.          DES_ECB
  3211.          DES_CBC
  3212.          DES_CFB64
  3213.          DES_OFB64
  3214.          DES3_ECB
  3215.          DES3_CBC
  3216.          DES3_CFB64
  3217.          DES3_OFB64
  3218.  
  3219. [-h hash]
  3220.      specify the hash to be used for encryption with SRP authentication
  3221.  
  3222.          MD5
  3223.          SHA
  3224.  
  3225. [-z debug]
  3226.      turn on SSL/TLS debug mode
  3227.  
  3228. [-z !ssl] [-z nossl]
  3229.      disable use of SSL
  3230.  
  3231. [-z !tls] [-z notls
  3232.      disable use of TLS
  3233.  
  3234. [-z secure]
  3235.      turn on SSL secure mode
  3236.  
  3237. [-z certsok]
  3238.      accept all certificates without checking validity
  3239.  
  3240. [-z verify=mode]
  3241.      set certificate verify mode to 0 (no verification), 1 (verify
  3242.      certificate if presented), or 2 (require verification of certificate)
  3243.  
  3244. [-z cert=cert-file]
  3245.      specify a file containing a client certificate to be presented to the
  3246.      FTP server
  3247.  
  3248. [-z key=key-file]
  3249.      specify a file containing a private key matching the client
  3250.      certificate
  3251.  
  3252. [-z !krb4] [-z nokrb4]
  3253.      disable use of Kerberos 4
  3254.  
  3255. [-z !gss] [-z nogss]
  3256.      disable use of GSSAPI - Kerberos 5
  3257.  
  3258. [-z !srp] [-z nosrp]
  3259.      disable use of SRP
  3260.  
  3261. [host]
  3262.      a host to open a connection to
  3263.  
  3264. 16.2. KFTP commands
  3265.  
  3266. !
  3267.      escape to the shell
  3268.  
  3269. $
  3270.      execute macro
  3271.  
  3272. account
  3273.      send account command to remote server
  3274.  
  3275. append
  3276.      append to a file
  3277.  
  3278. ascii
  3279.      set ascii transfer type
  3280.  
  3281. autoauth
  3282.      toggle autoauth mode
  3283.  
  3284. autoencrypt
  3285.      toggle autoencrypt mode
  3286.  
  3287. bell
  3288.      beep when command completed
  3289.  
  3290. binary
  3291.      set binary transfer type
  3292.  
  3293. bye
  3294.      terminate ftp session and exit
  3295.  
  3296. case
  3297.      toggle mget upper/lower case id mapping
  3298.  
  3299. ccc
  3300.      set clear protection level for commands
  3301.  
  3302. cd
  3303.      change remote working directory
  3304.  
  3305. cdup
  3306.      change remote working directory to parent
  3307.  
  3308. chmod
  3309.      change file permissions of remote file
  3310.  
  3311. clear
  3312.      set clear protection level for file transfers
  3313.  
  3314. close
  3315.      terminate ftp session
  3316.  
  3317. cprotect
  3318.      set protection level for commands
  3319.  
  3320. cr
  3321.      toggle carriage return stripping on ascii gets
  3322.  
  3323. delete
  3324.      delete remote file
  3325.  
  3326. debug
  3327.      toggle debug mode
  3328.  
  3329. dir
  3330.      list contents of remote directory
  3331.  
  3332. disconnect
  3333.      terminate ftp session
  3334.  
  3335. form
  3336.      set file transfer format
  3337.  
  3338. forward
  3339.      toggle forwarding of credentials during authentication
  3340.  
  3341. get
  3342.      receive file
  3343.  
  3344. glob
  3345.      toggle metacharacter expansion of local file names
  3346.  
  3347. hash
  3348.      toggle printing of '#' for each buffer transfered
  3349.  
  3350. help
  3351.      print local help information
  3352.  
  3353. idle
  3354.      get (set) idle timer on remote side
  3355.  
  3356. image
  3357.      set binary transfer type
  3358.  
  3359. lcd
  3360.      change local working directory
  3361.  
  3362. ls
  3363.      list contents of remote directory
  3364.  
  3365. macdef
  3366.      define a macro
  3367.  
  3368. mdelete
  3369.      delete multiple files
  3370.  
  3371. mdir
  3372.      list contents of multiple remote directories
  3373.  
  3374. mget
  3375.      receive multiple files
  3376.  
  3377. mkdir
  3378.      make directory on the remote machine
  3379.  
  3380. mls
  3381.      list contents of multiple remote directories
  3382.  
  3383. mode
  3384.      set file transfer mode
  3385.  
  3386. modtime
  3387.      show last modification time of remote file
  3388.  
  3389. mput
  3390.      send multiple files
  3391.  
  3392. newer
  3393.      get file if remote file is newer than local file
  3394.  
  3395. nmap
  3396.      set templates for default file name mapping
  3397.  
  3398. nlist
  3399.      nlist contents of remote directory
  3400.  
  3401. ntrans
  3402.      set translation table for default file name mapping
  3403.  
  3404. open
  3405.      connect to remote ftp
  3406.  
  3407. passive
  3408.      toggle passive transfer mode
  3409.  
  3410. private
  3411.      set private protection level for file transfer
  3412.  
  3413. prompt
  3414.      force interactive prompting on multiple commands
  3415.  
  3416. protect
  3417.      set protection level for file transfer
  3418.  
  3419. proxy
  3420.      issue command on alternate connection
  3421.  
  3422. sendport
  3423.      toggle use of PORT command for each data connection
  3424.  
  3425. put
  3426.      send one file
  3427.  
  3428. pwd
  3429.      print working directory on the remote machine
  3430.  
  3431. quit
  3432.      terminate ftp session and exit
  3433.  
  3434. quote
  3435.      send arbitrary ftp command
  3436.  
  3437. recv
  3438.      receive file
  3439.  
  3440. reget
  3441.      get file restarting at end of local file
  3442.  
  3443. rstatus
  3444.      show status of remote machine
  3445.  
  3446. rhelp
  3447.      get help from remote machine
  3448.  
  3449. rename
  3450.      rename file on remote machine
  3451.  
  3452. reset
  3453.      clear queued command replies
  3454.  
  3455. restart
  3456.      restart file transfer at bytecount
  3457.  
  3458. rmdir
  3459.      remote directory on the remote machine
  3460.  
  3461. runique
  3462.      toggle store unique for local files
  3463.  
  3464. safe
  3465.      set safe protection level for file transfer
  3466.  
  3467. send
  3468.      send one file
  3469.  
  3470. site
  3471.      send site specific command to remote server
  3472.  
  3473. size
  3474.      show size of remote file
  3475.  
  3476. status
  3477.      show current status
  3478.  
  3479. struct
  3480.      set file transfer structure
  3481.  
  3482. system
  3483.      show remote system type
  3484.  
  3485. sunique
  3486.      toggle store unique on remote machine
  3487.  
  3488. tenex
  3489.      set tenex file transfer type
  3490.  
  3491. type
  3492.      set file transfer type
  3493.  
  3494. user
  3495.      send new user information
  3496.  
  3497. umask
  3498.      get (set) umask on remote site
  3499.  
  3500. verbose
  3501.      toggle verbose mode
  3502.  
  3503. version
  3504.      display version information
  3505.  
  3506. ?
  3507.      print local help information
  3508.  
  3509. [Top][C-Kermit 7.0][Update Notes][Kermit Home]
  3510.   ------------------------------------------------------------------------
  3511. Kermit Security / Columbia University / kermit@columbia.edu / 31 March 2000
  3512.