Columbia Kermit/kermit.zip/c-kermit/security.txt

Text File | 2020-01-01 | 246KB | 5,362 lines

                           Kermit Security Reference

   Authors:
          Jeffrey Altman, Frank da Cruz
          [1]The Kermit Project, [2]Columbia University

   Applies to:
          [3]C-Kermit 8.0.200, 12 Dec 2001
          [4]Kermit 95 2.00 (not available yet).
          [5]An earlier version of this document covers [6]C-Kermit 7.0
          and [7]K95 1.1.17-20.

   Abstract:
          Security methods explained: Kerberos, SSL/TLS, SRP, SSH. How to
          configure and use them with C-Kermit and Kermit 95.

   This page last updated:
          12 December 2001

   [ [8]Kermit Home ] [ [9]C-Kermit ] [ [10]Kermit 95 ]
    ________________________________________________________________________

  CONTENTS

   1. [11]INTRODUCTION
   2. [12]DISCLAIMERS
   3. [13]KERMIT SECURITY USER GUIDE
   4. [14]INSTALLATION AND CONFIGURATION
   I. [15]WHERE TO FIND SECURE TELNET AND FTP SERVERS
  II. [16]MULTIHOMED HOSTS, FIREWALLS, NATS
 III. [17]INTRODUCTION TO CERTIFICATES
      [18]GLOSSARY
      [19]REFERENCES
      [20]TRADEMARKS
    ________________________________________________________________________

  1. INTRODUCTION

   [ [21]Top ] [ [22]Contents ] [ [23]Glossary ] [ [24]Next ]

   CHAPTER CONTENTS

  1.1. [25]Secure Connections
  1.2. [26]Internet Protocols
  1.3. [27]Authentication
  1.4. [28]Encryption
  1.5. [29]Integrity

   SECURITY is the hot topic on the Internet. Security systems and
   protocols abound. But it was not always so. In the early days, the
   mere act of putting two computers in touch with each other was quite
   amazing. To connect multiple diverse computers to a common network,
   allowing any pair of them to communicate, was almost inconceivable.
   When the [30]ARPANET (precursor of the Internet) was first operational
   on October 1, 1969, the eager task for many years afterwards was to
   open up more and more sites to it. The architecture of the network and
   its protocols were developed in research laboratories in an atmosphere
   of trust.

   Only later, when the ARPANET became the world-wide Internet and was
   opened up to limitless numbers of people, did security become an
   issue: hackers, crackers, script kiddies, terrorists, spies,
   swindlers, saboteurs, blackmailers, pranksters, and pests of every
   sort inundate the network and every computer on it with a constant
   barrage of probes and attacks. It is increasingly necessary to secure
   connections from eavesdropping and malicious tampering (not to mention
   spam, worms, viruses, and denial-of-service attacks, but that's
   [31]another story).

   The network itself is not secure. By its very nature and fundamental
   design, it is entirely open[32]*. While it might be possible to insert
   security at the transport and/or network layers, transparent to all
   applications, the approach until now has been to layer security
   protocols over TCP and IP: some of them standard, some not so
   standard. Even among the standard ones, there are many to choose from.
   This approach requires one or more security methods to be programmed
   into each and every client and server application that is to make or
   accept secure Internet connections. The situation should improve in
   the future as security becomes part of the network itself through
   evolving standards such as [33]IPSec, [34]IPv6, and [35]DNSSEC.

   Meanwhile, insecure connections remain the norm, in which passwords,
   credit-card information, private correspondence, and so on can be
   captured and/or altered in transit by malicious persons. Security
   remains elusive because we have a 30+ year history of open networks,
   clients, and servers, and because of the many competing security
   methods, the shifting definitions of each one, various legal
   entanglements, and the overall complexity of the entire topic.

   Why should I care about security? The reasons are obvious: to prevent
   fraud on your person, theft of your money or identity, hijacking of
   your computer accounts, tampering with your research results; any
   number of malicious acts aimed at you or performed by someone
   masquerading as you. Perhaps an even more compelling reason to care is
   that more and more sites are requiring secure clients for access:
   plain old dialup or insecure Telnet or FTP simply can't be used any
   more.

   Kermit software has offered secure connections since 1998. This
   document presents the security methods embodied in [36]C-Kermit 8.0
   and [37]Kermit 95 2.00, which include:

     * Kerberos([38]TM) IV and V
     * Secure Remote Password([39]TM)(SRP)
     * Secure Sockets Layer(SSL)/Transport Layer Security(TLS)
     * Secure Shell ([40]TM) (SSH) ([41]TM) v1 and v2 (built into K95,
       external in C-Kermit)
     * Microsoft NT LAN Manager (NTLM, K95 only)

   * This is a slight exaggeration; a ever-increasing amount of filtering
   occurs in routers; local networks are increasingly switched rather
   than broadcast, etc.
    ________________________________________________________________________

  1.1. Secure Connections

   [ [42]Top ] [ [43]Contents ] [ [44]Chapter Contents ] [ [45]Glossary ]

   What is a secure connection? A connection is secure if it provides:

     * Authentication of the user to the host/service without the
       transmission of the user's password;
     * Authentication of the host to the user;
     * Privacy, through a shared secret that can be used as an end-to-end
       encryption key; and:
     * Integrity: the assurance that the data has not been altered in
       transit.

   A secure connection requires two applications, one on each end, that
   support (and can negotiate) a common security method; for example, a
   Telnet client on your desktop and a Telnet server at the remote site,
   both equipped with Kerberos V protocols.

   Kermit software supports a variety of connection methods, including
   serial ports, modems, and TCP/IP. Presently, secure connections are
   supported only over TCP/IP connections. Since there are several
   security methods to consider (Kerberos, SSL, ...) and several TCP/IP
   application protocols where they can be used (Telnet, FTP, HTTP, ...),
   and different platforms for the clients and servers (Unix, VMS,
   Windows, OS/2, ...), the possibilities are many.

   To complicate matters, every Kermit program can come with or without
   security. Non-secure versions are required by USA export law. Secure
   versions can be built with any combination of the security methods
   listed above: Kerberos IV but not Kerberos V, SRP and SSL/TLS but not
   Kerberos, etc. Kermit 95 has either no security methods built in or
   else all of them. C-Kermit on Unix can have any combination, depending
   on the libraries available on each platform and which ones were
   selected by the builder.
    ________________________________________________________________________

  1.2. Internet Protocols

   [ [46]Top ] [ [47]Contents ] [ [48]Chapter Contents ] [ [49]Glossary ]

   Let's begin by looking at the Internet protocols that Kermit supports
   to see which security options are available for each:

   TELNET (Network Virtual Terminal Protocol)
          The Telnet protocol can be used to establish the most secure
          connections with the greatest choice of authentication and
          privacy method. Kermit's Telnet implementation supports
          Kerberos 4, Kerberos 5, Secure Remote Password (SRP), NTLM (K95
          only), and [50]X.509 certificates for client and server
          authentication. Privacy can be accomplished with the Secure
          Sockets Layer (SSL) or Transport Layer Security (TLS) cipher
          suites, or DES, CAST, or 3DES streaming ciphers.

   FTP (File Transfer Protocol)
          An FTP client can make secure connections for both the command
          and data channels as described in Internet [51]RFC 2228.
          Kermit's FTP implementation supports Kerberos 4, GSSAPI
          Kerberos 5, SRP, and SSL/TLS.

   HTTP (Hyper Text Transfer Protocol)
          HTTP can be used with SSL or TLS to submit requests and receive
          responses in a secure manner as described in [52]RFC 2818.

   RLOGIN (Remote Login)
          The Remote Login protocol can be used with Kerberos 4 or 5 to
          make authenticated connections. After authentication the DES
          streaming cipher can be used for privacy.

   SSL (Secure Socket Layer) / TLS (Transport Layer Security
          The SSL and TLS protocols can be used by themselves to
          establish a private connection to a host. Authentication of the
          server (and perhaps the client) is performed via exchange and
          verification of [53]X.509 certificates or Kerberos 5
          credentials. Kermit also can make Telnet connections over a
          secure SSL or TLS tunnel.

   Kerberos 5 User-to-User
          The Kerberos 5 user-to-user protocol can make authenticated and
          private connections between two end-user operated copies of
          Kermit.

   The table below summarizes which security methods Kermit can support
   for each Internet service if those security methods are built in to
   Kermit. If your copy of Kermit supports a particular security method
   for a particular service, you can use it if the server supports the
   same method. You see out which security methods your Kermit program
   supports by giving it the SHOW FEATURES command.
     _________________________________________________________________

     Protocol Krb4 Krb5 SSL/TLS SRP SSH NTLM
     Telnet Yes Yes Yes Yes Yes K95
     Rlogin Yes Yes No No No No
     SSL/TLS No Yes Yes No No No
     K5 User-User No Yes No No No No
     FTP Yes Yes Yes Yes No No
     HTTP No No Yes No No No
     Kermit Yes Yes Yes Yes No K95
     SSH No ?? No ?? Yes No
    ________________________________________________________________________

  1.3. Authentication

   [ [54]Top ] [ [55]Contents ] [ [56]Chapter Contents ] [ [57]Glossary ]

   SECTION CONTENTS

  1.3.1. [58]Kerberos
  1.3.2. [59]SRP
  1.3.3. [60]NTLM
  1.3.4. [61]X.509 Certificates

   AUTHENTICATION is the means by which one party proves its identity to
   to another. The most common authentication method is the familiar
   process of logging in with a username and password. When you do this
   on an insecure network connection, your identity and password are
   transmitted in clear text and can be "sniffed" by anybody who has
   access to any of the components of the network path; for example, by
   anybody who has a PC on a (non-switched) Ethernet network over which
   your information passes.

   Furthermore, when you make (say) a Telnet connection to a network, you
   accept the fact the you must authenticate yourself to it, but how do
   you know that the host itself is genuine? In the normal course of
   events, there is no requirement that it authenticate itself to you.

   Enter secure authentication. Any secure authentication scheme requires
   central management of identities, as in the Kerberos authentication
   system ([62]Section 1.3.1), X.509 certificates ([63]Appendix III), or
   Secure Remote Password ([64]Section 1.3.2). This type of security is
   best suited for large organizations -- universities, government
   agencies, corporations, hospitals -- that have a full-time
   professional network / security administration staff. The learning
   curve and startup time are significant, but worth the effort. Any
   security method can be breached, so the true measure of its
   effectiveness is its manageability: can breaches be repaired, can
   compromised identities be reclaimed? It is for these reasons that
   Microsoft, Sun, Apple, HP, IBM, and many Linux or BSD vendors are
   increasingly distributing Kerberos 5 as a core part of their operating
   systems.

   Unfortunately, the startup costs of a secure authentication system are
   sometimes so daunting that some organizations simply don't bother, and
   instead let users fend for themselves with unsigned public/private key
   pair schemes, such as SSH public key authentication and PGP. The only
   administrative tasks required up front are the installation and/or
   distribution of the required client and server software. This is not a
   secure authentication system; quite the opposite: it bypasses any
   secure authentication / authorization system that might be in place.
   And keys, once compromised, can not be revoked by those responsible
   for the security of the host: a serious consideration since so many
   security keys are stored on insecure disks (e.g. in Windows 9x/ME)
   ripe for picking.

    1.3.1. Kerberos

   [ [65]Top ] [ [66]Contents ] [ [67]Chapter Contents ] [ [68]Section
   Contents ] [ [69]Glossary ]

   Kerberos is a method, developed at Massachusetts Institute of
   Technology (MIT), by which two parties communicating over a TCP/IP
   connection can authenticate each other through a trusted, centrally
   managed third party without sending passwords across the network. The
   Kerberos protocols are defined in Internet RFCs [70]1510, [71]1964,
   and others. You can read more about Kerberos at the following
   websites:

     * [72]http://web.mit.edu/kerberos/www/
     * [73]http://nii.isi.edu/info/kerberos/
     * [74]http://nii.isi.edu/publications/kerberos-neuman-tso.html

   There are, in fact, two Kerberos protocols: Kerberos IV (4) and
   Kerberos V (5), the latter being the more flexible and secure
   protocol. The two are totally separate and incompatible. Any given
   site might support neither, either one, or both. One of the unique
   benefits associated with the use of Kerberos 5 authentication is its
   Single Sign-On (SSO) capability. This allows a user to enter their
   password once on the local machine, establish a secure connection to a
   second machine and from there establish additional connections without
   requiring the user to enter their password a second time.

   When both the client and server support the same version of Kerberos
   (4 or 5), Kerberos authentication with or without encryption can be
   negotiated. A "Kerberized" version of Kermit can make a connection to
   a non-Kerberized host, and a non-Kerberized host can accept a
   connection from a Kerberized version of Kermit, as long as neither
   side is configured to require Kerberos authentication.

   Kerberos authentication has been integrated into Telnet, Rlogin, FTP,
   and SSL/TLS as well as many other protocols not supported by Kermit.
   As part of the authentication process a session key is shared by the
   client and server that can be used to encrypt the current session.

    1.3.2. SRP

   [ [75]Top ] [ [76]Contents ] [ [77]Chapter Contents ] [ [78]Section
   Contents ] [ [79]Glossary ]

   Stanford University's Secure Remote Password (SRP) protocol is a
   method by which two parties can mutually authenticate each other in a
   secure manner through a Zero Knowledge Identification system. SRP is
   defined in Internet [80]RFC 2945. You can read more about SRP at the
   following website:

  [81]http://www-cs-students.stanford.edu/~tjw/srp/

   SRP authentication has been integrated into the Telnet and FTP
   protocol definitions (if not yet into all Telnet and FTP clients and
   servers). As a result of the authentication, a shared secret is
   produced that can be used to encrypt the authenticated session.

    1.3.3. NTLM

   [ [82]Top ] [ [83]Contents ] [ [84]Chapter Contents ] [ [85]Section
   Contents ] [ [86]Glossary ]

   Microsoft NT Lan Manager (NTLM) authentication is implemented in
   Kermit 95 only. Its only use is to authenticate Kermit 95 to Microsoft
   Windows based Telnet services distributed as part of Windows 2000,
   Windows XP Professional, and the NT Services for Unix products. Kermit
   95 can also use NTLM to authenticate incoming Telnet sessions when it
   is running under Windows NT/2000/XP. When running under Windows
   95/98/98SE/ME, Kermit 95 can only be an authenticating client.

   NTLM does not negotiate a shared secret and cannot be used to
   establish encrypted sessions. Therefore, connections made with NTLM
   are not considered secure although it is definitely better to use NTLM
   authentication than it is to transmit a password in clear text. NTLM
   is a proprietary protocol considered to be a trade secret by
   Microsoft. When establishing connections with another Kermit 95
   configured to accept incoming connections, Kermit 95 can negotiate
   NTLM over a SSL/TLS session. Security is then provided by SSL/TLS
   while authentication is performed with NTLM.

    1.3.4. X.509 Certificates

   [ [87]Top ] [ [88]Contents ] [ [89]Chapter Contents ] [ [90]Section
   Contents ] [ [91]Glossary ]

   When SSL/TLS is used to provide security, authentication of the server
   and optionally the client can be performed using [92]X.509 Public Key
   Certificates. Certificates are used to exchange a public key for use
   in establishing an encrypted connection and can be verified against a
   known trusted Root Certificate and a Certificate Revocation List (CRL)
   to indicate its authenticity and validity. The contents of the
   certificate can then be used to determine the identity of the remote
   service or the client.

   C-Kermit and Kermit 95 provide mechanisms for the customization of the
   certificate to userid mapping.
    ________________________________________________________________________

  1.4. Encryption

   [ [93]Top ] [ [94]Contents ] [ [95]Chapter Contents ] [ [96]Glossary ]

   Export of software incorporating strong encryption is [97]regulated by
   United States law.

   SECTION CONTENTS

  1.4.1. [98]Telnet
  1.4.2. [99]FTP
  1.4.3. [100]SSL/TLS
  1.4.4. [101]SSH
  1.4.5. [102]HTTP
  1.4.6. [103]Rlogin

   ENCRYPTION is the process by which data is encoded to prevent anybody
   from deciphering it except those for whom it is intended. Encryption
   is an essential component of Internet security because of the
   Internet's open architecture; since (in principal) everybody can watch
   your sessions, you have to scramble them to keep them private.

   A variety of encryption methods, or algorithms, exists ranging from
   easy to crack to next-to-impossible (but not truly impossible: if the
   data can be decrypted legitimately, it can also be decrypted
   illegitimately given adequate resources). Most modern
   encryption/decryption algorithms use keys as part of the process,
   either provided by the user or obtained automatically from a shared
   secret. For any given algorithm, the longer the key the more secure
   the encryption.

   Each application protocol such as Telnet, FTP and HTTP defines its own
   set of protocols for encrypting a session based on the authentication
   method.

    1.4.1. Telnet Encryption

   [ [104]Top ] [ [105]Contents ] [ [106]Chapter Contents ] [
   [107]Section Contents ] [ [108]Glossary ]

   The following encryption algorithms can be negotiated for a Telnet
   session with the Telnet Encryption Option ([109]RFC 2946) when used
   with Kerberos IV, Kerberos V, or Secure Remote Password
   authentication:

     * CAST-128 64-bit Cipher Feedback Mode [110]RFC 2950
     * CAST-128 64-bit Output Feedback Mode [111]RFC 2949
     * DES3 64-bit Cipher Feedback Mode [112]RFC 2947
     * DES3 64-bit Output Feedback Mode [113]RFC 2948
     * DES 64-bit Cipher Feedback Mode [114]RFC 2952
     * DES 64-bit Output Feedback Mode [115]RFC 2951

   When the Telnet START_TLS option is negotiated, [116]SSL/TLS provides
   encryption services for the Telnet session.

    1.4.2. FTP Encryption

   [ [117]Top ] [ [118]Contents ] [ [119]Chapter Contents ] [
   [120]Section Contents ] [ [121]Glossary ]

   Encryption for FTP sessions depends on the authentication method:
     * Kerberos IV authentication uses DES for encryption.
     * Kerberos V is supported within the GSS-API framework that
       negotiates the encryption algorithm at run-time. The negotiated
       encryption algorithm depends on the implementation of GSSAPI
       available to Kermit.
     * Secure Remote Password authentication may be used with CAST-128,
       3DES, DES, and Blowfish as encryption algorithms. The selected
       algorithm is user configurable.
     * SSL/TLS provides an extensive list of cipher suites for use
       protecting session data.

    1.4.3. SSL/TLS Encryption

   [ [122]Top ] [ [123]Contents ] [ [124]Chapter Contents ] [
   [125]Section Contents ] [ [126]Glossary ]

   Netscape's Secure Sockets Layer (SSL) and its IETF-approved successor,
   Transport Layer Security (TLS), provide for authentication and
   encryption of TCP/IP communications using a combination of public key
   and symmetric cryptographic algorithms. TLS is defined in Internet
   [127]RFC 2246. Traditional authentication of the server (and
   optionally the client) is performed by exchanging ITU-T X.509
   certificate chains (see [128]Appendix 3), that are verified by the
   receiver. Unlike raw public keys, X.509 certificates may be revoked by
   issuing a certificate revocation list (CRL) that is to be checked by
   the receiver during verification of the certificate chain.

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

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

   TLS can be used with Telnet Authentication methods such as Kerberos,
   Secure Remote Password, and NTLM to provide the highest level of data
   privacy with the strongest forms of mutual authentication when TLS
   in-band authentication is not performed.

    1.4.4. SSH Encryption

   [ [130]Top ] [ [131]Contents ] [ [132]Chapter Contents ] [
   [133]Section Contents ] [ [134]Glossary ]

   (to be filled in...)

    1.4.5. HTTP Encryption

   [ [135]Top ] [ [136]Contents ] [ [137]Chapter Contents ] [
   [138]Section Contents ] [ [139]Glossary ]

   Secure HTTP connections use [140]SSL/TLS for encryption.

    1.4.6. Rlogin Encryption

   [ [141]Top ] [ [142]Contents ] [ [143]Chapter Contents ] [
   [144]Section Contents ] [ [145]Glossary ]

   (to be filled in...)
    ________________________________________________________________________

  1.5. Integrity

   Certain security protocols including SSL/TLS, FTP SRP, FTP
   GSSAPI-Kerberos 5, Kerberos 5 User-to-User, and SSH not only encrypt
   network data streams, but also ensure that they have not been tampered
   with along the way. The integrity algorithms are most often MD4, MD5,
   or SHA-1.

   (details to be filled in...)
    ________________________________________________________________________

  2. DISCLAIMERS

   [ [146]Top ] [ [147]Contents ] [ [148]Glossary ] [ [149]Next ] [
   [150]Previous ]

     The statements made with regard to US export law reflect our
     understanding of the situation at this writing, which might change
     subsequently. We expect to update this document, and our website in
     general, in light of any new developments.

   Current US law forbids export of strong encryption software in binary
   form from the USA to all countries except Canada without a license.
   Thus the Kermit Project does not distribute pre-compiled secure
   versions of C-Kermit on the Internet.

   Security within Kermit is provided using the underlying services of
   third-party libraries, such as Kerberos or OpenSSL. These libraries
   are not necessarily included with Kermit (they are with the secure
   version of Kermit 95, but not with C-Kermit). If not, they must be
   obtained separately from the sources listed below, in compliance with
   the terms and conditions given at those sites and with United States
   and international law. For an overview of this issue, see (for
   example):

  [151]http://www.mozilla.org/crypto-faq.html

   Kermit software, when combined with the security libraries listed in
   this document, has been verified to negotiate and conduct
   authenticated and encrypted sessions with Kerberos, SRP, and/or
   SSL/TLS services on Internet hosts at Columbia University and other
   test sites, with Kermit features such as interactive terminal access,
   file transfer, and scripting operating successfully over secure
   connections, with any exceptions noted below.

   The Kermit Project does not and can not claim or warrant the external
   Kerberos, SRP, OpenSSL or other third-party modules to be free of
   loopholes or bugs. Authentication via Kerberos, SRP, or X.509
   certificates is not unbreakable. Any encryption method can be broken.
   Any software that is used for authentication or encryption should be
   analyzed for weaknesses, backdoors, bugs, and loopholes by the site
   and/or end user before use.

   The Kermit Project and Columbia University make no claim or warranty
   as to any particular level of security achievable by Kermit software
   with any third party security protocol, and may on no account be held
   liable for any damage resulting from its use (a more complete
   statement to this effect is found in the C-Kermit 8.0 license).

   Functional limitations:

     * Kerberos authentication is available on Telnet, FTP, Rlogin, and
       SSL/TLS secured connections.
     * Secure Remote Password authentication is available only on Telnet
       and FTP connections.
     * NTLM authentication is available only on Windows
       95/98/Me/NT/2000/XP and only on Telnet connections.
     * SSL/TLS may be used as its own connection protocol or on Telnet,
       FTP, and HTTP connections.
     * Kerberos support is not available in Kermit 95 for OS/2 due to
       lack of Kerberos implementations for OS/2.
     * SSH is built in to the Windows version Kermit 95, but C-Kermit
       uses the external ssh program.

   [ [152]C-Kermit ] [ [153]C-Kermit 8.0 ] [ [154]Kermit 95 ] [
   [155]Kermit Home ]
    ________________________________________________________________________

  3. KERMIT SECURITY USER GUIDE

   [ [156]Top ] [ [157]Contents ] [ [158]Glossary ] [ [159]Next ] [
   [160]Previous ]

   CHAPTER CONTENTS

  3.1. [161]Overview of Security Protocols
  3.2. [162]Security Command List
  3.3. [163]Making Secure Connections
  3.4. [164]Using Secure Connections

   Suppose you work at a company (or are a student or faculty member at a
   university, or otherwised engaged in an organization of some sort)
   that has secure services of the kind you can access with Kermit, such
   as terminal sessions, file transfer, or website management. Before you
   can access the services securely, you have to "tell" Kermit which
   authentication method to use, along with any site-specific parameters,
   and you might also want to say what should happen if the desired type
   of security can't be negotiated.

   Bear in mind that you can use only those security methods that are
   offered with the services you will be connecting to. You can't just
   pick any old security method and expect it to work: it takes two to
   tango.

   Kermit has all the commands you need to set up secure connections, and
   they are the topic of this rather lengthy chapter. But don't worry: in
   most cases, you'll have to deal with these commands only once, and
   possibly not at all:
     * If your organization has a [165]site or bulk license for Kermit
       95, the network or software license administrators in your
       organization should have set it all up for you in advance.
     * If you are setting up Kermit for your own use within an
       organization's security framework, you'll need to get assistance
       from the network administrators anyway, to find out the pertinent
       connection details.
     * In Kermit 95, there is a security form in the Dialer for any
       secure connections you need to make: fill it once, use it forever.
     * In any case, once you have put together the commands you need, you
       can add them to your Kermit customization file if you want them to
       be in effect every time you start Kermit, or you can make separate
       scripts for each host or organization and use them whenever
       needed.

   Therefore, this chapter is more for the system or network or security
   administrator than the typical end user. Given an organization that
   already has a security infrastructure in place, this chapter explains
   the Kermit commands necessary to use it. All the information should be
   here, but if you have trouble finding what you need or putting the
   pieces together, feel free to [166]send us questions by e-mail.
    ________________________________________________________________________

  3.1. Overview of Security Protocols

   SECTION CONTENTS

  3.1.1. [167]Kerberos
  3.1.2. [168]SRP
  3.1.3. [169]NTLM
  3.1.4. [170]SSL/TLS
  3.1.5. [171]SSH

  3.1.1. Kerberos Overview

   [ [172]Top ] [ [173]Contents ] [ [174]Chapter Contents ] [
   [175]Section Contents ] [ [176]Glossary ]

   When making a Kerberized connection, you must first know which
   Kerberos version, 4 or 5, is supported by the host or service you want
   to connect to, and you must be registered in the Kerberos database at
   the host's site. If you're unsure about any of this, contact your site
   administrator.

   Before authentication to a specific service (such as Telnet) can
   succeed, you must login to the site's Kerberos Ticket Granting Server.
   Depending on the Kerberos implementation and installation options this
   might be done automatically when you log in to your operating system.
   Otherwise you can do it with external utilities from MIT (such as
   Leash, KRB5, or kinit), or with Kermit's built-in functionality,
   explained in this chapter.

   Once a Ticket Granting Ticket (TGT) is acquired, Kermit can use it to
   request additional tickets for each host (service) you wish to connect
   to. These service tickets can be used to authenticate you with the
   host automatically during a specified time interval, after which the
   tickets expire. When authentication is successful, you are logged in
   to the host without having to supply a user ID or password.

   Besides providing credentials for use during authentication, the
   service ticket also contains a session key to be used for encrypting
   the session. After the connection is authenticated, Kermit (if the
   necessary encryption capabilities are available) attempts to negotiate
   bidirectional encryption. If encryption is negotiated, it is used in
   one or both directions, depending on what the server agrees to.

   When Kerberos V authentication is used, Kermit supports credential
   forwarding by transferring your Ticket Granting Tickets to the host
   that you are connecting to, so you can make additional authenticated
   connections from that host to any others that accept those tickets.
   This provides a single sign-on capability to all the hosts and
   services within the Kerberos realm.

   Kerberos 5 authentication is one of the few authentication methods
   that can be used to provide verification of anonymous TLS connections.
   This is taken advantage of in Telnet by negotiating AUTH KRB5 after
   establishing a private connection with the START_TLS option.

   Successful operation of Kerberos requires that all machines have their
   dates and times synchronized. Be aware that PC clocks can drift, and
   this can cause authentication failures. Kerberos requires that all
   clocks be synchronized within 5 minutes.

  3.1.2. Secure Remote Password (SRP) Overview

   [ [177]Top ] [ [178]Contents ] [ [179]Chapter Contents ] [
   [180]Section Contents ] [ [181]Glossary ]

   SRP requires no special configuration of the client. When Kermit is
   used to connect to a host that supports SRP, the user name is
   transmitted automatically to the host and then a Password prompt is
   displayed in the Kermit command screen. This indicates that the
   password will not be sent to the host over the communication channel.
   Instead the password is used as part of a negotiation in which
   authentication is either mutual or none at all.

   The result of a mutual authentication is a shared secret used to
   generate two different keys for encrypting the incoming and outgoing
   data.

   SRP authentication is one of the few authentication methods that can
   be used to provide verification of anonymous TLS connections. The
   Kermit Telnet client takes advantage of this fact by by negotiating
   AUTH SRP after establishing a private connection with the START_TLS
   option.

  3.1.3. NTLM Overview

   [ [182]Top ] [ [183]Contents ] [ [184]Chapter Contents ] [
   [185]Section Contents ] [ [186]Glossary ]

   Microsoft's native authentication method is called (Windows) NT LAN
   Manager, or NTLM. It is implemented in Windows 9x/ME and NT/2000/XP
   and requires no configuration on the part of the user. When K95 is
   used on any Microsoft Windows version, it can be used as an NTLM
   Telnet client to authenticate to Microsoft's NT Services for Unix
   Telnet Server or to a K95 configured to accept incoming connections.

   When K95 is used on Windows NT/2000/XP it can be configured to accept
   incoming connections and authenticate NTLM Telnet clients.

   NTLM is a weak form of authentication. It provides no shared secret
   and cannot be used as a means of securing a connection with
   encryption.

  3.1.4. SSLv3 and TLSv1 Overview

   [ [187]Top ] [ [188]Contents ] [ [189]Chapter Contents ] [
   [190]Section Contents ] [ [191]Glossary ]

     (Also see [192]Appendix III for an introduction to the concept of
     certificates.)

   Secure Sockets Layer Version 3 (SSLv3) and its successor Transport
   Layer Security Version 1 (TLSv1) ([193]RFC 2246) were originally
   developed for Web browsing. They provide a framework for using
   public-key certificates or Kerberos 5 to negotiate server and
   (optionally) client authentication and bidirectional encryption. The
   encryption provided by SSLv3 and TLSv1 is stronger than that provided
   by the Telnet Encryption option.

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

     * Pure SSLv3 connections via SET HOST host port /SSL
     * Pure TLSv1 connections via SET HOST host port /TLS
     * SSLv3 connections negotiated by Tim Hudson's Telnet AUTH SSL
       option
     * TLSv1 connections negotiated by the IETF TN3270E Working Group's
       TELNET START_TLS option
     * SSLv3 and TLSv1 connections negotiated with FTP OPEN host port
     * SSLv3 and TLSv1 connections negotiated with HTTP OPEN host port

   In their most common use, SSL and TLS negotiations provide the client
   with authentication of the host computer when the host's X.509
   certificate is verified or when Kerberos 5 is used. The client can be
   authenticated with an X.509 certificate issued to the end user, or
   with Kerberos 5, or with one of the supported Telnet authentication
   methods. Even though the data channel is encrypted, the transmission
   of passwords to the host should still be avoided to prevent theft by a
   compromised host.

   If certificates are to be verified, the root certificates of the
   certificate authorities (CAs) must be available. If you are not acting
   as your own CA you need a file containing the root certificates that
   were used to sign the certificates belonging to the servers you want
   to authenticate. A compilation of most of the commercial Certificate
   Authority root certificates as extracted from Microsoft Windows XP's
   certificate database is available at:

   [194]ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem

   Once the file is downloaded, you can tell Kermit where it is with the
   following command ([195]Section 3.2.2.3):

  SET AUTH SSL VERIFY-FILE path/ca_certs.pem

   When Kermit is acting as an [196]Internet Kermit Service daemon
   (IKSD), client certificates can be used for automatic login. If a
   certificate-to-userid mapping function is provided, the IKSD logs the
   user in automatically if the certificate is verified and the specified
   userid exists. Kermit also supports the use of a ".tlslogin" file that
   allows a certificate to be used to login automatically to an account
   without a certificate-to-userid mapping function. When Kermit receives
   a username via the Telnet New-Environment variable after it has
   received and verified a client certificate, it looks in the home
   directory corresponding to the username for a file called ".tlslogin".
   If the file contains the certificate presented by the client, the
   client is logged in as the requested user without a password. See
   [197]Appendix III for information on certificate to user mapping.

   The method for negotiating Tim Hudson's Telnet AUTH SSL option is open
   to a "man-in-the-middle" attack which is capable of disabling the use
   of SSL before the negotiation is begun. It should be used only with:

  SET TELNET AUTHENTICATION TYPE SSL
  SET TELOPT AUTHENTICATION REQUIRED

   When using IKSD with START_TLS you should create an /etc/iksd.conf
   including Kermit commands that point to the certificate and key files:

  set auth tls rsa-cert-file /usr/local/ssl/certs/telnetd-rsa.pem
  set auth tls rsa-key-file  /usr/local/ssl/certs/telnetd-rsa-key.pem
  set auth tls dsa-cert-file /usr/local/ssl/certs/telnetd-dsa.pem
  set auth tls dsa-key-file  /usr/local/ssl/certs/telnetd-dsa-key.pem

   as well as the list of acceptable ciphers:

  set auth tls cipher 3DES:DSS

   If your server certificate was signed by an intermediary certificate
   authority instead of a root, you must provide the full chain of
   intermediary certificates for the client to be able to authenticate
   your server. These certificates can be specified with:

  set auth tls rsa-cert-chain-file /usr/local/ssl/certs/telnetd-rsa-chain.pem
  set auth tls dsa-cert-chain-file /usr/local/ssl/certs/telnetd-dsa-chain.pem

   The SSL and TLS handshake can be very time-consuming, and therefore
   Kermit can cache your your SSL/TLS sessions. When Kermit is used with
   a peer that supports cached sessions, subsequent connections to the
   same host can be securely established in a fraction of the time
   necessary for the initial connection. This is especially important for
   FTP and HTTP, which can make many connections to the same host during
   during a typical session.

   For a list of Telnet servers that support START_TLS see [198]Section
   I.1 of [199]Appendix I. For a list of FTP servers that support AUTH
   SSL and AUTH TLS see [200]Section I.2.

  3.1.5. SSH v1 and v2 Overview

   [ [201]Top ] [ [202]Contents ] [ [203]Chapter Contents ] [
   [204]Section Contents ] [ [205]Glossary ]

   (To be filled in...)
    ________________________________________________________________________

  3.2. Security Command List

   [ [206]Top ] [ [207]Contents ] [ [208]Chapter Contents ] [
   [209]Glossary ] SECTION CONTENTS

  3.2.1. [210]Connection Establishment
  3.2.2. [211]The SET AUTHENTICATION Command
  3.2.3. [212]The AUTHENTICATE Command
  3.2.4. [213]Other Security-Related Commands

   The following notation is used in Kermit command syntax descriptions:

   KEYWORD
          Command keywords are shown in boldface. These are literal words
          to be used in the command. Alphabetic case does not matter.
          Keywords can be abbreviated to any degree that does not produce
          a conflict with any other keyword that can be used in the same
          position.

   parameter
          Parameter names are shown in italics; they are to be replaced
          by an actual value; for example, number might be replaced by
          123, and filename might be replaced by oofa.txt.

   [ thing ]
          Any item enclosed in italicized square brackets is optional;
          that is, it can be omitted.

   { thing1, thing2, ... }
          Italicized curly braces enclose a list of choices: pick one.

   oofa.txt
          Typewriter font is used for computer messages, dialogs, code,
          and filenames.

   In all Kermit commands:

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

   Some of Kermit's Kerberos-related commands are rather complex, but
   remember that you don't have to memorize them, or any other Kermit
   commands. Use "?" at any point to feel your way through the command,
   or type HELP for the desired command to see a brief explanation. If
   you would like to have a tutorial in Kermit basics before proceeding,
   please visit:

   The C-Kermit Tutorial
          [214]http://www.columbia.edu/kermit/ckututor.html

   The Kermit 95 Tutorial
          [215]http://www.columbia.edu/kermit/k95tutor.html

   Kermit Script Tutorial and Library
          [216]http://www.columbia.edu/kermit/ckscripts.html

   Before you try to make any secure connections, you should check
   whether your version of Kermit has the required capabilities. The SHOW
   FEATURES command lists the security methods that are and are not
   included. In addition the following commands can be used (typically in
   scripts) to check for specific security features:

   CHECK KERBEROS
          tells whether your version of Kermit has been built to include
          Kerberos protocol (even if it cannot function on your system).
          Succeeds if Kerberos is included, fails if it isn't. The CHECK
          command can be used in scripts like this:

  check kerberos
  if success {
      Commands to execute if Kerberos is built in.
  } else {
      Commands to execute if Kerberos is not built in.
  }

   CHECK NTLM
          Tells whether your version of Kermit has been built to include
          the NTLM support even if it cannot function on your system, and
          succeeds or fails accordingly.

   CHECK SRP
          Tells whether your version of Kermit has been built to include
          SRP protocols. Succeeds or fails accordingly.

   CHECK SSL/TLS
          Tells whether your version of Kermit has been built to include
          SSL/TLS (even if it cannot function on your system). Succeeds
          or fails accordingly.

   IF AVAILABLE ENCRYPTION command
          Executes the command if session encryption is available in your
          version of Kermit (e.g. in K95 if the K95CRYPT.DLL file is
          installed on your PC). Example:

  if available encryption set telnet encryption type cast128_cfb64

   IF AVAILABLE KERBEROS4 command
          Executes the command if Kerberos 4 is available in your version
          of Kermit (e.g. if the Kerberos 4 DLLs are installed on your
          PC).

   IF AVAILABLE KERBEROS5 command
          Executes the command if Kerberos 5 is available in your version
          of Kermit.

   IF AVAILABLE NTLM command
          Executes the command if Microsoft NT LAN Manager protocol is
          available in your version of Kermit.

   IF AVAILABLE SRP command
          Executes the command if Secure Remote Password protocol is
          available in your version of Kermit.

   IF AVAILABLE { SSL, TLS } command
          Executes the command if SSL/TLS protocol is available in your
          version of Kermit.
    ________________________________________________________________________

  3.2.1. Connection Establishment

   [ [217]Top ] [ [218]Contents ] [ [219]Chapter Contents ] [
   [220]Section Contents ] [ [221]Glossary ]

   SUBSECTION CONTENTS

  3.2.1.1. [222]Making Secure Telnet Connections
  3.2.1.2. [223]Making Secure FTP Connections
  3.2.1.3. [224]Making Secure HTTP Connections

    3.2.1.1. Secure TELNET Connections

   [ [225]Top ] [ [226]Contents ] [ [227]Chapter Contents ] [
   [228]Section Contents ] [ [229]Subsection Contents ] [ [230]Glossary ]

   The Telnet protocol is one of the most flexible protocols ever used on
   computer networks, and therefore can be somewhat complicated when its
   advanced options come into play. Kermit has commands to manage every
   aspect of the Telnet connection. Kermit's Telnet engine and related
   commands are thoroughly described in the Kermit Telnet Reference:

  [231]http://www.columbia.edu/kermit/telnet.html

   (which you should read if you're not familiar with Kermit's Telnet
   client). This section focuses on Telnet-related commands for making
   secure connections.

   Four Telnet Options can be negotiated between a Telnet client and
   server that affect secure connections: AUTH, ENCRYPT, START_TLS, and
   FORWARD_X. When people talk about Telnet not being secure they are
   referring to Telnet clients and servers that can't negotiate any of
   these four options (because they have not been coded to do so). That
   does not mean that secure Telnet clients (such as Kermit) and servers
   ([232]Appendix I) are not readily available.

   Telnet sessions always begin in an insecure state. Only after the
   initial negotiations are complete can the session be secured. Security
   in Telnet can be established using many combinations of Telnet Options
   and authentication and encryption methods.

   The AUTH option negotiates whether authentication is to be used for
   the current session, and if so, which type of authentication. The
   authentication type is determined by the server offering an ordered
   list of types and the client choosing the most preferred type that it
   supports. Most forms of authentication generate a shared secret that
   can be used with the ENCRYPT option for privacy. The How and Encrypt
   flags specify an authentication mode and whether encryption is
   required for this connection. The AUTH option can be negotiated with
   either the START_TLS or the ENCRYPT option, but not both.

   The following commands control Kermit's Telnet security negotiation
   policies and procedures:

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

   SET TELNET AUTHENTICATION TYPE { AUTOMATIC, KERBEROS4, KERBEROS5,
          NTLM, SRP, SSL, NONE }
          AUTOMATIC is the default. Available options can vary depending
          on the features Kermit was built to support and the operating
          system configuration; type "set telnet auth type ?" for a list
          (Hint: keywords in Kermit commands can be abbreviated).

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

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

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

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

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

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

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

   The Telnet protocol ENCRYPT option is used to negotiate whether
   streaming ciphers are to be used to protect the privacy of the
   connection, and if so, which encryption type to use in each direction.
   The encryption type is determined by each side offering the list of
   types it can use to receive data. Then the sender chooses the first
   type that it supports from the list. The ENCRYPT option cannot be
   negotiated without the AUTH option. Whenever both START_TLS and
   ENCRYPT are both available, START_TLS is used since TLS provides both
   privacy and integrity to the data stream.

   SET TELOPT [ { /CLIENT, /SERVER } ] ENCRYPTION { ACCEPTED, REFUSED,
          REQUESTED, REQUIRED } { ACCEPTED, REFUSED, REQUESTED, REQUIRED
          }
          The first parameter specifies the Kermit-to-peer state. The
          second parameter specifies the peer-to-Kermit state. The
          default is ACCEPTED REQUESTED: Kermit accepts encryption if
          offered, and requests it in case it is not offered.

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

   The START_TLS option negotiates whether the current session is to be
   protected by Transport Layer Security (TLS), the same protocol used to
   secure all of the HTTP Web sites on the Internet. TLS uses X.509
   certificates or Kerberos 5 credentials to authenticate the server and
   optionally authenticate the client.

   START_TLS can be used with AUTH to allow Kerberos, Secure Remote
   Password, or other authentication methods to be used to authenticate
   the client. START_TLS can not be used with the ENCRYPT option. Nor is
   there any need to since the protection provided by TLS is stronger
   than all of the streaming ciphers supported by the ENCRYPT option.

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

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

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

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

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

   When establishing a secure connection there are potentially three
   usernames associated with the connection: the name of the user on the
   local machine; the name under which the user authenticates (the
   Kerberos principal name or X.509 certificate name); and the name the
   user wants to login as. The login name can be set with either of the
   following commands:

   SET TELNET ENVIRONMENT USER name

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

   All forms of authentication rely on some secret information that only
   the user (or service) being authenticated knows or has in their
   possession. Before Kermit can authenticate as the user it must acquire
   this secret information. This is usually done by prompting the user
   for the necessary information at the time of authentication. But what
   if you need to automate the process? The SET LOGIN PASSWORD command
   can be used to specify the password to Kermit prior to establishing
   the connection. However, we strongly advise that this command be used
   in a script that prompts for the password and then establishes the
   automated connection later. Storing a password in a script file
   defeats all of the hard work you have done to secure your connections.

   An NTLM user ID consists of both a DOMAIN and a username. This is set
   in Kermit as SET LOGIN USER DOMAIN\\username due to the use of
   backslash (\) as the command quote character in Kermit's command
   language.

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

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

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

    3.2.1.2. Secure FTP Connections

   [ [233]Top ] [ [234]Contents ] [ [235]Chapter Contents ] [
   [236]Section Contents ] [ [237]Subsection Contents ] [ [238]Glossary ]

   C-Kermit 8.0 and Kermit 95 2.00 provide support for authenticated and
   encrypted file transfers using Kerberos 4, GSSAPI-Kerberos 5, Secure
   Remote Password (SRP), Secure Sockets Layer (SSL), and Transport Layer
   Security (TLS).

   Complete details on how to use the FTP support can be found at the
   [239]Kermit website. Here we explain how to make secure FTP
   connections (server willing) with the FTP OPEN command:

   FTP [ OPEN [ { /SSL, /TLS } ] ] hostname [ port ] [ switches ]
          Opens a connection to the FTP server on the given host. The
          default TCP port is 21 (or 990 if /SSL or /TLS are specified),
          but a different port number can be supplied if necessary. /SSL
          or /TLS should be used if the FTP daemon is accessed through an
          SSL Proxy Server. Optional switches are:

        /ANONYMOUS
                Logs you in anonymously.

        /USER:text
                Supplies the given text as your username.

        /PASSWORD:text
                Supplies the given text as your password. If you include
                a username but omit this switch and the server requires a
                password, you are prompted for it.

        /ACCOUNT:text
                Supplies the given text as your account, if required by
                the server.

        /ACTIVE
                Forces an active (rather than passive) connection.

        /PASSIVE
                Forces a passive (rather than active) connection.

   The following commands configure the use of FTP Security when
   establishing connections:

   SET FTP AUTHTYPE list
          Specifies an ordered list of authentication methods to be
          attempted when FTP AUTOAUTHENTICATION is ON. The default list
          is: GSSAPI-KRB5, SRP, KERBEROS_V4, TLS, SSL. If none of the
          specified methods are supported by the server, an insecure
          login is used as a fallback. It should be noted that TLS and
          SSL can be used to secure an anonymous connection.

   SET FTP AUTOAUTHENTICATION { ON, OFF }
          Specifies whether or not authentication should be negotiated by
          the FTP OPEN command. Default is ON.

   SET FTP AUTOENCRYPTION { ON, OFF }
          Specifies whether encryption and message integrity (privacy)
          should be negotiated by the FTP OPEN command. Default is ON.

   SET FTP AUTOLOGIN { ON, OFF }
          Tells Kermit whether to try to automatically log you in (using
          the FTP USER command) during the FTP OPEN command. Default is
          ON.

   SET FTP COMMAND-PROTECTION-LEVEL { CLEAR, CONFIDENTIAL, PRIVATE, SAFE
          }
          Tells what level of protection is applied to the FTP command
          channel. CLEAR means no protection at all. CONFIDENTIAL means
          the messages are encrypted but not integrity protected. PRIVATE
          means the messages are encrypted and integrity protected. SAFE
          means the messages are integrity protected but not encrypted.

   SET FTP CREDENTIAL-FORWARDING { ON, OFF }
          Specifies whether end-user credentials are to be forwarded to
          the server if supported by the authentication method. At the
          moment only GSSAPI-KRB5 supports credentials forwarding.

   SET FTP DATA-PROTECTION-LEVEL { CLEAR, CONFIDENTIAL, PRIVATE, SAFE }
          Tells what level of protection is applied to the FTP data
          channel. The levels are the same as for SET FTP
          COMMAND-PROTECTION-LEVEL.

   SET FTP SRP CIPHER cipher
          Specifies a cipher to be used to encrypt FTP data if SRP
          security is negotiated. The default cipher is DES3_ECB.

   SET FTP SRP HASH hash
          Specifies a hash to be used to integrity protect FTP data if
          SRP security is negotiated. The default hash is SHA1.
      ______________________________________________________________________

    3.2.1.3. Secure HTTP Connections

   [ [240]Top ] [ [241]Contents ] [ [242]Chapter Contents ] [
   [243]Section Contents ] [ [244]Subsection Contents ] [ [245]Glossary ]

   C-Kermit 8.0 and Kermit 95 2.00 provide support for secure HTTP
   requests via the use of SSL or TLS. Secure connections are established
   automatically when the destination service name is "https" or the port
   number is 443. Alternatively, SSL or TLS may be utilized with
   arbitrary port numbers if you include the appropriate switch in the
   HTTP OPEN command:

   HTTP [ switches ] OPEN [ { /SSL, /TLS } ] hostname [ service/port ]
          Instructs Kermit to open a new connection for HTTP
          communication with the specified host on the specified port.
          The default port is "http" (80). If /SSL or /TLS are specified
          a secure connection is established. If switches are specified,
          they are applied to all subsequent HTTP actions (GET, PUT, ...)
          until an HTTP CLOSE command has been executed.
    ________________________________________________________________________

  3.2.2. The SET AUTHENTICATION Command

   [ [246]Top ] [ [247]Contents ] [ [248]Chapter Contents ] [
   [249]Section Contents ] [ [250]Glossary ]

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

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

  3.2.2.1. SET AUTHENTICATION Commands for Kerberos

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

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

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

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

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

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

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

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

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

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

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

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

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

          in the Kermit initialization file or connection script.

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

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

  SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL {}

          has been issued.

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

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

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

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

  3.2.2.2. SET AUTHENTICATION Commands for SRP

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

  3.2.2.3. SET AUTHENTICATION Commands for SSL/TLS

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

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

        Key Exchange Algorithms:

          kRSA: RSA key exchange

          kDHr: Diffie-Hellman key exchange (key from RSA cert)

          kDHd: Diffie-Hellman key exchange (key from DSA cert)

          kEDH: Ephemeral Diffie-Hellman key exchange (temporary key)

          kKRB5: Kerberos 5

        Authentication Algorithm:

          aNULL: No authentication

          aRSA: RSA authentication

          aDSS: DSS authentication

          aDH: Diffie-Hellman authentication

          aKRB5: Kerberos 5

        Cipher Encoding Algorithm:

          eNULL: No encoding

          AES256: 256-bit AES encoding

          AES128: 128-bit AES encoding

          DES: DES encoding

          3DES: Triple DES encoding

          RC4: RC4 encoding

          RC2: RC2 encoding

          IDEA: IDEA encoding

        MAC Digest Algorithm:

          MD5: MD5 hash function

          SHA1: SHA1 hash function

          SHA: SHA hash function (should not be used)

        Aliases:

          ALL: all ciphers

          SSLv2: all SSL version 2.0 ciphers (should not be used)

          SSLv3: all SSL version 3.0 ciphers

          EXP: all export ciphers (40-bit)

          EXPORT56: all export ciphers (56-bit)

          LOW: all low strength ciphers (no export)

          MEDIUM: all ciphers with 128-bit encryption

          HIGH: all ciphers using greater than 128-bit encryption

          RSA: all ciphers using RSA key exchange

          DH: all ciphers using Diffie-Hellman key exchange

          EDH: all ciphers using Ephemeral Diffie-Hellman key exchange

          ADH: all ciphers using Anonymous Diffie-Hellman key exchange

          DSS: all ciphers using DSS authentication

          KRB5: all ciphers using Kerberos 5

          AES: all ciphers using AES

          NULL: all ciphers using no encryption

          Each item in the list may include a prefix modifier:

        "+"
                Move cipher(s) to the current location in the list

        "-"
                Remove cipher(s) from the list (may be added again by a
                subsequent list entry)

        "!"
                Kill cipher from the list (it may not be added again by a
                subsequent list entry)

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

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

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

   All algorithms including ADH and export but excluding patented
   algorithms:

  HIGH:MEDIUM:LOW:EXPORT56:EXP:ADH:!kRSA:!aRSA:!RC4:!RC2:!IDEA

   The OpenSSL command:

  openssl ciphers -v list-of-ciphers

   may be used to list all of the ciphers and the order described by a
   specific list-of-ciphers.

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

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

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

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

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

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

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

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

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

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

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

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

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

   Note: When Kermit is running as an IKSD it cannot support encrypted
   private keys. If your private key file is encrypted you can use the
   following command to unencrypt it (provided you know that pass
   phrase):

  openssl dsa -in encrypted-key-file -out unencrypted-key-file

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

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

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

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

   Note: When Kermit is running as an IKSD it cannot support encrypted
   private keys. If your private key file is encrypted you can use the
   following command to unencrypt it (provided you know that pass
   phrase):

  openssl rsa -in encrypted-key-file -out unencrypted-key-file

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

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

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

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

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

          OpenSSL expects the hash symlinks to be made like this:

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

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

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

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

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

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

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

  3.2.3. The AUTHENTICATE Command (Kerberos Only)

   [ [253]Top ] [ [254]Contents ] [ [255]Chapter Contents ] [
   [256]Section Contents ] [ [257]Glossary ]

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

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

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

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

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

   AUTHENTICATE K4 INITIALIZE switches (all optional):

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

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

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

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

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

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

   The Kerberos 4 principal format is:

  userid[.instance[.instance]]@[realm]

   but can be omitted if it is the same as your username or SET LOGIN
   USERID value on the client system.

   AUTHENTICATE K5 INITIALIZE switches (all optional):

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

        /FORWARDABLE
                Requests forwardable tickets.

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

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

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

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

        /NOT-FORWARDABLE
                Requests non-forwardable tickets.

        /NOT-PROXIABLE
                Requests non-proxiable tickets.

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

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

        /PROXIABLE
                Requests proxiable tickets.

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

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

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

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

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

   The Kerberos 5 principal format is:

  userid[/instance][@realm]

   and can be omitted if it is the same principal as stored in the
   current ticket cache at the time Kermit started; or the current
   username if a ticket cache did not exist.

   Note: Kerberos 5 always attempts to retrieve a Ticket Granting Ticket
   (TGT) using the preauthenticated TGT request.

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

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

        /ENCRYPTION
                Displays the encryption used by each ticket (if
                applicable):

               o DES-CBC-CRC
               o DES-CBC-MD4
               o DES-CBC-MD5
               o DES-CBC-RAW
               o DES-HMAC-SHA1
               o DES3-CBC-RAW
               o DES3-CBC-SHA
               o DES3-HMAC-SHA1

        /FLAGS
                provides the following information (if applicable) for
                each ticket:

               o F - Ticket is Forwardable
               o f - Ticket was Forwarded
               o P - Ticket is Proxiable
               o p - Ticket is a Proxy
               o D - Ticket may be Postdated
               o d - Ticket has been Postdated
               o i - Ticket is Invalid
               o R - Ticket is Renewable
               o I - Ticket is the Initial Ticket
               o H - Ticket has been authenticated by Hardware
               o A - Ticket has been Pre-authenticated

  3.2.4. Other Security-Related Commands

   [ [264]Top ] [ [265]Contents ] [ [266]Chapter Contents ] [
   [267]Section Contents ] [ [268]Glossary ]

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

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

   For mutual authentication to succeed, the client and the server must
   agree on the name to be used for the server. It is common for servers
   to have more than one name. This is especially true for clusters of
   servers that provide the same function and are referenced by an alias.
   For example, www.foo.com might be an alias for three machines
   www-1.foo.com, www-2.foo.com, and www-3.foo.com. If the hosts are
   configured to use separate credentials for authentication it would be
   necessary to know which host is actually in use since "www.foo.com" is
   not equal to "www-1.foo.com".

   On the other hand, since DNS is not a secure service, using an
   additional lookup to verify the name associated with a particular IP
   address increases the susceptibility that the authentication may be
   forged by an attacker.

   For the highest level of security, Reverse DNS Lookups should be
   turned OFF.

   [ [270]C-Kermit ] [ [271]C-Kermit 8.0 ] [ [272]Kermit 95 ] [
   [273]Kermit Home ]
    ________________________________________________________________________

  3.3. Making Secure Connections

   [ [274]Top ] [ [275]Contents ] [ [276]Chapter Contents ] [
   [277]Glossary ]

   SECTION CONTENTS

  3.3.1. [278]The SET HOST Command
  3.3.2. [279]The TELNET Command
  3.3.3. [280]The RLOGIN Command
  3.3.4. [281]Making Secure FTP Connections
  3.3.5. [282]Making Secure HTTP Connections
  3.3.6. [283]Using Only SSL or TLS
  3.3.7. [284]Using Kerberos 5 User-to-User Protocol

   TCP/IP connections established by Kermit are initiated either with the
   SET HOST command; a protocol-specific command such as TELNET or
   RLOGIN; or in the case of FTP and HTTP an OPEN command.

    3.3.1. The SET HOST Command

   [ [285]Top ] [ [286]Contents ] [ [287]Chapter Contents ] [
   [288]Section Contents ] [ [289]Glossary ]

   When using the SET HOST command to establish a secure connection,
   several switches are available between SET HOST and the hostname, plus
   a protocol switch at the end:

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

   The following SET HOST switches are useful with secure connections:

   /CONNECT
          Tells Kermit to enter CONNECT (terminal) mode automatically if
          the connection is successful.

   /SERVER
          Tells Kermit to enter server mode automatically if the
          connection is successful.

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

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

     The SET HOST protocol-switches used with secure connections are:

   /RLOGIN
          Use Rlogin protocol even if this is not an Rlogin port.

   /TELNET
          Send initial Telnet negotiations even if this is not a Telnet
          port.

   /K4LOGIN
          Use Kerberos IV klogin protocol even if this is not a klogin
          port.

   /EK4LOGIN
          Use Kerberos IV Encrypted login protocol even if this is not an
          eklogin port.

   /K5LOGIN
          Use Kerberos V klogin protocol even if this is not a klogin
          port.

   /EK5LOGIN
          Use Kerberos V Encrypted login protocol even if this is not an
          eklogin port.

   /K5USER2USER
          Use Kerberos V User to User protocol.

   /SSL
          Perform SSL negotiations.

   /SSL-TELNET
          Perform SSL negotiations and if successful start Telnet
          negotiations.

   /TLS
          Perform TLS negotiations.

   /TLS-TELNET
          Perform TLS negotiations and if successful start Telnet
          negotiations.

    3.3.2. The TELNET Command

     [ [290]Top ] [ [291]Contents ] [ [292]Chapter Contents ] [
     [293]Section Contents ] [ [294]Glossary ]

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

   TELNET /AUTH:type /ENCRYPT:type /USERID:[name] /PASSWORD:[string] host
          port
          The TELNET command is a shortcut for making interactive
          terminal connections on a TCP/IP network using Telnet protocol.
          When used for secure connections, Kermit's TELNET command is
          the equivalent of:

  SET TELOPT AUTH ...
  SET TELNET AUTH TYPE ...
  SET TELOPT ENCRYPT ...
  SET TELNET ENCRYPT TYPE ...
  SET LOGIN USERID ...
  SET LOGIN PASSWORD ...
  SET HOST /CONNECT host port /TELNET

          The optional TELNET command switches are:

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

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

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

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

    3.3.3. The RLOGIN Command

     [ [295]Top ] [ [296]Contents ] [ [297]Chapter Contents ] [
     [298]Section Contents ] [ [299]Glossary ]

     The RLOGIN (Remote Login) protocol is not as flexible as the Telnet
     protocol and supports no option mechanism. Authentication and
     privacy are not part of the RLOGIN protocol. When we refer to
     authenticated and encrypted RLOGIN we are really referring to one
     of four other protocols derived from RLOGIN: Kerberos 4 Remote
     Login (K4LOGIN); Kerberos 4 Encrypted Remote Login (EK4LOGIN);
     Kerberos 5 Remote Login (K5LOGIN); and Kerberos 5 Encrypted Remote
     Login (EK5LOGIN).

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

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

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

        /KERBEROS4
                means service klogin and protocol k4login

        /KERBEROS4 /ENCRYPT
                means service eklogin and protocol ek4login

        /KERBEROS5
                means service klogin and protocol k5login

        /KERBEROS5 /ENCRYPT
                means service eklogin and protocol ek5login

    3.3.4. Making Secure FTP Connections

     [ [300]Top ] [ [301]Contents ] [ [302]Chapter Contents ] [
     [303]Section Contents ] [ [304]Glossary ]

     By default Kermit tries to negotiate a secure authentication method
     and to obtain private command and data channels. Therefore, all
     that is normally required to establish a secure FTP session is to
     issue the FTP OPEN command. If the server to which you are
     connecting supports a common security mechanism, it is used to
     secure the session.

     For example, to establish a secure FTP connection using SRP the
     following commands could be executed:

  SET FTP AUTHTYPE SRP
  SET FTP AUTOAUTHENTICATE ON              ; default setting
  SET FTP AUTOENCRYPTION ON                ; default setting
  SET FTP AUTOLOGIN ON                     ; default setting
  SET FTP SRP CIPHER DES_ECB               ; default setting
  SET FTP SRP HASH SHA1                    ; default setting
  SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting
  SET FTP DATA-PROTECTION-LEVEL PRIVATE    ; default setting
  FTP OPEN host /USER:username /PASSWORD:password

     If the /USER and/or /PASSWORD switches are omitted, the user is
     prompted for the required fields.

     For example, to establish a secure FTP connection using
     GSSAPI-Kerberos 5 the following commands could be executed:

  SET AUTH KERBEROS5 REALM MY.REALM
  SET AUTH KERBEROS5 PRINCIPAL my-principal
  AUTH KERBEROS5 INIT
  SET FTP AUTHTYPE GSSAPI-KRB5
  SET FTP AUTOAUTHENTICATE ON              ; default setting
  SET FTP AUTOENCRYPTION ON                ; default setting
  SET FTP AUTOLOGIN ON                     ; default setting
  SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting
  SET FTP DATA-PROTECTION-LEVEL PRIVATE    ; default setting
  FTP OPEN host /USER:username

     If the /USER switch is omitted, the user is prompted for the name
     to login as after authentication is performed.

     Here is an example using TLS to secure the FTP session for an
     anonymous user:

  SET AUTH TLS VERIFY-FILE ca-cert.pem
  SET FTP AUTHTYPE TLS
  SET FTP AUTOAUTHENTICATE ON              ; default setting
  SET FTP AUTOENCRYPTION ON                ; default setting
  SET FTP AUTOLOGIN ON                     ; default setting
  SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting
  SET FTP DATA-PROTECTION-LEVEL PRIVATE    ; default setting
  FTP OPEN host /ANONYMOUS

     Here is an example using FTP through an SSL Proxy Server:

  SET AUTH SSL VERIFY-FILE ca-cert.pem
  SET FTP AUTOLOGIN ON                     ; default setting
  SET FTP COMMAND-PROTECTION-LEVEL PRIVATE ; default setting
  SET FTP DATA-PROTECTION-LEVEL PRIVATE    ; default setting
  FTP OPEN /SSL host /USER:username /PASSWORD:password

     If the /USER and/or /PASSWORD switches are omitted, the user is
     prompted for the required fields.

    3.3.5. Making Secure HTTP Connections

     [ [305]Top ] [ [306]Contents ] [ [307]Chapter Contents ] [
     [308]Section Contents ] [ [309]Glossary ]

     Here is an example of a secure GET:

  SET AUTH TLS VERIFY-FILE ca-cert.pem
  HTTP OPEN host HTTPS
  HTTP /USER:username /PASSWORD:password GET index.html index.html
  HTTP CLOSE

    3.3.6. Using Only SSL or TLS

     [ [310]Top ] [ [311]Contents ] [ [312]Chapter Contents ] [
     [313]Section Contents ] [ [314]Glossary ]

     Secure Sockets Layer (SSL) and Transport Layer Security (TLS)
     protocols were designed to secure e-commerce transactions (HTTP)
     over the Internet. Their use as a tunnel protocol is becoming
     widespread as a means for securing other protocols such as FTP,
     IMAP, POP3, LDAP, NNTP, and even insecure versions of Telnet (this
     is frequently done with STunnel: [315]http://www.stunnel.org/.)
     Kermit provides the ability to establish SSL and TLS connections to
     transfer data, script HTTP sessions, or use Telnet protocol without
     the START_TLS option.

     Kermit provides four protocol-switches for establishing SSL or TLS
     connections: /SSL, /TLS, /SSL-TELNET, and /TLS-TELNET. Unlike other
     protocols such as TELNET and RLOGIN there are no standard services
     (IP ports) assigned to these protocols. Use of these protocols
     assumes prior knowledge of the ports to connect to on the remote
     host. There are also no shortcut commands for use with these
     protocols. Use the SET HOST command as described above when making
     connections.

     The [316]SET AUTHENTICATION { SSL, TLS }... commands are used to
     configure the [317]certificates and authorities, and verification
     options used during connection establishment.

     [ [318]STunnel Case Study ]

    3.3.7. Using Kerberos 5 User-to-User Protocol

     [ [319]Top ] [ [320]Contents ] [ [321]Chapter Contents ] [
     [322]Section Contents ] [ [323]Glossary ]

     The Kerberos 5 authentication implemented in the Telnet protocol is
     a client to server authentication protocol. It requires that the
     parties to the authentication be an end user principal and a
     service principal. The Kerberos 5 User to User protocol is
     specificly designed to allow two end user principals to
     authenticate one another. The shared secret generated during the
     authentication is then used to ensure the privacy of the data
     transmitted on the connection.

     There is no shortcut command provided for Kerberos 5 User to User
     protocol; nor is there a default service. To establish a connection
     between two Kermit processes using Kerberos 5 User to User
     protocol:

     * Each user must have retrieved a valid Kerberos 5 TGT.
     * One user must issue a SET HOST * port /K5USER2USER command.
     * One user must issue a SET HOST hostname port /K5USER2USER command.

     [ [324]C-Kermit ] [ [325]C-Kermit 8.0 ] [ [326]Kermit 95 ] [
     [327]Kermit Home ]
      ______________________________________________________________________

    3.4. Using Secure Connections

     [ [328]Top ] [ [329]Contents ] [ [330]Chapter Contents ] [
     [331]Glossary ]

     Once you have a secure connection, you can use it just like a
     regular (insecure one). Telnet sessions are Telnet sessions; FTP is
     FTP. However, encryption and the subsequent decryption of a data
     stream can result in 10% to 60% reduction in file transfer
     performance depending on the encryption algorithm. Encrypted data
     streams are uncompressible, thus reducing throughput on PPP or SLIP
     connections.

     When OpenSSL is built with support for ZLIB compression and
     compressed SSL/TLS connections can be negotiated, the degradation
     in file transfer performance can be reduced.

     In Kermit 95, the authentication type and encryption levels are
     displayed in the terminal-screen status Line as follows:

     K4 Kerberos IV
     K5 Kerberos V
     NTLM   NT LAN Manager
     SRP Secure Remote Password
     pp No encryption
     Ep Encryption to host, plaintext from host
     pD Plaintext to host, encryption from host
     ED Encryption both directions
     SSL Secure Sockets Layer (both directions)
     TLS Transport Layer Security (both directions)

     Encrypted sessions become unreadable if even one bit of data is
     inserted into or deleted from the data stream. One damaged bit
     results in nine damaged bytes but subsequent bytes remain readable.
     But since TCP/IP is a reliable transport by definition, none of
     this should occur.

     Windows login names are not case-sensitive. However, Unix login
     names are. If the Unix login name is "fred" but Windows was logged
     in using the name "Fred", authentication appears to succeed but
     telnetd closes the connection after Telnet negotiations are
     complete. There are several solutions to this problem:

     * Make sure the Windows login name is case identical to the Unix
       login name. (If Windows has recorded the login in the registry as
       "Fred" it won't matter if you login to Windows using "fred". The
       only way to correct this problem is to edit the Registry.)
     * Use the SET LOGIN USERID name command to set the proper login name
       before connecting to the telnet server.
     * Use the SET AUTHENTICATION { KERBEROS4, KERBEROS5 } PRINCIPAL name
       command to set the proper principal name before connecting to the
       telnet server.
     * Specify the remote username in the principal of your AUTHENTICATE
       Kxxx INITIALIZE command.

     Kermit adjusts the case of the name if and only if a case
     insensitive comparison of the SET LOGIN USERID name and the name in
     the authentication ticket shows no differences.

     [ [332]C-Kermit ] [ [333]C-Kermit 8.0 ] [ [334]Kermit 95 ] [
     [335]Kermit Home ]
    ________________________________________________________________________

  4. INSTALLATION AND CONFIGURATION

     [ [336]Top ] [ [337]Contents ] [ [338]Glossary ] [ [339]Appendices
     ] [ [340]Previous ]

     This chapter is intended for those who are building secure Kermit
     programs from source code and/or installing secure versions of
     Kermit for use within their organization. It presumes that you've
     read all the previous chapters.

     CHAPTER CONTENTS

  4.1. [341]Security in Kermit 95
  4.2. [342]Security in C-Kermit

  4.1. Security in Kermit 95

     Kermit 95 comes precompiled with support for Kerberos 4, Kerberos
     5, Secure Remote Password (SRP), NT Lan Manager (NTLM)
     authentication, OpenSSL's SSLv3 and TLSv1, and SSH v1 and v2.

     SECTION CONTENTS

  4.1.1. [343]Kerberos
  4.1.2. [344]SRP
  4.1.3. [345]NTLM
  4.1.4. [346]OpenSSL
  4.1.5. [347]SSH
  4.1.6. [348]Firewalls
  4.1.7. [349]Adding Other Security Methods to Kermit 95

  4.1.1. Kerberos in Kermit 95

     [ [350]Top ] [ [351]Contents ] [ [352]Chapter Contents ] [
     [353]Section Contents ] [ [354]Glossary ]

     Kermit 95 supports Kerberos Telnet Authentication, Kerberos Rlogin,
     Kerberos FTP, and Kerberos SSL/TLS (K5 only) when any of the
     following Kerberos IV or Kerberos V implementations are installed
     on a Windows 95 or Windows NT workstation:

        MIT Kerberos for Microsoft Operating Systems Release 2.1.1

          Supports Kerberos 4 and Kerberos 5 version 1.2.x:
                [355]http://web.mit.edu/kerberos/www/

        Naval Research Laboratories

          Supports Kerberos 5:
                [356]ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/README

     When Kerberos IV and/or Kerberos V are installed and the DLLs are
     located in the PATH, Kermit 95 attempts to negotiate authentication
     with the host if the host is Kerberized and if you have not
     instructed Kermit 95 to do otherwise.

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

  [357]http://www.kermit-project.org/noexport.html

     Due to the length of the shared secret negotiated by Kerberos 4
     only 56-bit DES encryption can be used.

     Per-PC configuration files may or may not be necessary at your
     installation. If your site's DNS servers supply Kerberos realm
     information, no configuration files are needed and you can skip to
     [358]Section 4.1.2.

  4.1.1.1. Kerberos IV Configuration Files for K95

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

KRB.CON:
  CC.COLUMBIA.EDU
  CC.COLUMBIA.EDU kerberos.cc.columbia.edu
  KERMIT.COLUMBIA.EDU kerberos.cc.columbia.edu
  COLUMBIA.EDU kerberos.cc.columbia.edu
  .KERBEROS.OPTION. dns

     The first line is the default Kerberos IV realm to be used. The
     subsequent lines list realms and the hostnames to be used to
     contact the KDC for that realm.

     The last line is an indicator that DNS can be used to map Realms to
     KDCs and host names to Realms.

KRBREALM.CON:
  .CC.COLUMBIA.EDU CC.COLUMBIA.EDU
  CC.COLUMBIA.EDU CC.COLUMBIA.EDU
  .COLUMBIA.EDU CC.COLUMBIA.EDU
  COLUMBIA.EDU CC.COLUMBIA.EDU
  .KERMIT.COLUMBIA.EDU CC.COLUMBIA.EDU
  KERMIT.COLUMBIA.EDU CC.COLUMBIA.EDU

     Each line specifies either a domain name prefaced with a "." or a
     host name and the Kerberos IV realm to which it belongs.

  4.1.1.2. The Kerberos V Configuration File for K95

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

[libdefaults]
        default_realm = CC.COLUMBIA.EDU
        default_tkt_enctypes = des-cbc-crc
        default_tgs_enctypes = des-cbc-crc
        ticket_lifetime = 600
        dns_fallback = true

[domain_realm]
        .cc.columbia.edu = CC.COLUMBIA.EDU
        cc.columbia.edu = CC.COLUMBIA.EDU
        .columbia.edu = CC.COLUMBIA.EDU
        columbia.edu = CC.COLUMBIA.EDU

[realms]
        CC.COLUMBIA.EDU = {
                kdc = kerberos.columbia.edu:88
                admin_server = kerberos.columbia.edu:749
                default_domain = cc.columbia.edu
                supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4
                supported_keytypes = des:normal des-cbc-crc:v4
        }

  4.1.2. Secure Remote Password protocol in Kermit 95

     [ [359]Top ] [ [360]Contents ] [ [361]Chapter Contents ] [
     [362]Section Contents ] [ [363]Glossary ]

     Kermit 95 supports Telnet Authentication via Secure Remote Password
     protocol without any additional software.

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

  [364]http://www.kermit-project.org/noexport.html

     Kermit 95 contains support for authenticating incoming connections
     using SRP. Unfortunately, there are no Windows based tools for
     creating the SRP password file. However, once a password and config
     file are created on Unix they can be copied to Windows. On Windows
     9x the tpasswd and tpasswd.conf files are stored in the C:\WINDOWS
     directory. On NT they are stored in %windir%\SYSTEM32\DRIVERS\ETC.

  4.1.3. NT LAN Manager Authentication in Kermit 95

     [ [365]Top ] [ [366]Contents ] [ [367]Chapter Contents ] [
     [368]Section Contents ] [ [369]Glossary ]

     NTLM authentication is a feature of Windows 95/98, NT, and Windows
     2000. It is used to authenticate Windows clients to Windows
     services. Telnet Auth NTLM is implemented in the Microsoft Telnet
     Daemon that ships with NT Services for Unix and with Windows 2000.

     Windows 95/98 only contains support for the client whereas NT
     contains support for both client and server. Kermit 95 can
     authenticate incoming connections with NTLM when it is executing on
     NT.

  4.1.4. OpenSSL support for SSLv3 and TLSv1 in Kermit 95

     [ [370]Top ] [ [371]Contents ] [ [372]Chapter Contents ] [
     [373]Section Contents ] [ [374]Glossary ]

     Kermit 95 supports SSL/TLS security via OpenSSL when the encryption
     patch (obtained from the Kermit Project) is installed. The
     encryption patch is available WITH EXPORT RESTRICTIONS at:

  [375]http://www.kermit-project.org/noexport.html

     On non-Unix platforms OpenSSL does not define default locations for
     certificates and revocation lists therefore the appropriate SET
     AUTH { SSL, TLS } commands must be given (e.g. included in the
     K95CUSTOM.INI or IKSD.KSC file) before certificate verification to
     be performed.

     As of Kermit 95 version 2.00 the default locations are provided as
     follows:
     * SET AUTH { SSL, TLS } VERIFY-DIR \v(exedir)certs
     * SET AUTH { SSL, TLS } VERIFY-FILE \v(exedir)ca_certs.pem
     * SET AUTH { SSL, TLS } CRL-DIR \v(exedir)crls
     * SET AUTH { SSL, TLS } CRL-FILE \v(exedir)ca_crls.pem

     Due to patent licensing restrictions on the IDEA algorithm within
     the United States, all binaries that the Kermit Project distributes
     to provide SSL/TLS support for Kermit 95 do not contain IDEA
     ciphers.

     See [376]Appendix III if you wish to provide server-side support
     for authentication of clients using public key certificates.

  4.1.5. SSH v1 and v2 in Kermit 95

     [ [377]Top ] [ [378]Contents ] [ [379]Chapter Contents ] [
     [380]Section Contents ] [ [381]Glossary ]

     (To be filled in...)

  4.1.6. Firewalls

     [ [382]Top ] [ [383]Contents ] [ [384]Chapter Contents ] [
     [385]Section Contents ] [ [386]Glossary ]

     The Windows versions of Kermit 95 do not support SOCKS; the OS/2
     version has built-in support for SOCKS4. NEC distributes a SOCKS5
     Winsock shim for Windows 9x/NT at:

  [387]ftp://ftp.nec.co.jp/pub/packages/sotools/

  4.1.7. Adding Other Security Methods to Kermit 95

     [ [388]Top ] [ [389]Contents ] [ [390]Chapter Contents ] [
     [391]Section Contents ] [ [392]Glossary ]

     Kermit 95 includes a DLL interface for adding new security methods.
     The DLL can be loaded with the SET NETWORK TYPE command:

  SET NETWORK TYPE DLL dll-file

     The connection is made with a SET HOST command:

  SET HOST command-line

     where the command-line is passed to the DLL after the normal Kermit
     quoting rules are applied. A C language skeleton for the DLL is
     available here:

  [393]http://www.columbia.edu/kermit/k95dll_c.txt
    ________________________________________________________________________

  4.2. Security in C-Kermit

     [ [394]Top ] [ [395]Contents ] [ [396]Chapter Contents ] [
     [397]Glossary ]

     SECTION CONTENTS

  4.2.1. [398]Kerberos
  4.2.2. [399]SRP
  4.2.3. [400]SSL/TLS
  4.2.4. [401]Shadow Passwords
  4.2.5. [402]PAM
  4.2.6. [403]Using External Security Methods with C-Kermit

     C-Kermit 8.0 can be compiled with support for Kerberos 4, Kerberos
     5, Secure Remote Password, and OpenSSL's SSLv3 and TLSv1. As of
     this writing the following combinations of platforms and security
     protocols are provided in the Makefile distributed with C-Kermit:

     * aix41+krb5+krb4
     * aix43gcc+krb5+krb4
     * aix43gcc+krb5+krb4+openssl
     * irix6x+krb5
     * irix65+krb5
     * linux+krb5
     * linux+krb5+krb4
     * linux+srp+gmp
     * linux+srp+gmp+no-des
     * linux+srp+gmp-export
     * linux+srp+gmp+pam
     * linux+srp
     * linux+srp+pam
     * linux+shadow+pam
     * linux+openssl
     * linux+openssl+shadow
     * linux+openssl+zlib+shadow+pam
     * linux+srp+openssl
     * linux+krb5+krb4+srp
     * linux+krb5+krb4+srp+openssl
     * linux+krb5+krb4+openssl
     * linux+krb5+krb4+openssl+shadow
     * linux+krb5+krb4+openssl+zlib+shadow
     * linux+krb5+krb4+srp-export
     * linux+krb5+krb4+srp+pam
     * linux+krb5+krb4+srp+openssl+pam-debug
     * linux+krb5+krb4+srp+openssl+pam
     * linux+krb5+krb4+srp+openssl+zlib+pam
     * linux+krb5+openssl+zlib+shadow+pam
     * redhat71
     * redhat71+srp
     * solaris2x+krb4
     * solaris2xg+krb4
     * solaris2xg+openssl+zlib+pam+shadow
     * solaris2xg+openssl+pam+shadow
     * solaris2xg+krb5+krb4+openssl+shadow
     * solaris25+krb4
     * solaris25g+krb4
     * solaris25g+krb5+krb4+openssl+shadow
     * solaris26g+openssl
     * solaris8g+openssl+zlib+pam+shadow
     * solaris8g+krb4
     * sunos41gcc+krb4
     * sunos41gcc+openssl
     * sunos41gcc+krb4+openssl
     * sunos41gcc+krb4+openssl+zlib
     * sunos41gcc+krb4+srp+openssl+zlib
     * sunos41gcc+srp+openssl+zlib
     * uw7ssl

  4.2.1. Kerberos in C-Kermit 8.0

     [ [404]Top ] [ [405]Contents ] [ [406]Chapter Contents ] [
     [407]Section Contents ] [ [408]Glossary ]

     Kerberos IV and Kerberos V support is available for Unix versions
     of C-Kermit 8.0. Kerberos support in C-Kermit is provided for both
     outgoing and incoming connections (SET HOST /SERVER * port /TELNET
     or the [409]Internet Kermit Service).

     Kerberized C-Kermit binaries are not available due to export
     restrictions (see [410]Section 2); you must build your own binary
     from a combination of Columbia source code and Kerberos libraries
     from other sources.

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

  [411]http://web.mit.edu/kerberos/www/
  [412]http://web.mit.edu/network/kerberos-form.html
    2. Choose a Kerberos 4 installation (from MIT) and retrieve a source
       code kit from the appropriate site:

  [413]http://web.mit.edu/kerberos/www/
  [414]http://web.mit.edu/network/kerberos-form.html
    3. Build and install Kerberos on your system according to the
       instructions that come with the Kerberos distribution you have
       chosen.
    4. Add a new entry to the C-Kermit makefile for your platform that
       uses "krbmit" as the build target and adds the following to
       CFLAGS:

  -DCK_AUTHENTICATION -DCK_KERBEROS

        For Kerberos 4 include:
                -DKRB4 $(K4INC)

        For Kerberos 5 include:
                -DKRB5 $(K5INC)

        For Kerberos 5 with Kerberos 4 compatibility mode:
                -DKRB5 -DKRB524 -DKRB4 $(K5INC)

        If you desire DES and 3DES encryption include:
                -DCK_ENCRYPTION -DCK_DES

        Add the appropriate libraries to LIBS. For Kerberos 4 include:
                $(K4LIB) -lkrb

        For Kerberos 5 include:
                $(K5LIB) -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto

        For Kerberos 4 compatibility mode with Kerberos 5 include:
                $(K5LIB) -ldes425 -lkrb4 -lgssapi_krb5 -lkrb5 -lcom_err
                -lk5crypto

        The makefile defines the path to the Kerberos header files using
                the variables K4INC or K5INC:
                -I/usr/kerberos/include

        The location of the Kerberos libraries is specified using the
                variables K4LIB or K5LIB:
                -L/usr/kerberos/lib

       The Kerberos header files and libraries are often installed in
       host specific locations. The values of the K4INC, K5INC, K4LIB,
       and K5LIB variables can be altered by:
          + Editing the makefile
          + Defining new values on the make command line
          + Exporting the variables to the system environment and
            specifying the -e on the make command line.
       Use the "linux+krb5", "linux+krb5+krb4", and "sunos41gcc+krb4"
       makefile entries as models.

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

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

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

  4.2.2. Secure Remote Password protocol in C-Kermit

     [ [416]Top ] [ [417]Contents ] [ [418]Chapter Contents ] [
     [419]Section Contents ] [ [420]Glossary ]

     Secure Remote Password (SRP) support is available for Unix versions
     of C-Kermit 8.0. SRP support in C-Kermit is provided for both
     outgoing and incoming connections (SET HOST /SERVER * port /TELNET
     or the Internet Kermit Service).

     SRP C-Kermit binaries are not available due to export restrictions
     (see [421]Section 2); you must build your own binary from a
     combination of Columbia source code and SRP libraries from other
     sources.

    1. Retrieve the SRP 1.7.4 source code kit from:

  [422]http://srp.stanford.edu/srp/
    2. There are several different methods for configuring the build
       process of SRP. Two methods are supported for use with C-Kermit.
       The recommended way is to build SRP using OpenSSL to provide the
       required big number math and cryptographic functionality. DES/3DES
       functionality is built into OpenSSL.
       The second method is to build SRP with the GNU MP library for big
       number math and use SRP's Krypto library for the cryptographic
       functionality. If
       Regardless of which method you decide to use, be sure to read the
       installation instructions before installing because SRP replaces
       many standard Unix system files and failure to follow the
       procedures may leave you locked out of your system.
    3. Add a new entry to the C-Kermit makefile for your platform that:
       uses "srpmit" as the build target and adds the following CFLAGS:

  -DCK_AUTHENTICATION -DCK_SRP $(SRPINC)

        If you built SRP with OpenSSL add:
                $(SSLINC)

        If you desire telnet encryption include:
                -DCK_ENCRYPTION

        For CAST encryption add:
                -DCK_CAST

        For DES and 3DES encryption add:
                -DCK_DES -DLIBDES

        Add the appropriate libraries to LIBS. If you built SRP using
                OpenSSL:
                $(SRPLIB) -lsrp -lkrypto $(SSLLIB) -lcrypto

        If you built SRP with GNU MP but without DES/3DES support use:
                $(SRPLIB) -lsrp -lgmp -lkrypto

        If you built SRP with GNU MP and Eric Young's DES library use:
                $(SRPLIB) -lsrp -lgmp -ldes -lkrypto

        The makefile defines the path to the SRP header files using the
                variable SRPINC:
                -I/usr/local/include

        The location of the Kerberos libraries is specified using the
                variable SRPLIB:
                -L/usr/local/lib

        The makefile defines the path to the OpenSSL header files using
                the variable SSLINC:
                -I/usr/local/ssl/include

        The location of the OpenSSL libraries is specified using the
                variable SSLLIB:
                -L/usr/local/ssl/lib

       The SRP and OpenSSL header files and libraries are often installed
       in host specific locations. The values of the SRPINC, SRPLIB,
       SSLINC, and SSLLIB variables can be altered by:
          + Editing the makefile
          + Defining new values on the make command line
          + Exporting the variables to the system environment and
            specifying the -e on the make command line.
       Use the "linux+srp" and "linux+krb5+krb4+srp" makefile entries as
       models.

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

     When C-Kermit 8.0 is built with SRP support and installed as an
     [423]Internet Kermit Service Daemon (IKSD), SRP is offered for
     authenticating incoming connections.

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

     [ [424]Top ] [ [425]Contents ] [ [426]Chapter Contents ] [
     [427]Section Contents ] [ [428]Glossary ]

     OpenSSL support is available for Unix versions of C-Kermit 8.0.
     SSLv3 and TLSv1 support in C-Kermit is provided for both outgoing
     and incoming connections (SET HOST /SERVER * port /TELNET or the
     [429]Internet Kermit Service).

     OpenSSL C-Kermit binaries are not available due to export
     restrictions (see [430]Section 2); you must build your own binary
     from a combination of Columbia source code and the OpenSSL
     libraries from other sources.

    1. Retrieve the OpenSSL 0.9.6b source code kit from:

  [431]http://www.openssl.org/
    2. Build OpenSSL according to the installation instructions. Be aware
       that OpenSSL includes support for algorithms that are covered by
       patents or claimed as intellectual property in the United States
       (and perhaps some other countries.) Use of these algorithms
       without the proper licenses can make you liable to legal action.
       Be sure to read the entire README file before building and
       installing OpenSSL.
       OpenSSL has many features that can be selected when it is
       configured prior to compiling the libraries. One feature that's
       useful to C-Kermit is support for Anonymous-Diffie-Hellman (ADH)
       ciphers in SRP and Kerberos 5 Telnet Authentication.
       Note: If you are using a version of OpenSSL later than SNAPSHOT
       20011201 you can build it with support for ZLIB compression and
       Kerberos 5 ciphers. However, OpenSSL releases prior to version 1.0
       are not guaranteed to be backward compatible. C-Kermit 8.0 builds
       with any 0.9.6 version of OpenSSL. C-Kermit 8.0 might not build
       with future versions of OpenSSL without modification.
    3. Add a new entry to the C-Kermit makefile for your platform that
       uses "krbmit" as the build target and adds the following to
       CFLAGS:

  -DCK_AUTHENTICATION -DCK_SSL $(SSLINC)
   To add support for ZLIB compression add the following to CFLAGS:
       -DZLIB
   Add the appropriate libraries to LIBS:
       $(SSLLIB) -lssl -lcrypto
   For ZLIB compression add to LIBS:
       -lzlib
   The makefile defines the path to the OpenSSL header files using the
       variable SSLINC:
       -I/usr/local/ssl/include
   The location of the OpenSSL libraries is specified using the variable
       SSLLIB:
       -L/usr/local/ssl/lib
       The OpenSSL header files and libraries are often installed in host
       specific locations. The values of the SSLINC and SSLLIB variables
       can be altered by:
          + editing the makefile
          + defining new values on the make command line
          + exporting the variables to the system environment and
            specifying the -e on the make command line.
       Use the "linux+openssl" and "linux+krb5+krb4+srp+openssl" makefile
       entries as models.

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

     When C-Kermit 8.0 is installed as an Internet Kermit Service
     (IKSD), TLSv1 is offered for authenticating incoming connections
     via the Telnet START_TLS option.

     If you wish to provide support for authentication of clients using
     public key certificates you must provide two custom functions
     X509_to_user() and X509_userok. These functions provide the
     certificate to local userid mapping and user authorization
     functionality. Example functions that use the /UID field of the
     Certificate Subject name may be activated by specifying:

  make entry KFLAGS=-DX509_UID_TO_USER

     when compiling C-Kermit. If you with to use the Certificate Subject
     Alternate Name you can specify:

  make entry KFLAGS=-DX509_SUBJECT_ALT_NAME_TO_USER

     The X509_to_user() and X509_userok() functions are the last
     functions in the ck_ssl.c module. See [432]Appendix III.

  4.2.4. Shadow Passwords in C-Kermit 8.0

     [ [433]Top ] [ [434]Contents ] [ [435]Chapter Contents ] [
     [436]Section Contents ] [ [437]Glossary ]

     Shadow password files are used in many versions of Unix to provide
     a greater level of security for user passwords stored on the local
     disk. The standard Unix password file must be world readable so
     processes can find out the user's shell, home directory, and other
     permissions. By moving the passwords into a separate file that only
     stores passwords, access to the file can be restricted to only
     those processes that are authorized to perform authentication.

     When C-Kermit 8.0 is used as the Internet Kermit Service on systems
     that are configured to use shadow passwords the following CFLAG
     must be added to the makefile entry:

  -DCK_SHADOW

  4.2.5. Pluggable Authentication Module (PAM) Support in C-Kermit 8.0

     [ [438]Top ] [ [439]Contents ] [ [440]Chapter Contents ] [
     [441]Section Contents ] [ [442]Glossary ]

     PAM is implemented in many versions of Unix so system
     administrators can add new forms of authentication for interactive
     login (console, telnet, rlogin, ...) without requiring
     recompilation of each service.

     When C-Kermit 8.0 is used as the Internet Kermit Service on systems
     that are configured to use PAM the following CFLAG must be added to
     the makefile entry:

  -DCK_PAM

     and the following libraries may have to be included:

  -lpam -ldl

     The default PAM Service Name is "kermit". If you wish to use a
     different name specify:

  KFLAGS=-DPAM_SERVICE_NAME="service-name"

     when building C-Kermit.

     Before C-Kermit can be used with PAM, configuration information
     must be added for the specified PAM_SERVICE_NAME to either
     /etc/pam.conf or /etc/pam.d/ depending on the version of PAM your
     operating system has installed. A complete primer on PAM can (or
     once could be) be found at:

  [443]http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/.

  4.2.6. Using External Security Methods with C-Kermit

     [ [444]Top ] [ [445]Contents ] [ [446]Chapter Contents ] [
     [447]Section Contents ] [ [448]Glossary ]

     Other protocols can be used to create secure connections that are
     not currently implemented in Kermit, such as Secure Shell (SSH).
     The fact that SSH is not integrated into Kermit software does not
     mean that Kermit cannot be used in conjunction with it. SSH
     provides for tunneling, which allows a localhost proxy to be
     configured to take insecure connections on the local machine and
     connect them via secure connections to remote hosts.

     Secure connection clients can be used as the communication channel
     in C-Kermit 7.0 and later and Kermit 95 1.1.16 and later via the
     PTY (Unix only) and PIPE commands. See [449]Section 2.7 of the
     [450]C-Kermit 7.0 Update Notes for details.

     Firewalls based on access lists, proxies, and SOCKS do not provide
     secure connections. However, they do restrict the ports that may be
     used to communicate between the Internet and the Intranet which
     makes it more difficult for someone to break into the Intranet from
     outside. They do not protect the network from internal attacks nor
     do they protect a connection, once made, from eavesdropping or
     hijacking. They may be used in conjunction with secure connection
     systems but should not be used as a replacement for them. C-Kermit
     can be built as a SOCKS client if you have a SOCKS library;
     otherwise you can run SOCKSified Telnet or Rlogin clients through
     C-Kermit with the PIPE command. See [451]C-Kermit Configuration
     Options document for details.

     [ [452]C-Kermit ] [ [453]C-Kermit 8.0 ] [ [454]Kermit 95 ]
    ________________________________________________________________________

  APPENDIX I. WHERE TO FIND SECURE TELNET AND FTP SERVERS

     [ [455]Top ] [ [456]Contents ] [ [457]Glossary ] [ [458]Home ]

     CONTENTS

  I.1. [459]Telnet
  I.2. [460]FTP
  I.3. [461]Internet Kermit Service
  I.4. [462]HTTP
  I.5. [463]Securing Insecure Services with STunntl

     Contrary to widespread misconception, Telnet and FTP are not
     insecure protocols to be discarded. These protocols have been
     secured by the IETF through the addition of standard security
     methods: Kerberos, SSL/TLS, and SRP (see [464]REFERENCES) and
     continue to offer manifold advantages over their would-be
     replacements in terms of functionality, flexibility, and platform
     independence. If your operating system does not include secure
     remote access methods, secure third-party servers can often be
     found.

  I.1. Secure Telnet Servers

     [ [465]Top ] [ [466]Contents ] [ [467]Appendix Contents ] [
     [468]Glossary ]

   Sun Solaris 8 and later
          Ships with a Kerberos 5 enabled Telnetd.

   Apple Mac OS X
          Ships with a Kerberos 5 enabled Telnetd.

   Cisco IOS
          The telnet server for Cisco routers, terminal servers, ...
          ships with Kerberos 5 support.

   SCO (Caldera) OSR5, Unixware 7, and Open UNIX 8
          Ships with Kerberos 5 support.

   Z/OS V1R2.0 Communication Server for Server/390 IP
          Ships with Kerberos 5 support:


  [469]http://www-1.ibm.com/servers/eserver/zseries/zos/commserver/kerberos.htm
l

   Debian and Red Hat Linux
          Recent versions ship with Kerberos 5 support.

   HP-UX 11
          Ships with Kerberos 5 support.

   Compaq DCE for OpenVMS
          provides Kerberos 5 support.

   MIT Kerberos 5 1.2.3
          The Kerberos 5 Telnet server is part of the standard Kerberos 5
          distribution available from MIT. Kerberos 5 is unique among
          authentication methods in offering true single sign-on
          capability to the network via forwarded credentials. It also
          allows authentication to cross Kerberos realms; for example,
          between different organizations.

          The Kerberos 5 Telnet server is "downwards compatible" with the
          older Kerberos 4 protocol. The Kerberos 5 Telnet authentication
          protocol provides for strong mutual authentication of the
          client and server without requiring the client to possess prior
          knowledge of the server's credentials. During authentication a
          session key (DES, RC4, 3DES) is produced that is used with a
          negotiated encryption algorithm to give privacy protection to
          incoming and outgoing data.

  [470]http://web.mit.edu/kerberos/www/

          Follow the links to "Getting Kerberos from MIT". Future
          versions of the MIT Kerberos 5 distribution will include
          support for SSL/TLS and X Windows System Data Forwarding.

   MIT Kerberos 4
          The precursor to Kerberos 5. Kerberos 4 provides strong
          authentication without the single sign-on or cross-realm
          capabilities of Kerberos 5. The Kerberos 4 Telnet server is
          part of the Kerberos 4 distribution.

          The Kerberos 4 Telnet authentication protocol provides for
          strong mutual authentication of client and server without
          requiring prior knowledge by the client of the server's
          credentials. During authentication a session key (56-bit DES
          only) is produced for use with a negotiated encryption
          algorithm for privacy of incoming and outgoing data.

  [471]http://web.mit.edu/kerberos/www/

          Follow the links to "Getting Kerberos from MIT".

   Secure Remote Password
          SRP is based on Zero Knowledge Identification algorithms by
          which the client and server prove their identities by
          exchanging data over a public channel. This data can't be used
          to determine the secrets involved nor can it be used to
          replicate the authentication sequence. Authentication of the
          server does not require the client to have prior knowledge of
          the server's credentials. During authentication a session key
          (320-bits) is produced for use with a negotiated encryption
          algorithm to provide privacy protection to incoming and
          outgoing data. As of the 1.7.1 release, the SRP Telnet client
          and server implement the START_TLS option as well as the X
          Windows Systems Data Forwarding option. This distribution can
          be built against MIT Kerberos 5 or MIT Kerberos 4 distribution
          to enable Kerberos authentication. The combination of START_TLS
          and AUTH (SRP and KRB5) provide for the strongest combination
          of private communication and password based mutual authentication.

          The SRP Telnet server is part of the SRP distribution:

  [472]http://www-cs-students.stanford.edu/~tjw/srp/

          Follow the link to Download Software

   Transport Layer Security (X.509 certificates and Kerberos 5)
          TLSv1 (the successor to SSLv3 used in most Web browsers)
          provides strong encryption and optional authentication of the
          server and client using X.509 certificates or Kerberos 5.
          Authentication of the server via X.509 requires the client to
          have prior knowledge of the server's X.509 certificate or the
          certificates of the Certificate Authorities that signed the
          server's certificate. An open source distribution of TLSv1 is
          available from:

  [473]http://www.openssl.org/

          Current development snapshots of OpenSSL are required for
          Kerberos 5 support. A Telnet server that implements the
          START_TLS option and X Windows System Data Forwarding is
          available from:

  [474]ftp://ftp.runestig.com/pub/starttls/start_tls-telnet.current.tar.gz
    ________________________________________________________________________

  I.2. Secure FTP Servers

     [ [475]Top ] [ [476]Contents ] [ [477]Appendix Contents ] [
     [478]Glossary ]

   MIT Kerberos 5 1.2.3
          The Kerberos 5 FTP server is part of the standard Kerberos 5
          distribution available from MIT. Kerberos 5 is unique among
          authentication methods in offering true single sign-on
          capability to the network via forwarded credentials. It also
          allows authentication to cross Kerberos realms; for example,
          between different organizations.

          The Kerberos 5 FTP server provides for strong authentication
          using either Kerberos 4 or GSSAPI-Kerberos 5. Both the command
          and data channels are encrypted and integrity protected.

  [479]http://web.mit.edu/kerberos/www/

          Follow the links to "Getting Kerberos from MIT". Future
          versions of the MIT Kerberos 5 distribution will include
          support for SSL/TLS and X Windows System Data Forwarding.

   MIT Kerberos 4
          The precursor to Kerberos 5. Kerberos 4 provides strong
          authentication without the single sign-on or cross-realm
          capabilities of Kerberos 5. The Kerberos 4 Telnet and FTP
          clients and servers are part of the Kerberos 4 distribution.

          The Kerberos 4 FTP server provides for strong authentication.
          Both the command and data channels are encrypted and integrity
          protected.

  [480]http://web.mit.edu/kerberos/www/

          Follow the links to "Getting Kerberos from MIT".

   Secure Remote Password
          SRP is based on Zero Knowledge Identification algorithms by
          which the client and server prove their identities by
          exchanging data over a public channel. This data can't be used
          to determine the secrets involved nor can it be used to
          replicate the authentication sequence. Authentication of the
          server does not require the client to have prior knowledge of
          the server's credentials. During authentication a session key
          (320-bits) is produced for use with a negotiated encryption
          algorithm to provide privacy protection to incoming and
          outgoing data.

          The FTP server provides for strong authentication. Both the
          command and data channels are encrypted and integrity protected
          with a user selectable set of encryption algorithms (blowfish,
          cast-128, 3des, des) and hash algorithms (md5, sha-1).

  [481]http://www-cs-students.stanford.edu/~tjw/srp/

          Follow the link to Download Software

   Transport Layer Security (X.509 certificates and Kerberos 5)
          TLSv1 (the successor to SSLv3 used in most Web browsers)
          provides strong encryption and optional authentication of the
          server and client using X.509 certificates or Kerberos 5.
          Authentication of the server via X.509 requires the client to
          have prior knowledge of the server's X.509 certificate or the
          certificates of the Certificate Authorities that signed the
          server's certificate. An open source distribution of TLSv1 is
          available from:

  [482]http://www.openssl.org/

          Current development snapshots of OpenSSL are required for
          Kerberos 5 support.

          Two FTP servers that implement the SSL/TLS protocol for
          securing both the command and data channels are available from:

  [483]ftp://ftp.runestig.com/pub/ftp-tls/
  [484]ftp://ftp.runestig.com/pub/ftpd-tls/
  [485]ftp://ftp.runestig.com/pub/proftpd-tls/
    ________________________________________________________________________

  I.3. Secure Internet Kermit Service

     [ [486]Top ] [ [487]Contents ] [ [488]Appendix Contents ] [
     [489]Glossary ]

     Available from Columbia University:

     * [490]User Documentation
     * [491]Administrator Documentation
     * (coming soon) Windows version...

  I.4. Secure HTTP Servers

     [ [492]Top ] [ [493]Contents ] [ [494]Appendix Contents ] [
     [495]Glossary ]

     Most web servers provide support for SSL/TLS secured HTTP
     connections.

  I.5. Securing Insecure Services with STunnel

     [ [496]Top ] [ [497]Contents ] [ [498]Appendix Contents ] [
     [499]Glossary ]

     It is also possible to wrap a nonsecure service such as Telnet or
     Sredird in [500]Stunnel, for use with Kermit's ability to negotiate
     non-secure protocols over SSL/TLS; [501]CLICK HERE for a case
     study.
    ________________________________________________________________________

  APPENDIX II. MULTI-HOMED HOSTS, FIREWALLS, AND NETWORK ADDRESS TRANSLATION

     [ [502]Top ] [ [503]Contents ] [ [504]Glossary ]

     CONTENTS

  II.1. [505]Firewalls
  II.2. [506]Network Address Translation
  II.3. [507]Multi-Homed Hosts and Aliasing

     The Internet was originally designed for end-to-end communication
     between connected computers belonging to a single cloud. All
     computers were able to directly communicate with all the other
     computers attached to the network. In particular, if computer A
     could communicate with computer B then computer B could communicate
     with computer A. Unfortunately, this no longer true.

     Three factors changed this. First, the abuse of the Internet by
     hackers and virus/worm authors convinced organizations that wished
     to join the internet that it was not safe to do so without limiting
     their exposure. This resulted in the popular use of firewalls to
     restrict the types of communications that could flow across the
     Internet gateways.

     The second factor was the success of the world wide web and the use
     of client only computers that did not have permanent addresses.
     These computers (mostly DOS, Windows, and Macintosh) did not run
     services and were only used to communicate with a very small number
     of server computers that spoke HTTP. Connectivity to these machines
     only required one way communication: from the client to the server.

     The third factor was the explosion in the number of client devices
     that are connected to the Internet. When an individual or company
     wants to connect their computers to the Internet they need to be
     assigned IP addresses for their computers. However, most ISPs sell
     service based on the number of assigned IP addresses or, in the
     case of home networks, provide only a single address. To save money
     or simply two put all the kids' computers on the network at the
     same time, people started to experiment with network gateways that
     implemented Network Address Translation (NAT). The NAT would
     convert the IP addresses of multiple computers on the private side
     of the gateway to share a single address on the public side of the
     gateway. A computer that has been assigned an address that is being
     translated can establish and listen for connections with other
     computers on the private side of the network and can establish
     connections to computers on the public side of the network.
     However, the computers cannot receive connections established from
     computers on the pubic side of the network because the true address
     of the computer has been hidden.

     These factors complicate the use of many Internet protocols such as
     FTP and cause problems for authentication systems. In addition to
     these problems there are some other issues that must be taken into
     account. It is possible for a single computer to have multiple
     network adapter cards. This is often done to allow a computer to
     act as a gateway between two networks; to provide the computer with
     redundancy for critical services; or to allow the computer to
     maintain more than one identity (such as to provide web services
     for two different domains.) Computers with multiple network
     addresses are referred to as being "multi-homed".

     There are also potential problems caused when multiple computers
     are used to serve a single purpose. For instance, a web server for
     a large commercial operation probably does not have a single
     computer providing service to all of their customers. Instead they
     have a farm (or cluster) of computers. The one you actually are
     served by is determined randomly using a load-balancing algorithm.
     When you authenticate to one of these computers you do not want to
     authenticate to the individual name assigned to each computer but
     to the common name used to access any one of them. The technique
     used to allow multiple computers to respond to a single name is
     called "aliasing".

  II.1 Firewalls

     [ [508]Top ] [ [509]Contents ] [ [510]Appendix Contents ] [
     [511]Glossary ]

     Firewalls are used to restrict the types of network packets that
     may cross a network boundary. Firewall products fall into four
     general categories:

   Port Filtering Firewalls
          Port Filtering firewalls are the simplist of the firewall
          techniques. Port filtering is performed by specifying an
          ordered set of ACCEPT and DENY rules for each combination of:

          + packet type
          + source address
          + source port
          + destination address
          + destination port
          + if packet type is TCP, whether a connection must exist or not

          This allows a firewall to be configured to only allow through
          the firewall packets that are meant for specific computers; or
          packets meant for specific services; or packets to/from
          specific hosts/networks.

          Port Filtering firewalls frequently cause problems for users of
          Kerberos authentication when they are not configured to allow
          UDP packets to be sent or received from the Key Distribution
          Center.

          Port Filtering firewalls are also a problem for the FTP
          protocol since the standard mode is for the FTP server to
          establish a data channel on a random port number to the FTP
          client when data is to be transferred. This port number is
          agreed to be sending the destination address and port value
          across the FTP command channel.

          Port Filtering firewalls need to be configured to allow
          connections from clients to reach the host ports necessary for
          each protocol that is used with Kermit:

     Port Protocol
     21/tcp FTP
     22/tcp SSH
     23/tcp Telnet
     80/tcp HTTP
     88/udp Kerberos 5 authentication
     443/tcp HTTP over TLS
     750/udp Kerberos 4 authentication
     990/tcp FTP over TLS
     992/tcp Telnet over TLS
     1649/tcp Internet Kermit Service (Kermit)

          The official list of "well-known" and "registered" port
          assignments is available from Internet Assigned Numbers
          Authority:

  [512]http://www.iana.org/assignments/port-numbers

   Content-Aware Firewalls
          Content-Aware Firewalls attempt to solve the problem with FTP
          and similar protocols that transmit addressing information as
          part of the protocol. These firewalls are aware of a specific
          set of internet protocols such as FTP. When the FTP client
          specifies the destination address and port to used by the
          server to establish the data channel, the firewall can watch
          and temporarily allow that connection to pass through the
          firewall. Unfortunately, Content Aware Firewalls cannot work
          with secure protocols since all of the data is being
          transmitted in encrypted form.

   Application Layer Gateways
          Application Layer Gateways are services that appear to be the
          actually service you wish to connect to. Instead of connecting
          directly to the telnet service on foo.bar.com you connect to
          the telnet service on the firewall and allow the firewall to
          establish an equivalent session with the telnet service on
          foo.bar.com.

          As with Content-Aware Firewalls this procedure simply does not
          work with secure connections. The Application Layer Gateway
          (ALG) will either not know the key to use to read the protected
          data; or the ALG will be able to decrypt all of the data and
          the end-to-end security of the connection know has a location
          where a man-in-the-middle attack can be targeted.

   Authenticated Firewall Traversal Protocols
          Authenticated Firewall Traversal Protocols simply allow a
          client process running on a computer to create connections that
          may cross the firewall once the client or service has been
          authenticated and authorized. These firewalls are quite
          flexible and work very well with secure connections. In fact,
          they enhance the security of the connection from the
          perspective of the network administrator.

    II.1.1 FTP Passive Mode

     [ [513]Top ] [ [514]Contents ] [ [515]Appendix Contents ] [
     [516]Glossary ]

     FTP is one of the few well-known Internet services that requires
     the use of multiple connections. As described above, FTP originally
     required the server to establish the data connection to the client
     using a destination address and port provided by the client. This
     method of operation does not work with Port Filtering Firewalls.

     More recently, FTP was extended to support "passive mode". When
     passive mode is use the connections for the data channels are
     created in the reverse direction. Instead of the server
     establishing a connection to the client; the client establishes a
     second connection with server as the destination. This works just
     fine as long as the client is behind the firewall and the server is
     in public address space. If the server is behind a firewall then
     the traditional mode must be used. If both the client and server
     are each behind their own Port Filtering Firewalls then data
     channels cannot be established.

     This is supposed to be solved by the use of Content Aware Firewalls
     or Application Layer Gateways. However, was the command channel is
     encrypted the Firewall is unable to view the IP address
     information.

     In Kermit, the use of passive mode is controlled with the command:

  SET FTP PASSIVE-MODE { ON, OFF }

     The default is to use passive mode.

    II.1.2 Firewall Traversal via an HTTP Proxy

     [ [517]Top ] [ [518]Contents ] [ [519]Appendix Contents ] [
     [520]Glossary ]

     The simplist form of firewall traversal is the HTTP CONNECT
     command. The CONNECT command was implemented to allow a public web
     server which usually resides on the boundary between the public and
     private networks to forward HTTP requests from clients on the
     private network to public web sites. In order to allow secure web
     connections to be established, the CONNECT command works by
     authenticating the client with a username/password and then
     establishing a tunnel to the desired host.

     Many web servers support the CONNECT command and it can be
     configured to allow outgoing connections to authenticated user to
     any TCP/IP hostname/port combination accessible to the web server.
     The limitations of HTTP CONNECT is that it can only be used for
     outgoing connections for protocols that are implemented using
     TCP/IP. Protocols such as Kerberos authentication that use UDP/IP
     cannot be tunneled using HTTP CONNECT.

     Kermit provides support for the use of HTTP CONNECT proxy services
     with the command:

  SET TCP HTTP-PROXY hostname/ip-address[:port]

     When a port is not specified the default port configured on the
     HTTP server is used. This is frequently port 443. When a hostname
     is specified, it is resolved using the DNS available to the web
     server.

    II.1.3 Firewall Traversal with SOCKS

     [ [521]Top ] [ [522]Contents ] [ [523]Appendix Contents ] [
     [524]Glossary ]

     In the early 1990s as firewalls were becoming prevalent, David
     Koblas developed the SOCKS protocol for firewall traversal of
     TCP/IP. There are two popular versions of SOCKS currently in use.
     Version 4.2 provides support for client applications using TCP/IP
     to traverse firewalls. This functionality is similar to the support
     provided by HTTP CONNECT. However, there is one distinction. A
     client using SOCKS is aware of the public source IP address and
     port. This allows this information to be used within the
     application protocol to assist in securing the connection. (This
     information is crucial to securing FTP sessions with GSSAPI
     Kerberos 5.)

     After 1995, the IETF began working on a successor to the SOCK 4
     protocol. This work produced SOCKS Version 5 ([525]RFC 1928). SOCKS
     5 is significantly more general than version 4. In addition to
     supporting client to server TCP/IP connections, it provides two
     crucial sets of functionality not found in previous protocols:

     * Authenticated firewall traversal of UDP/IP packets.
     * Authenticated binding of incoming public ports on the firewall.

     This allows a service on the private network to offer public
     services. It also allows client applications such as FTP to
     establish a temporary public presence that can be used by the FTP
     server to create a data channel. By allowing the client bind to a
     public port on the firewall and be aware of the public address,
     SOCKS 5 allows the application protocol to communicate that
     information to the server.

     C-Kermit can be built using either SOCKS 4 or SOCKS 5.
     Configuration of the SOCKS servers is determined by the
     requirements of the SOCKS library.

     Kermit 95 2.00 supports SOCKS 4.2. The SOCKS Server is specified
     with the command:

  SET TCP SOCKS-SERVER hostname/ip-address

     It should be noted that the best part about the SOCKS protocols is
     that each and every application does not need to implement them.
     Instead, SOCKS can be built into the IP stack on each host
     operating system and the protocols could work transparently without
     any change to the programs already shipped.

  II.2 Network Address Translation

     [ [526]Top ] [ [527]Contents ] [ [528]Appendix Contents ] [
     [529]Glossary ]

     Network Address Translation (NAT) is a technique used to allow a
     single public IP address provided by an Internet Service Provider
     (ISP) to be shared among multiple computers on a private IP based
     network. NAT technology is often found in routers designed for the
     Home and Small Office market. This technique is wonderful as long
     as the application protocols being used do not require knowledge of
     the IP addresses being used. In fact, NATs when combined with SOCKS
     Version 5 would be a perfect solution except that we have never
     seen a product that combines these two technologies. (It is most
     likely a chicken-and-egg situation. No client applications support
     SOCKS 5, therefore no router manufacturers feel pressure to produce
     them. Since no routers support SOCKS 5, application vendors do not
     implement it.)

     NAT has particularly bad implications for Kerberos authentication
     that traditionally embeds into the ticket the IP addresses on which
     the ticket is valid. Another protocol that is adversely affected by
     NAT is FTP. However, FTP passive mode works around it.

     As luck would have it. Kerberos 4 has no problem with NAT because
     the Kerberos 4 ticket has room for only a single IP address and
     that IP address is assigned not by the client but by the KDC. The
     result is that when Kerberos 4 is used from behind a NAT the IP
     address that is placed into the ticket is the public IP address of
     the NAT, not the IP address of the client machine. This means the
     ticket is good only on the far side of the NAT and not on the near
     side.

     Kerberos 5 on the other hand is seriously affected by NAT. The
     addresses are stored in the ticket by the client. This allows the
     ticket to support the multiple addresses needed for multi-homed
     systems. However, when NAT is used, it is the private IP address
     that is stored into the ticket and not the public address seen by
     the KDC. If this ticket is now used to access a service on the
     public network, the service rejects the Kerberos 5 ticket since the
     IP address in the ticket does not match the source IP address used
     to establish the connection.

     This can be worked around if the client uses a kinit that allows a
     list of additional IP addresses to be specified for inclusion in
     the TGT. Kermit supports this capability with one of the following
     commands:

  AUTH K5 INIT /ADDRESSES:{list-of-addresses}
  SET AUTH K5 ADDRESSES {list-of-addresses}

     The problem with this solution is that, although it is secure, in
     most cases the end user does not know which IP address is assigned
     to the far side of the NAT. In this situation it is necessary to
     remove all IP addresses from the TGT. Kermit provides the AUTH K5
     INIT /NO-ADDRESSES and SET AUTH K5 NO-ADDRESSES ON commands for
     this purpose. However, this solution is less secure since a TGT
     with no specified IP addresses can be used from any machine. Stolen
     TGTs are therefore extremely useful to a thief. We strongly advise
     that removing the IP address information from Kerberos 5 tickets
     not be performed on computers using file based caches as they are
     particularly vulnerable to theft.

     Sometimes it is possible to read the public address from the device
     providing NAT, as shown in the following Kermit script:

  [530]ftp://kermit.columbia.edu/kermit/scripts/ckermit/linksys

     For those interested in more technical information on the
     consequences of Network Address Translation, the IETF has several
     Informational RFCs on the subject:

   Architectural Implications of NAT
          [531]ftp://ftp.isi.edu/in-notes/rfc2993.txt

   IP Network Address Translator (NAT) Terminology and Considerations
          [532]ftp://ftp.isi.edu/in-notes/rfc2663.txt

   Traditional IP Network Address Translator (Traditional NAT)
          [533]ftp://ftp.isi.edu/in-notes/rfc3002.txt

   NAT Friendly Application Design Guidelines
          [534]http://www.ietf.org/internet-drafts/draft-ietf-nat-app-gui
          de-06.txt

   Keith Moore's "What NATs Break"
          [535]http://www.cs.utk.edu/~moore/what-nats-break.html

  II.3 Multi-Homed Hosts and Aliasing

     [ [536]Top ] [ [537]Contents ] [ [538]Appendix Contents ] [
     [539]Glossary ]

     IP socket connections are established using IP addresses and port
     numbers. Human beings do not remember large groups of numbers well.
     Instead we remember do a better job remembering names. The Domain
     Name Service (DNS) is globally distributed database that converts
     between the names that humans recognize and the IP addresses that
     allow the desired service to be communicated with.

     There are two situations where multiple IP addresses can be
     associated with the same computer or service. The first is a
     computer that has multiple network interfaces. This is known as a
     multi-homed computer. Each interface is assigned its own IP
     address. The second situation is where a DNS name resolves to
     multiple computers. This is referred to as aliasing. Both can play
     havoc with authentication when using either Kerberos or X.509
     certificates. Kermit is designed to support multi-homed computers
     and those with multiple names. Unfortunately, not everything else
     is.

     Kerberos 4 does not support multi-homed computers. Its ticket
     format only has space for a single IP address. If you are using
     Kermit as a client with Kerberos 4 authentication you must be sure
     to set the network interface you use for establishing your
     connections to match the one stored in the Kerberos 4 ticket. The
     ticket address can be viewed with the command:

  AUTH K4 LIST

     The interface to be used can be configured with:

  SET TCP ADDRESS

     There is no method for automating this process at the current time.

     Kerberos 5 has no problem with multihomed hosts because the ticket
     supports multiple IP addresses and those IP addresses are inserted
     into the ticket by the client, not by the KDC.

     There can also be problems when a host is being accessed through a
     DNS alias. The administrator for the host needs to install the
     service keys for both the unique hostname and the alias name in the
     Kerberos 4 service key file. When this is not done it can lead to
     problems because the service key retrieved by the client does not
     match the one used by the service.

     Kermit attempts to compensate for this by resolving the DNS alias
     the to real hostname. However, this does not always work on Windows
     95 or Windows NT 3.5x due to their caching of DNS information. For
     instance, at Columbia University the CUNIX name resolves to one of
     six machines, each with a different name, such as HOSTA, HOSTB,
     etc. When telneting to CUNIX, you might be given IP address
     128.59.35.136. But even though the DNS servers are properly
     configured to return the proper name (e.g. HOSTB) for that IP
     address, Windows 95 returns CUNIX because it retrieves the
     information from its internal cache instead of performing another
     network call. This means that instead of retrieving a Kerberos 4
     ticket for the service:

  [e-mail]

     we get a ticket for:

  [e-mail]

     This use of the wrong ticket produces the following error:

  Can't decode authenticator (krb_rd_req)

     DNS aliases and multiple addresses can be a problem for connections
     protected with SSL/TLS. To maximize their revenue streams, most
     commercial certificate authorities do not issue certificates with
     multiple hostnames and/or IP addresses. Therefore the hostname used
     to access the service has to match the one that used in the
     certificate. Although Kermit can resolve aliases to unique
     hostnames for Kerberos, it cannot do so for X.509 certificates.

     When you are acting as your own Certificate Authority using the
     OpenSSL tools you can produce certificates containing multiple
     hostnames and IP addresses. Kermit authenticates connections
     correctly when presented with these certificates.

     [ [540]C-Kermit ] [ [541]C-Kermit 8.0 ] [ [542]Kermit 95 ] [
     [543]Kermit Home ]
    ________________________________________________________________________

  APPENDIX III: INTRODUCTION TO CERTIFICATES WITH OPENSSL

     [ [544]Top ] [ [545]Contents ] [ [546]Glossary ]

     CONTENTS

  III.1.  [547]What Are Certificates (etc)...?
  III.2.  [548]RSA vs DSA Certifications
  III.3.  [549]Should You Be Your Own Certificate Authority?
  III.4.  [550]Generating a DSA CA (self-signed) Certificate
  III.5.  [551]Generating a DSA CSR
  III.6.  [552]Generating an RSA CA (self-signed) certificate
  III.7.  [553]Generating an RSA CSR
  III.8.  [554]Signing a CSR with your CA certificate
  III.9.  [555]Revoking a Certificate
  III.10. [556]Generating a CRL
  III.11. [557]Mapping a Client Certificate to a User ID

     LINKS

     * [558]IETF Public-Key Infrastructure (X.509) (pkix) Charter
     * [559]RFC 2459: Internet X.509 Public Key Infrastructure -
       Certificate and CRL Profile
     * [560]RFC 2527: Internet X.509 Public Key Infrastructure -
       Certificate Policy and Certification Practices Framework
     * [561]RFC 2528: Internet X.509 Public Key Infrastructure -
       Representation of Key Exchange Algorithm (KEA) Keys in Internet
       X.509 Public Key Infrastructure Certificates

     This is a brief introduction to certificates, certificate
     authorities, and how to use them. The information presented here is
     highly technical and can be skipped unless:

     * you are a system administrator and want to learn how to secure
       your host, or:
     * you want to know how to use client certificates to authenticate to
       a host.

     RSA Security, Inc., has a good Frequently Asked Questions (FAQ):

  [562]http://www.rsasecurity.com/rsalabs/faq/questions.html

     The FAQ covers many topics related to cryptography as well as how
     public key certificates work and how they are to be used.

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

     [ [563]Top ] [ [564]Contents ] [ [565]Appendix Contents ] [
     [566]Glossary ]

     Public key (asymmetric) cryptography defines a class of algorithms
     for key exchange that include RSA and Diffie-Hellman (DH). These
     algorithms provide a mechanism to create a shared secret that can
     be used for encrypting future communications. Anyone listening to
     the exchange would be no closer to figuring out the value of the
     shared secret than if they were to take a guess.

     There are two parts to the exchange. A private key that is never
     disclosed, and a public key that may be viewed by all. An X.509
     certificate is a standard package for distributing a public key
     with identifying features such that the authenticity and validity
     of the public key may be verified by a recipient.

     The authenticity and validity of a certificate is provided by a
     combination of information provided within the certificates (the
     subject, the issuer, dates of validity, ...) as well as the trust
     that is placed in the certificate issuer (the Certificate
     Authority, or CA). The CA signs each of the certificates that it
     issues with its own certificate. With a copy of the CA's
     certificate it is possible to validate all of the certificates that
     were signed by the CA's private key.

     A user who wants to have a certificate signed by a CA creates a
     Certificate Signing Request (CSR). The CSR is an unsigned
     certificate presented to the CA along with information verifying
     the identity and desired use for the certificate. The CA signs the
     CSR producing a certificate that is valid for a specific time
     frame, which is then returned to the user.

     If the private key of the certificate were to be compromised the CA
     may revoke the certificate. The CA publishes a Certificate
     Revocation List (CRL) on a periodic basis containing a list of all
     certificates that would otherwise be valid if they were not
     revoked. It is the responsibility of the verifier to check not only
     the authenticity of the certificate but also whether or not it has
     been revoked by the issuer.

  III.2. RSA Certificates vs DSA Certificates

     [ [567]Top ] [ [568]Contents ] [ [569]Appendix Contents ] [
     [570]Glossary ]

     The important differences between RSA and DSA certificates are:

     * The RSA algorithms are faster than DSA.
     * The RSA algorithms are supported by all the major browsers whereas
       DSA are not.
     * The RSA algorithms were patented in the United States (until Sept
       29, 2000), requiring payments of licensing fees for producers of
       software utilizing them, whereas DSA is free.
     * The RSA private and public key pairs may be used for encrypting
       data as well as signing. DSA private and public key pairs may only
       be used for signing. Therefore, products incorporating DSA
       algorithms are easier to export from the United States.

     Due to the patent issues surrounding the RSA algorithms, the Kermit
     Project does not maintain a library or distribute any binaries that
     are built with the RSA algorithms. This policy can change when the
     RSA patent expires.

  III.3. Should You Be Your Own Certificate Authority?

     [ [571]Top ] [ [572]Contents ] [ [573]Appendix Contents ] [
     [574]Glossary ]

     There are many companies that believe that providing CA services is
     big business. These include but are not limited to:

     * [575]Verisign
     * [576]Thawte Consulting
     * [577]CertiSign Cerificadora Digital Ltda.
     * [578]IKS GmbH
     * [579]Uptime Commerce Ltd.
     * [580]BelSign NV/SA

     The root CA certificates of these companies certificates are
     included most of the popular browsers. This provides an ease-of-use
     advantage to the recipients of certificates they sign since the
     root certificates do not need to be otherwise distributed to
     authenticate the signed certificates.

     On the other hand, as is pointed out by C. Ellison and B. Schneier
     in their paper, Ten Risks of PKI: What You're Not Being Told About
     Public Key Infrastructure:

  [581]http://www.counterpane.com/pki-risks.html

     using the commercial CA services it makes it difficult to decide
     whether or not a certificate should be trusted for a particular
     purpose, especially if you want to use certificates to authenticate
     an end user to a system for remote access. In this situation it is
     necessary to not only be able to authenticate a certificate but be
     able to know that the information within the certificate, such as
     the uniqueIdentifier used for the User ID, is tightly controlled
     and in fact unique in your environment.

     If you choose to be your own CA you will have to configure your
     environment. Create the following directory trees to store the DSA
     and RSA CAs.

   openssl/dsaCA/certs/
   openssl/dsaCA/crl/
   openssl/dsaCA/private/
   openssl/dsaCA/newcerts/
   openssl/dsaCA/requests/
   openssl/rsaCA/certs/
   openssl/rsaCA/crl/
   openssl/rsaCA/private/
   openssl/rsaCA/newcerts/
   openssl/rsaCA/requests/

     Place the openssl.cnf file into the openssl directory. Edit it to
     meet the requirements of your organization. Create two sections,
     [ CA_DSA ] and [ CA_RSA ]:

  [ CA_DSA ]

  dir             = openssl_path/dsaCA/    # Where everything is kept
  certs           = $dir/certs             # Where the issued certs are kept
  crl_dir         = $dir/crl               # Where the issued crl are kept
  database        = $dir/index.txt         # database index file.
  new_certs_dir   = $dir/newcerts          # default place for new certs.

  certificate     = $dir/certs/cacert.pem  # The CA certificate
  serial          = $dir/ca.srl            # The current serial number
  crl             = $dir/crl.pem           # The current CRL
  private_key     = $dir/private/cakey.pem # The private key
  RANDFILE        = $dir/private/.rand     # private random number file

  x509_extensions = x509v3_extensions      # The extensions to add to the cert
  default_days    = 365                    # how long to certify for
  default_crl_days= 30                     # how long before next CRL
  default_md      = sha1                   # which md to use.
  preserve        = no                     # keep passed DN ordering
  policy          = policy_match           # which CA policy

  [ CA_RSA ]

  dir             = openssl_path/rsaCA/    # Where everything is kept
  certs           = $dir/certs             # Where the issued certs are kept
  crl_dir         = $dir/crl               # Where the issued crl are kept
  database        = $dir/index.txt         # database index file.
  new_certs_dir   = $dir/newcerts          # default place for new certs.

  certificate     = $dir/certs/cacert.pem  # The CA certificate
  serial          = $dir/ca.srl            # The current serial number
  crl             = $dir/crl.pem           # The current CRL
  private_key     = $dir/private/cakey.pem # The private key
  RANDFILE        = $dir/private/.rand     # private random number file

  x509_extensions = x509v3_extensions      # The extensions to add to the cert
  default_days    = 365                    # how long to certify for
  default_crl_days= 30                     # how long before next CRL
  default_md      = sha1                   # which md to use.
  preserve        = no                     # keep passed DN ordering
  policy          = policy_match           # which CA policy

     If you wish to use the uniqueIdentifier field to perform
     certificate to user ID mapping, add it after the emailAddress
     field.

     If you wish to use the subjectAltName field to perform certificate
     to user ID mapping, you must to add a [ x509v3_extensions ]
     section:

  [ x509v3_extensions ]

  subjectAltName                 = email:copy

     Other formats of the subjectAltName field are:

  subjectAltName                 = email:copy
  subjectAltName                 = issuerl:copy
  subjectAltName                 = email:[e-mail]
  subjectAltName                 = DNS:www.company.com
  subjectAltName                 = IP:100.99.98.97
  subjectAltName                 = RID:2.99999.1

     Other x509v3 extensions include:

  nsCaRevocationUrl              = http://www.domain.com/ca-crl.pem
  nsComment                      = "This is a comment"

     To avoid the need to specify the location of the openssl.cnf file,
     set the environment variable OPENSSL_CNF to be equal to the full
     path of the file. If you do not create this environment variable
     you must to include the option:

  -config path/openssl.cnf

     to each openssl command.

     Create the file that stores the next available serial number for
     each CA:

   openssl/dsaCA/ca.srl
   openssl/rsaCA/ca.srl

     The format of this file is a hex value followed by a LF (0x0A)
     character. The value "01" is an appropriate initial value.

     Create an empty file to store the index of signed certificates:

   openssl/dsaCA/index.txt
   openssl/rsaCA/index.txt

     Now you are ready to create the DSA and RSA CA certificates for
     your organization.

  III.4. Generating a DSA CA (self-signed) Certificate

     [ [582]Top ] [ [583]Contents ] [ [584]Appendix Contents ] [
     [585]Glossary ]

     Change the current working directory to openssl/dsaCA/.

     Generate the DSA parameters to be used when generating the keys for
     use with your certificates:

  openssl dsaparam 1024 -out dsa1024.pem

     Generate the self-signed certificate to be used as the CA
     certificate for your organization:

  openssl req -x509 -newkey dsa:dsa1024.pem -days days \
    -keyout private/cakey.pem -out certs/cacert.pem

     The days parameter should be replaced by the number of days you
     want this certificate to remain valid. All certificates signed by
     this certificate become invalid when this certificate expires.

     Be sure to not forget the pass-phrase you use to protect the
     private key of the CA certificate. If you do not wish to encrypt
     the CA's private key you may specify the -nodes option. But this is
     highly discouraged.

     You can check the contents of the CA certificate with the command:

  openssl x509 -text -in certs/cacert.pem

  III.5. Generating a DSA CSR

     [ [586]Top ] [ [587]Contents ] [ [588]Appendix Contents ] [
     [589]Glossary ]

     Change the current working directory to openssl/dsaCA/.

     If you have not already created a set of DSA parameters, you must
     generate a set:

  openssl dsaparam 1024 -out dsa1024.pem

     It is safe to reuse the DSA parameters.

     Generate the DSA certificate request:

  openssl req -newkey dsa:dsa1024.pem -keyout private/name-key.pem \
    -out requests/name-req.pem

     where name should be replaced by something that identifies the
     files. Perhaps the hostname or userid for which the certificate is
     being generated.

     If you are generating a CSR for use as a host certificate, be sure
     to specify the fully qualified domain name as reported by the DNS
     as the Common Name for the certificate. Otherwise, it won't be
     recognized as belonging to the host it is installed on by its
     clients.

     Be sure not to forget the pass-phrase you use to protect the
     private key of the CA certificate. The certificate (after signing)
     is unusable without it. Use the -nodes option if you wish to store
     the key unencrypted.

     You can check the contents of the CSR with the command:

  openssl req -text -in requests/name-req.pem

     The CSR now stored in requests/name-req.pem may be sent to one of
     the commercial CAs if you do not wish to be your own CA.

  III.6. Generating an RSA CA (self-signed) certificate

     [ [590]Top ] [ [591]Contents ] [ [592]Appendix Contents ] [
     [593]Glossary ]

     Change the current working directory to openssl/rsaCA/.

     Generate the self-signed certificate to be used as the CA
     certificate for your organization:

  openssl req -x509 -newkey rsa:1024 -days days \
    -keyout private/cakey.pem -out certs/cacert.pem

     The days parameter should be replaced by the number of days you
     want this certificate to remain valid. All certificates signed by
     this certificate become invalid when this certificate expires.

     Be sure not to forget the pass-phrase you use to protect the
     private key of the CA certificate. If you do not wish to encrypt
     the CA's private key you may specify the -nodes option. But this is
     highly discouraged.

     You can check the contents of the CA certificate with the command:

  openssl x509 -text -in certs/cacert.pem

  III.7. Generating an RSA CSR

     [ [594]Top ] [ [595]Contents ] [ [596]Appendix Contents ] [
     [597]Glossary ]

     Change the current working directory to openssl/rsaCA/.

  openssl req -newkey rsa:1024 -keyout private/name-key.pem \
    -out requests/name-req.pem

     name should be replaced by something that identifies the files,
     such as the hostname or userid for which the certificate is being
     generated.

     If you are generating a CSR for use as a host certificate be sure
     to specify the fully qualified domain name as reported by the DNS
     as the Common Name for the certificate. Otherwise, it is not
     recognized as belonging to the host it is installed on by its
     clients.

     Be sure not to forget the pass-phrase you use to protect the
     private key of the CA certificate. The certificate (after signing)
     is unusable without it. Use the -nodes option if you wish to store
     the key unencrypted.

     You can check the contents of the CSR with the command:

  openssl req -text -in requests/name-req.pem

     The CSR now stored in requests/name-req.pem may be sent to one of
     the commercial CAs if you do not wish to be your own CA.

  III.8. Signing a CSR with your CA certificate

     [ [598]Top ] [ [599]Contents ] [ [600]Appendix Contents ] [
     [601]Glossary ]

     If you are signing a DSA certificate change directory to
     openssl/dsaCA/ and use a caname of "CA_DSA". If you are signing an
     RSA certificate change directory to openssl/rsaCA/ and use a caname
     of "CA_RSA":

  openssl ca -name caname -in requests/name-req.pem \
    -out certs/name.pem -days days

     The days parameter should be replaced by the number of days you
     want the signed certificate to remain valid. If you want to specify
     a specific date range you can replace the -days parameters with:

 -startdate YYMMDDHHMMSSZ  - certificate validity notBefore
 -enddate YYMMDDHHMMSSZ    - certificate validity notAfter

     The file certs/name.pem now contains a signed certificate that may
     be used by a host or client for authentication with its matching
     private key (private/name-key.pem.)

     An alternative method of signing the CSR is to use the command:

  openssl x509 -req -in requests/name-req.pem -CA certs/cacert.pem \
    -CAkey private/cakey.pem -out certs/name.pem -days days \
    -CAserial ca.srl -CAcreateserial

     The "openssl x509" command provides greater functionality at the
     expense of ease of use. The X509 may be used to assign X.509v3
     certificate extensions with the -extfile and -extensions switches.
     It may also be used to produce certificates that may only be used
     for specific purposes.

     You can check the contents of the CA certificate with the command:

  openssl x509 -text -in certs/name.pem

  III.9. Revoking a Certificate

     [ [602]Top ] [ [603]Contents ] [ [604]Appendix Contents ] [
     [605]Glossary ]

     If you are revoking a DSA certificate change directory to
     openssl/dsaCA/ and use a caname of "CA_DSA". If you are revoking an
     RSA certificate change directory to openssl/rsaCA/ and use a caname
     of "CA_RSA".

  openssl ca -name caname -revoke certs/name.pem

     marks the certificate as being revoked in the index.txt file. It is
     necessary to revoke a certificate with a given subject name if you
     wish to generate a new certificate with an identical subject name.
     Once a certificate is revoked it is listed in the next generated
     CRL.

  III.10. Generating a CRL

     [ [606]Top ] [ [607]Contents ] [ [608]Appendix Contents ] [
     [609]Glossary ]

     If you are generating a CRL for your DSA certificates change
     directory to openssl/dsaCA/ and use a caname of "CA_DSA". If you
     are generating a CRL for your RSA certificate change directory to
     openssl/rsaCA/ and use a caname of "CA_RSA":

  openssl ca -name caname -gencrl -out crl/date-crl.pem

     date should be replaced by the date the crl was generated.

     You can check the contents of the CRL with the command:

  openssl crl -in crl/date-crl.pem -text

     The current CRL should be placed somewhere it is publicly and
     easily accessible. For instance, by HTTP or FTP. The CRL is signed
     by the CA certificate

  III.11. Mapping a Client Certificate to a User ID

     [ [610]Top ] [ [611]Contents ] [ [612]Appendix Contents ] [
     [613]Glossary ]

     Kermit can be configured to perform a mapping from an X.509 client
     certificate to a User ID. This is primarily of use when Kermit is
     installed as an Internet Kermit Service. When a mapping is enabled,
     the client certificate may be used to authenticate and
     automatically login a user to their account or resources.

     Unfortunately, it is not possible to build a function in to Kermit
     to provide the mapping from Certificate to User ID that would be
     secure and/or applicable to every installation. There are several
     commonly used approaches to map a certificate to a userid. Kermit
     can be customized to use whichever one you choose to use in your
     environment.

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

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

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

          This method is safer than the uniqueIdentifier, but it is still
          placing a lot of trust in the Certificate Authority. If you are
          not issuing the certificates yourself you'll have to trust that
          the CA has a legitimate method for verifying that the e-mail
          address belongs to the user for whom the CA is signing a
          certificate.

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

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

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

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

    III.11.1. Mapping a Client Certificate to a User ID in Kermit 95

     [ [614]Top ] [ [615]Contents ] [ [616]Appendix Contents ] [
     [617]Glossary ]

     X.509 to User ID mapping functions are implemented in Kermit 95 via
     the use of a user compiled Dynamic Link Library (DLL),
     X5092UID.DLL. To build this DLL you need a C compiler such as
     Microsoft's Visual C++ and OpenSSL 0.9.4 (or higher) compiled and
     installed.

     OpenSSL sources may be retrieved from the web site:

  [618]http://www.openssl.org/

     As of this writing the current release of OpenSSL is 0.9.6b and
     0.9.7 is under development. Kermit 95 1.1.20 works OpenSSL binaries
     produced by compiling versions 0.9.4 or higher. Patches for OpenSSL
     0.9.4 to allow compilation under OS/2 are located at:

  [619]http://www.geocities.com/SiliconValley/Hills/8057/files/openssl.html

     On Windows, OpenSSL must be compiled and linked to use the NT DLL
     option without Debug information. Compiling the DLLs with support
     for debugging links the DLLs to an incompatible C Run Time Library
     DLL. On OS/2, OpenSSL must be compiled to use the DLL version of
     the run time library.

     The DLL must contain two functions with the following prototypes:

  /* X509_to_user() returns 0 if valid userid in 'userid', else -1 */
  int X509_to_user(X509 *peer_cert, char *userid, int len);

  /* X509_userok() returns 0 if access is denied; 1 is access is permitted */
  int X509_userok(X509 * peer_cert, const char * userid);

     An example function that uses the /UID field of the Certificate
     Subject name follows:

  int
  X509_to_user(X509 *peer_cert, char *userid, int len) {
      int err;

      if (!(peer_cert && userid) || len <= 0)
          return -1;

      /* Userid is in cert subject /UID */
      err = X509_NAME_get_text_by_NID(X509_get_subject_name(peer_cert),
                                       NID_uniqueIdentifier, userid, len);
      if (err > 0)
          return 0;
      return -1;
  }

     An example function provides userid authorization follows:

int
X509_userok(X509 * peer_cert, const char * userid) {
    /* check if clients cert is in "user"'s ~/.tlslogin file */
    char buf[512];
    int r = 0;
    FILE *fp;
    struct passwd *pwd;
    X509 *file_cert;

    if ( peer_cert == NULL )
      return(0);

    if (!(pwd = getpwnam(userid)))
     return 0;
    if (strlen(pwd->pw_dir) > 500)
     return(0);
    sprintf(buf, "%s/.tlslogin", pwd->pw_dir);

    if (!(fp = fopen(buf, "r")))
      return 0;
    while (!r && (file_cert = PEM_read_X509(fp, NULL, NULL, NULL))) {
        if (<ASN1_STRING_cmp(peer_cert->signature, file_cert->signature))
            r = 1;
        X509_free(file_cert);
    }
    fclose(fp);
    return(r);
}

     These functions must be compiled into a DLL called "X5092UID.DLL".
     It should be linked to the OpenSSL libraries and the DLL version of
     the run time library.

     Contact [620]Kermit Support for further information..

    III.11.2 Mapping a Client Certificate to a User ID in C-Kermit

     [ [621]Top ] [ [622]Contents ] [ [623]Appendix Contents ] [
     [624]Glossary ]

     X.509 to User ID mapping functions are implemented in C-Kermit in
     one of two ways.

     * If you want to use the uniqueIdentifier field you can specify
       KFLAGS=-DX509_UID_TO_USER at compile time.
     * If you want to use the subjectAltName field you can specify
       KFLAGS=-DX509_SUBJECT_ALT_NAME_TO_USER at compile time.
     * Otherwise, you need to customize the X509_to_user() function in
       the ck_ssl.c source file to implement your verification method.

     A X509_userok() that supports the use of the ~userid/.tlslogin file
     is provided. This function should be examined for compatibility
     with the institutional access policies. It should be replaced or
     modified as needed.

     Contact [625]Kermit Support for further information..
    ________________________________________________________________________

  GLOSSARY [ [626]Top ] [ [627]Contents ]

   ARPANET
          The US Department of Defense [628]Advanced Research Projects
          Agency Network, the precursor to the Internet.

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

   Authorization
          The process by which one gains access to a particular resource.

   CA
          SSL/TLS X.509 Certificate Authority.

   Certificate
          A public security key packaged in a way that allows its
          verification.

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

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

   CAST
          An encryption algorithm similar to DES (q.v.).

   CRL
          SSL/TLS X.509 Certificate Revocation List.

   CSR
          SSL/TLS X.509 Certificate Signing Request.

   DES
          USA Federal Information Processing Standard (FIPS) [629]46-2
          Data Encryption Standard (1988, 1993).

   DNS
          Domain Name System (which resolves IP hostnames into numeric IP
          addresses).

   DNSSEC
          [630]Domain Name System Security.

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

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

   FTP
          File Transfer Protocol. On the Internet, this refers to a
          specific protocol defined in [631]RFC 959 and its followons.

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

   Host
          A computer that can be accessed over a network.

   HTTP
          Hyper Text Transfer Protocol, the protocol of the World Wide
          Web, [632]RFC 2616.

   IETF
          The [633]Internet Engineering Task Force, the body that sets
          standards for use on the Internet.

   IKSD
          [634]Internet Kermit Service Daemon.

   IPsec
          [635]IP Security Protocol.

   IPv6
          [636]Internet Protocol Version 6, the "next generation"
          Internet protocol.

   ITU-T
          International Telecommunications Union, the body that sets
          international X-dot-series standards.

   Integrity
          The assurance that traffic on a network connection has not been
          altered in transit.

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

   PGP
          [637]Pretty Good Privacy, the original do-it-yourself public
          key security scheme, first developed in 1991 by Phil Zimmerman.

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

   NAT
          Network Address Translator.

   NTLM
          Microsoft (Windows) NT LAN Manager authentication protocol.

   PKI
          Public Key Infrastructure.

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

   Principal
          (Kerberos) A string that names a specific entity to which a set
          of credentials may be assigned. It generally has three parts,
          primary/instance@REALM:

         1. Primary: Identifies the user or service.
         2. Instance: Usually a hostname or REALM.
         3. REALM: Logical network served by a single Kerberos database
            and KDC.

   Privacy
          The assurance that traffic on a network connection is
          intelligible only to the two communicating parties.

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

   SSL
          Secure Sockets Layer, developed by/for Netscape for secure Web
          connections.

   SOCKS
          Protocol for firewall traversal. SOCKS5 is an Internet standard
          ([638]RFC 1928).

   SSL/TLS
          SSL (q.v.) and/or TLS (q.v.).

   SRP
          Stanford University's Secure Remote Password protocol, a
          zero-knowledge based authentication method.

   TELNET
          ARPANET/Internet Network Virtual Terminal Protocol ("Teletype
          Network"), described in [639]RFC 854 plus many followons.

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

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

   TLS
          Transport Layer Security, the Internet standard form of SSL
          (q.v.),

     [640]RFC 2246.

   X.509
          ITU-T standard for exchanging public keys.
    ________________________________________________________________________

  REFERENCES

     [ [641]Top ] [ [642]Contents ]
    1. Schneier, Bruce, Applied Cryptography: Protocols, Algorithms, and
       Source Code in C, 2nd Edition, 784 pages, John Wiley & Sons; ISBN:
       0471117099 (1995).
    2. da Cruz, Frank, and Christine M. Gianone, Using C-Kermit, 2nd
       Edition, 622 pages, Digital Press / Butterworth Heinemann; ISBN:
       1-55558-164-1 (1997)
    3. [643]The Kermit Project Website
    4. [644]RFC 854:  Telnet Protocol Specification
    5. [645]RFC 959:  File Transfer Protocol (FTP)
    6. [646]RFC 1282: BSD Rlogin
    7. [647]RFC 1510: The Kerberos Network Authentication Service (V5)
    8. [648]RFC 1928: SOCKS Protocol Version 5
    9. [649]RFC 1964: The Kerberos Version 5 GSS-API Mechanism
   10. [650]RFC 2217 Telnet Com Port Control Option
   11. [651]RFC 2228: FTP Security Extensions
   12. [652]RFC 2246: The TLS Protocol Version 1.0
   13. [653]RFC 2663: IP Network Address Translator (NAT) Terminology and
       Considerations
   14. [654]RFC 2459: Internet X.509 Public Key Infrastructure -
       Certificate and CRL Profile
   15. [655]RFC 2527: Internet X.509 Public Key Infrastructure -
       Certificate Policy and Certification Practices Framework
   16. [656]RFC 2528: Internet X.509 Public Key Infrastructure -
       Representation of Key Exchange Algorithm (KEA) Keys...
   17. [657]RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
   18. [658]RFC 2712: Addition of Kerberos Cipher Suites to Transport
       Layer Security (TLS)
   19. [659]RFC 2818: HTTP over TLS
   20. [660]RFC 2839: Internet Kermit Service
   21. [661]RFC 2840: Telnet KERMIT Option
   22. [662]RFC 2941: Telnet Authentication Option
   23. [663]RFC 2942: Telnet Authentication: Kerberos Version 5
   24. [664]RFC 2943: TELNET Authentication Using DSA
   25. [665]RFC 2944: Telnet Authentication: SRP
   26. [666]RFC 2945: The SRP Authentication and Key Exchange System
   27. [667]RFC 2946: Telnet Data Encryption Option
   28. [668]RFC 2947: Telnet Encryption: DES3 64 bit Cipher Feedback
   29. [669]RFC 2948: DES3 64-bit Output Feedback Mode
   30. [670]RFC 2949: CAST-128 64-bit Output Feedback Mode
   31. [671]RFC 2950: CAST-128 64-bit Cipher Feedback Mode
   32. [672]RFC 2951: DES 64-bit Output Feedback Mode
   33. [673]RFC 2952: DES 64-bit Cipher Feedback Mode
   34. [674]RFC 2953: Telnet Encryption: DES 64 bit Output Feedback
   35. [675]RFC 2993: Architectural Implications of NAT
   36. [676]RFC 3002: Traditional IP Network Address Translator
       (Traditional NAT)

   Also see:
          [677]http://www.columbia.edu/kermit/standards.html
    ________________________________________________________________________

  TRADEMARKS

     [ [678]Top ] [ [679]Contents ]

   Kerberos
          Is a trademark of Massachusetts Institute of Technology.

   Secure Remote Password
          Is a trademark of Stanford University.

   Secure Shell
          Is a trademark of SSH Communications Security Corporation.

   SSH
          Is a registered trademark of SSH Communications Security
          Corporation.

     [ [680]Top ] [ [681]Contents ] [ [682]Glossary ] [ [683]C-Kermit
     Home ] [ [684]Kermit Home ]
       ______________________________________________________________

     [685]Kermit Security Reference / [686]The Kermit Project /
     [687]Columbia University / [688][e-mail] / 12
     Dec 2001

References

   1. http://www.columbia.edu/kermit/
   2. http://www.columbia.edu/
   3. http://www.columbia.edu/kermit/ck80.html
   4. http://www.columbia.edu/kermit/k95next.html
   5. http://www.columbia.edu/kermit/security70.html
   6. http://www.columbia.edu/kermit/ck70.html
   7. http://www.columbia.edu/kermit/k95.html
   8. http://www.columbia.edu/kermit/index.html
   9. http://www.columbia.edu/kermit/ckermit.html
  10. http://www.columbia.edu/kermit/k95.html
  11. http://www.columbia.edu/kermit/security80.html#x1
  12. http://www.columbia.edu/kermit/security80.html#x2
  13. http://www.columbia.edu/kermit/security80.html#x3
  14. http://www.columbia.edu/kermit/security80.html#x4
  15. http://www.columbia.edu/kermit/security80.html#xa1
  16. http://www.columbia.edu/kermit/security80.html#xa2
  17. http://www.columbia.edu/kermit/security80.html#xa3
  18. http://www.columbia.edu/kermit/security80.html#glossary
  19. http://www.columbia.edu/kermit/security80.html#references
  20. http://www.columbia.edu/kermit/security80.html#trademarks
  21. http://www.columbia.edu/kermit/security80.html#top
  22. http://www.columbia.edu/kermit/security80.html#contents
  23. http://www.columbia.edu/kermit/security80.html#glossary
  24. http://www.columbia.edu/kermit/security80.html#x2
  25. http://www.columbia.edu/kermit/security80.html#x1.1
  26. http://www.columbia.edu/kermit/security80.html#x1.2
  27. http://www.columbia.edu/kermit/security80.html#x1.3
  28. http://www.columbia.edu/kermit/security80.html#x1.4
  29. http://www.columbia.edu/kermit/security80.html#x1.5
  30. http://www.columbia.edu/kermit/security80.html#glossary
  31. http://www.columbia.edu/acis/security/safecomputing.html
  32. http://www.columbia.edu/kermit/security80.html#n01
  33. http://www.ietf.org/html.charters/ipsec-charter.html
  34. http://www.ipv6.org/
  35. http://www.ietf.org/ids.by.wg/dnssec.html
  36. http://www.columbia.edu/kermit/ckermit.html
  37. http://www.columbia.edu/kermit/k95.html
  38. http://www.columbia.edu/kermit/security80.html#trademarks
  39. http://www.columbia.edu/kermit/security80.html#trademarks
  40. http://www.columbia.edu/kermit/security80.html#trademarks
  41. http://www.columbia.edu/kermit/security80.html#trademarks
  42. http://www.columbia.edu/kermit/security80.html#top
  43. http://www.columbia.edu/kermit/security80.html#contents
  44. http://www.columbia.edu/kermit/security80.html#x1
  45. http://www.columbia.edu/kermit/security80.html#glossary
  46. http://www.columbia.edu/kermit/security80.html#top
  47. http://www.columbia.edu/kermit/security80.html#contents
  48. http://www.columbia.edu/kermit/security80.html#x1
  49. http://www.columbia.edu/kermit/security80.html#glossary
  50. http://www.columbia.edu/kermit/security80.html#xa3
  51. ftp://ftp.isi.edu/in-notes/rfc2228.txt
  52. ftp://ftp.isi.edu/in-notes/rfc2818.txt
  53. http://www.columbia.edu/kermit/security80.html#xa3
  54. http://www.columbia.edu/kermit/security80.html#top
  55. http://www.columbia.edu/kermit/security80.html#contents
  56. http://www.columbia.edu/kermit/security80.html#x1
  57. http://www.columbia.edu/kermit/security80.html#glossary
  58. http://www.columbia.edu/kermit/security80.html#x1.3.1
  59. http://www.columbia.edu/kermit/security80.html#x1.3.2
  60. http://www.columbia.edu/kermit/security80.html#x1.3.3
  61. http://www.columbia.edu/kermit/security80.html#x1.3.4
  62. http://www.columbia.edu/kermit/security80.html#x1.3.1
  63. http://www.columbia.edu/kermit/security80.html#xa3
  64. http://www.columbia.edu/kermit/security80.html#x1.3.2
  65. http://www.columbia.edu/kermit/security80.html#top
  66. http://www.columbia.edu/kermit/security80.html#contents
  67. http://www.columbia.edu/kermit/security80.html#x1
  68. http://www.columbia.edu/kermit/security80.html#x1.3
  69. http://www.columbia.edu/kermit/security80.html#glossary
  70. ftp://ftp.isi.edu/in-notes/rfc1510.txt
  71. ftp://ftp.isi.edu/in-notes/rfc1964.txt
  72. http://web.mit.edu/kerberos/www/
  73. http://nii.isi.edu/info/kerberos/
  74. http://nii.isi.edu/publications/kerberos-neuman-tso.html
  75. http://www.columbia.edu/kermit/security80.html#top
  76. http://www.columbia.edu/kermit/security80.html#contents
  77. http://www.columbia.edu/kermit/security80.html#x1
  78. http://www.columbia.edu/kermit/security80.html#x1.3
  79. http://www.columbia.edu/kermit/security80.html#glossary
  80. ftp://ftp.isi.edu/in-notes/rfc2945.txt
  81. http://www-cs-students.stanford.edu/~tjw/srp/
  82. http://www.columbia.edu/kermit/security80.html#top
  83. http://www.columbia.edu/kermit/security80.html#contents
  84. http://www.columbia.edu/kermit/security80.html#x1
  85. http://www.columbia.edu/kermit/security80.html#x1.3
  86. http://www.columbia.edu/kermit/security80.html#glossary
  87. http://www.columbia.edu/kermit/security80.html#top
  88. http://www.columbia.edu/kermit/security80.html#contents
  89. http://www.columbia.edu/kermit/security80.html#x1
  90. http://www.columbia.edu/kermit/security80.html#x1.3
  91. http://www.columbia.edu/kermit/security80.html#glossary
  92. http://www.columbia.edu/kermit/security80.html#xa3
  93. http://www.columbia.edu/kermit/security80.html#top
  94. http://www.columbia.edu/kermit/security80.html#contents
  95. http://www.columbia.edu/kermit/security80.html#x1
  96. http://www.columbia.edu/kermit/security80.html#glossary
  97. http://www.columbia.edu/kermit/security80.html#x2
  98. http://www.columbia.edu/kermit/security80.html#x1.4.1
  99. http://www.columbia.edu/kermit/security80.html#x1.4.2
 100. http://www.columbia.edu/kermit/security80.html#x1.4.3
 101. http://www.columbia.edu/kermit/security80.html#x1.4.4
 102. http://www.columbia.edu/kermit/security80.html#x1.4.5
 103. http://www.columbia.edu/kermit/security80.html#x1.4.6
 104. http://www.columbia.edu/kermit/security80.html#top
 105. http://www.columbia.edu/kermit/security80.html#contents
 106. http://www.columbia.edu/kermit/security80.html#x1
 107. http://www.columbia.edu/kermit/security80.html#x1.4
 108. http://www.columbia.edu/kermit/security80.html#glossary
 109. ftp://ftp.isi.edu/in-notes/rfc2946.txt
 110. ftp://ftp.isi.edu/in-notes/rfc2950.txt
 111. ftp://ftp.isi.edu/in-notes/rfc2949.txt
 112. ftp://ftp.isi.edu/in-notes/rfc2947.txt
 113. ftp://ftp.isi.edu/in-notes/rfc2948.txt
 114. ftp://ftp.isi.edu/in-notes/rfc2952.txt
 115. ftp://ftp.isi.edu/in-notes/rfc2951.txt
 116. http://www.columbia.edu/kermit/security80.html#x1.4.3
 117. http://www.columbia.edu/kermit/security80.html#top
 118. http://www.columbia.edu/kermit/security80.html#contents
 119. http://www.columbia.edu/kermit/security80.html#x1
 120. http://www.columbia.edu/kermit/security80.html#x1.4
 121. http://www.columbia.edu/kermit/security80.html#glossary
 122. http://www.columbia.edu/kermit/security80.html#top
 123. http://www.columbia.edu/kermit/security80.html#contents
 124. http://www.columbia.edu/kermit/security80.html#x1
 125. http://www.columbia.edu/kermit/security80.html#x1.4
 126. http://www.columbia.edu/kermit/security80.html#glossary
 127. ftp://ftp.isi.edu/in-notes/rfc2246.txt
 128. http://www.columbia.edu/kermit/security80.html#xa3
 129. ftp://ftp.isi.edu/in-notes/rfc2712.txt
 130. http://www.columbia.edu/kermit/security80.html#top
 131. http://www.columbia.edu/kermit/security80.html#contents
 132. http://www.columbia.edu/kermit/security80.html#x1
 133. http://www.columbia.edu/kermit/security80.html#x1.4
 134. http://www.columbia.edu/kermit/security80.html#glossary
 135. http://www.columbia.edu/kermit/security80.html#top
 136. http://www.columbia.edu/kermit/security80.html#contents
 137. http://www.columbia.edu/kermit/security80.html#x1
 138. http://www.columbia.edu/kermit/security80.html#x1.4
 139. http://www.columbia.edu/kermit/security80.html#glossary
 140. http://www.columbia.edu/kermit/security80.html#x1.4.3
 141. http://www.columbia.edu/kermit/security80.html#top
 142. http://www.columbia.edu/kermit/security80.html#contents
 143. http://www.columbia.edu/kermit/security80.html#x1
 144. http://www.columbia.edu/kermit/security80.html#x1.4
 145. http://www.columbia.edu/kermit/security80.html#glossary
 146. http://www.columbia.edu/kermit/security80.html#top
 147. http://www.columbia.edu/kermit/security80.html#contents
 148. http://www.columbia.edu/kermit/security80.html#glossary
 149. http://www.columbia.edu/kermit/security80.html#x1
 150. http://www.columbia.edu/kermit/security80.html#x3
 151. http://www.mozilla.org/crypto-faq.html
 152. http://www.columbia.edu/kermit/ckermit.html
 153. http://www.columbia.edu/kermit/ck80.html
 154. http://www.columbia.edu/kermit/k95.html
 155. http://www.columbia.edu/kermit/index.html
 156. http://www.columbia.edu/kermit/security80.html#top
 157. http://www.columbia.edu/kermit/security80.html#contents
 158. http://www.columbia.edu/kermit/security80.html#glossary
 159. http://www.columbia.edu/kermit/security80.html#x4
 160. http://www.columbia.edu/kermit/security80.html#x2
 161. http://www.columbia.edu/kermit/security80.html#x3.1
 162. http://www.columbia.edu/kermit/security80.html#x3.2
 163. http://www.columbia.edu/kermit/security80.html#x3.3
 164. http://www.columbia.edu/kermit/security80.html#x3.4
 165. http://www.columbia.edu/kermit/k95bulk.html
 166. mailto:[e-mail]
 167. http://www.columbia.edu/kermit/security80.html#x3.1.1
 168. http://www.columbia.edu/kermit/security80.html#x3.1.2
 169. http://www.columbia.edu/kermit/security80.html#x3.1.3
 170. http://www.columbia.edu/kermit/security80.html#x3.1.4
 171. http://www.columbia.edu/kermit/security80.html#x3.1.5
 172. http://www.columbia.edu/kermit/security80.html#top
 173. http://www.columbia.edu/kermit/security80.html#contents
 174. http://www.columbia.edu/kermit/security80.html#x3
 175. http://www.columbia.edu/kermit/security80.html#x3.1
 176. http://www.columbia.edu/kermit/security80.html#glossary
 177. http://www.columbia.edu/kermit/security80.html#top
 178. http://www.columbia.edu/kermit/security80.html#contents
 179. http://www.columbia.edu/kermit/security80.html#x3
 180. http://www.columbia.edu/kermit/security80.html#x3.1
 181. http://www.columbia.edu/kermit/security80.html#glossary
 182. http://www.columbia.edu/kermit/security80.html#top
 183. http://www.columbia.edu/kermit/security80.html#contents
 184. http://www.columbia.edu/kermit/security80.html#x3
 185. http://www.columbia.edu/kermit/security80.html#x3.1
 186. http://www.columbia.edu/kermit/security80.html#glossary
 187. http://www.columbia.edu/kermit/security80.html#top
 188. http://www.columbia.edu/kermit/security80.html#contents
 189. http://www.columbia.edu/kermit/security80.html#x3
 190. http://www.columbia.edu/kermit/security80.html#x3.1
 191. http://www.columbia.edu/kermit/security80.html#glossary
 192. http://www.columbia.edu/kermit/security80.html#xa3
 193. ftp://ftp.isi.edu/in-notes/rfc2246.txt
 194. ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
 195. http://www.columbia.edu/kermit/security80.html#x3.2.2.3
 196. http://www.columbia.edu/kermit/iksd.html
 197. http://www.columbia.edu/kermit/security80.html#xa3.11
 198. http://www.columbia.edu/kermit/security80.html#xa1.1
 199. http://www.columbia.edu/kermit/security80.html#xa1
 200. http://www.columbia.edu/kermit/security80.html#xa1.2
 201. http://www.columbia.edu/kermit/security80.html#top
 202. http://www.columbia.edu/kermit/security80.html#contents
 203. http://www.columbia.edu/kermit/security80.html#x3
 204. http://www.columbia.edu/kermit/security80.html#x3.1
 205. http://www.columbia.edu/kermit/security80.html#glossary
 206. http://www.columbia.edu/kermit/security80.html#top
 207. http://www.columbia.edu/kermit/security80.html#contents
 208. http://www.columbia.edu/kermit/security80.html#x3
 209. http://www.columbia.edu/kermit/security80.html#glossary
 210. http://www.columbia.edu/kermit/security80.html#x3.2.1
 211. http://www.columbia.edu/kermit/security80.html#x3.2.2
 212. http://www.columbia.edu/kermit/security80.html#x3.2.3
 213. http://www.columbia.edu/kermit/security80.html#x3.2.4
 214. http://www.columbia.edu/kermit/ckututor.html
 215. http://www.columbia.edu/kermit/k95tutor.html
 216. http://www.columbia.edu/kermit/ckscripts.html
 217. http://www.columbia.edu/kermit/security80.html#top
 218. http://www.columbia.edu/kermit/security80.html#contents
 219. http://www.columbia.edu/kermit/security80.html#x3
 220. http://www.columbia.edu/kermit/security80.html#x3.2
 221. http://www.columbia.edu/kermit/security80.html#glossary
 222. http://www.columbia.edu/kermit/security80.html#x3.2.1.1
 223. http://www.columbia.edu/kermit/security80.html#x3.2.1.2
 224. http://www.columbia.edu/kermit/security80.html#x3.2.1.3
 225. http://www.columbia.edu/kermit/security80.html#top
 226. http://www.columbia.edu/kermit/security80.html#contents
 227. http://www.columbia.edu/kermit/security80.html#x3
 228. http://www.columbia.edu/kermit/security80.html#x3.2
 229. http://www.columbia.edu/kermit/security80.html#x3.2.1
 230. http://www.columbia.edu/kermit/security80.html#glossary
 231. http://www.columbia.edu/kermit/telnet.html
 232. http://www.columbia.edu/kermit/security80.html#xa1
 233. http://www.columbia.edu/kermit/security80.html#top
 234. http://www.columbia.edu/kermit/security80.html#contents
 235. http://www.columbia.edu/kermit/security80.html#x3
 236. http://www.columbia.edu/kermit/security80.html#x3.2
 237. http://www.columbia.edu/kermit/security80.html#x3.2.1
 238. http://www.columbia.edu/kermit/security80.html#glossary
 239. http://www.columbia.edu/kermit/ftpclient.html
 240. http://www.columbia.edu/kermit/security80.html#top
 241. http://www.columbia.edu/kermit/security80.html#contents
 242. http://www.columbia.edu/kermit/security80.html#x3
 243. http://www.columbia.edu/kermit/security80.html#x3.2
 244. http://www.columbia.edu/kermit/security80.html#x3.2.1
 245. http://www.columbia.edu/kermit/security80.html#glossary
 246. http://www.columbia.edu/kermit/security80.html#top
 247. http://www.columbia.edu/kermit/security80.html#contents
 248. http://www.columbia.edu/kermit/security80.html#x3
 249. http://www.columbia.edu/kermit/security80.html#x3.2
 250. http://www.columbia.edu/kermit/security80.html#glossary
 251. http://www.columbia.edu/kermit/security80.html#x3.2.3
 252. http://www.columbia.edu/kermit/security80.html#xa2
 253. http://www.columbia.edu/kermit/security80.html#top
 254. http://www.columbia.edu/kermit/security80.html#contents
 255. http://www.columbia.edu/kermit/security80.html#x3
 256. http://www.columbia.edu/kermit/security80.html#x3.2
 257. http://www.columbia.edu/kermit/security80.html#glossary
 258. http://www.columbia.edu/kermit/ckermit2.htm#x1.5
 259. http://www.columbia.edu/kermit/ckermit2.htm
 260. http://www.columbia.edu/kermit/security80.html#glossary
 261. http://www.columbia.edu/kermit/ckb2.html
 262. http://www.columbia.edu/kermit/ckermit2.htm#x1.6
 263. http://www.columbia.edu/kermit/ckermit2.htm
 264. http://www.columbia.edu/kermit/security80.html#top
 265. http://www.columbia.edu/kermit/security80.html#contents
 266. http://www.columbia.edu/kermit/security80.html#x3
 267. http://www.columbia.edu/kermit/security80.html#x3.2
 268. http://www.columbia.edu/kermit/security80.html#glossary
 269. http://www.columbia.edu/kermit/security80.html#xa2
 270. http://www.columbia.edu/kermit/ckermit.html
 271. http://www.columbia.edu/kermit/ck80.html
 272. http://www.columbia.edu/kermit/k95.html
 273. http://www.columbia.edu/kermit/index.html
 274. http://www.columbia.edu/kermit/security80.html#top
 275. http://www.columbia.edu/kermit/security80.html#contents
 276. http://www.columbia.edu/kermit/security80.html#x3
 277. http://www.columbia.edu/kermit/security80.html#glossary
 278. http://www.columbia.edu/kermit/security80.html#x3.3.1
 279. http://www.columbia.edu/kermit/security80.html#x3.3.2
 280. http://www.columbia.edu/kermit/security80.html#x3.3.3
 281. http://www.columbia.edu/kermit/security80.html#x3.3.4
 282. http://www.columbia.edu/kermit/security80.html#x3.3.5
 283. http://www.columbia.edu/kermit/security80.html#x3.3.6
 284. http://www.columbia.edu/kermit/security80.html#x3.3.7
 285. http://www.columbia.edu/kermit/security80.html#top
 286. http://www.columbia.edu/kermit/security80.html#contents
 287. http://www.columbia.edu/kermit/security80.html#x3
 288. http://www.columbia.edu/kermit/security80.html#x3.3
 289. http://www.columbia.edu/kermit/security80.html#glossary
 290. http://www.columbia.edu/kermit/security80.html#top
 291. http://www.columbia.edu/kermit/security80.html#contents
 292. http://www.columbia.edu/kermit/security80.html#x3
 293. http://www.columbia.edu/kermit/security80.html#x3.3
 294. http://www.columbia.edu/kermit/security80.html#glossary
 295. http://www.columbia.edu/kermit/security80.html#top
 296. http://www.columbia.edu/kermit/security80.html#contents
 297. http://www.columbia.edu/kermit/security80.html#x3
 298. http://www.columbia.edu/kermit/security80.html#x3.3
 299. http://www.columbia.edu/kermit/security80.html#glossary
 300. http://www.columbia.edu/kermit/security80.html#top
 301. http://www.columbia.edu/kermit/security80.html#contents
 302. http://www.columbia.edu/kermit/security80.html#x3
 303. http://www.columbia.edu/kermit/security80.html#x3.3
 304. http://www.columbia.edu/kermit/security80.html#glossary
 305. http://www.columbia.edu/kermit/security80.html#top
 306. http://www.columbia.edu/kermit/security80.html#contents
 307. http://www.columbia.edu/kermit/security80.html#x3
 308. http://www.columbia.edu/kermit/security80.html#x3.3
 309. http://www.columbia.edu/kermit/security80.html#glossary
 310. http://www.columbia.edu/kermit/security80.html#top
 311. http://www.columbia.edu/kermit/security80.html#contents
 312. http://www.columbia.edu/kermit/security80.html#x3
 313. http://www.columbia.edu/kermit/security80.html#x3.3
 314. http://www.columbia.edu/kermit/security80.html#glossary
 315. http://www.stunnel.org/
 316. http://www.columbia.edu/kermit/security80.html#x3.2.2.3
 317. http://www.columbia.edu/kermit/security80.html#xa3
 318. http://www.columbia.edu/kermit/case21.html
 319. http://www.columbia.edu/kermit/security80.html#top
 320. http://www.columbia.edu/kermit/security80.html#contents
 321. http://www.columbia.edu/kermit/security80.html#x3
 322. http://www.columbia.edu/kermit/security80.html#x3.3
 323. http://www.columbia.edu/kermit/security80.html#glossary
 324. http://www.columbia.edu/kermit/ckermit.html
 325. http://www.columbia.edu/kermit/ck80.html
 326. http://www.columbia.edu/kermit/k95.html
 327. http://www.columbia.edu/kermit/index.html
 328. http://www.columbia.edu/kermit/security80.html#top
 329. http://www.columbia.edu/kermit/security80.html#contents
 330. http://www.columbia.edu/kermit/security80.html#x3
 331. http://www.columbia.edu/kermit/security80.html#glossary
 332. http://www.columbia.edu/kermit/ckermit.html
 333. http://www.columbia.edu/kermit/ck80.html
 334. http://www.columbia.edu/kermit/k95.html
 335. http://www.columbia.edu/kermit/index.html
 336. http://www.columbia.edu/kermit/security80.html#top
 337. http://www.columbia.edu/kermit/security80.html#contents
 338. http://www.columbia.edu/kermit/security80.html#glossary
 339. http://www.columbia.edu/kermit/security80.html#xa1
 340. http://www.columbia.edu/kermit/security80.html#x3
 341. http://www.columbia.edu/kermit/security80.html#x4.1
 342. http://www.columbia.edu/kermit/security80.html#x4.2
 343. http://www.columbia.edu/kermit/security80.html#x4.1.1
 344. http://www.columbia.edu/kermit/security80.html#x4.1.2
 345. http://www.columbia.edu/kermit/security80.html#x4.1.3
 346. http://www.columbia.edu/kermit/security80.html#x4.1.4
 347. http://www.columbia.edu/kermit/security80.html#x4.1.5
 348. http://www.columbia.edu/kermit/security80.html#x4.1.6
 349. http://www.columbia.edu/kermit/security80.html#x4.1.7
 350. http://www.columbia.edu/kermit/security80.html#top
 351. http://www.columbia.edu/kermit/security80.html#contents
 352. http://www.columbia.edu/kermit/security80.html#x4
 353. http://www.columbia.edu/kermit/security80.html#x4.1
 354. http://www.columbia.edu/kermit/security80.html#glossary
 355. http://web.mit.edu/kerberos/www/
 356. ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/README
 357. http://www.kermit-project.org/noexport.html
 358. http://www.columbia.edu/kermit/security80.html#x4.1.2
 359. http://www.columbia.edu/kermit/security80.html#top
 360. http://www.columbia.edu/kermit/security80.html#contents
 361. http://www.columbia.edu/kermit/security80.html#x4
 362. http://www.columbia.edu/kermit/security80.html#x4.1
 363. http://www.columbia.edu/kermit/security80.html#glossary
 364. http://www.kermit-project.org/noexport.html
 365. http://www.columbia.edu/kermit/security80.html#top
 366. http://www.columbia.edu/kermit/security80.html#contents
 367. http://www.columbia.edu/kermit/security80.html#x4
 368. http://www.columbia.edu/kermit/security80.html#x4.1
 369. http://www.columbia.edu/kermit/security80.html#glossary
 370. http://www.columbia.edu/kermit/security80.html#top
 371. http://www.columbia.edu/kermit/security80.html#contents
 372. http://www.columbia.edu/kermit/security80.html#x4
 373. http://www.columbia.edu/kermit/security80.html#x4.1
 374. http://www.columbia.edu/kermit/security80.html#glossary
 375. http://www.kermit-project.org/noexport.html
 376. http://www.columbia.edu/kermit/security80.html#xa3.11.1
 377. http://www.columbia.edu/kermit/security80.html#top
 378. http://www.columbia.edu/kermit/security80.html#contents
 379. http://www.columbia.edu/kermit/security80.html#x4
 380. http://www.columbia.edu/kermit/security80.html#x4.1
 381. http://www.columbia.edu/kermit/security80.html#glossary
 382. http://www.columbia.edu/kermit/security80.html#top
 383. http://www.columbia.edu/kermit/security80.html#contents
 384. http://www.columbia.edu/kermit/security80.html#x4
 385. http://www.columbia.edu/kermit/security80.html#x4.1
 386. http://www.columbia.edu/kermit/security80.html#glossary
 387. ftp://ftp.nec.co.jp/pub/packages/sotools/
 388. http://www.columbia.edu/kermit/security80.html#top
 389. http://www.columbia.edu/kermit/security80.html#contents
 390. http://www.columbia.edu/kermit/security80.html#x4
 391. http://www.columbia.edu/kermit/security80.html#x4.1
 392. http://www.columbia.edu/kermit/security80.html#glossary
 393. http://www.columbia.edu/kermit/k95dll_c.txt
 394. http://www.columbia.edu/kermit/security80.html#top
 395. http://www.columbia.edu/kermit/security80.html#contents
 396. http://www.columbia.edu/kermit/security80.html#x4
 397. http://www.columbia.edu/kermit/security80.html#glossary
 398. http://www.columbia.edu/kermit/security80.html#x4.2.1
 399. http://www.columbia.edu/kermit/security80.html#x4.2.2
 400. http://www.columbia.edu/kermit/security80.html#x4.2.3
 401. http://www.columbia.edu/kermit/security80.html#x4.2.4
 402. http://www.columbia.edu/kermit/security80.html#x4.2.5
 403. http://www.columbia.edu/kermit/security80.html#x4.2.6
 404. http://www.columbia.edu/kermit/security80.html#top
 405. http://www.columbia.edu/kermit/security80.html#contents
 406. http://www.columbia.edu/kermit/security80.html#x4
 407. http://www.columbia.edu/kermit/security80.html#x4.2
 408. http://www.columbia.edu/kermit/security80.html#glossary
 409. http://www.columbia.edu/kermit/iksd.html
 410. http://www.columbia.edu/kermit/security80.html#x2
 411. http://web.mit.edu/kerberos/www/
 412. http://web.mit.edu/network/kerberos-form.html
 413. http://web.mit.edu/kerberos/www/
 414. http://web.mit.edu/network/kerberos-form.html
 415. http://www.columbia.edu/kermit/iksd.html
 416. http://www.columbia.edu/kermit/security80.html#top
 417. http://www.columbia.edu/kermit/security80.html#contents
 418. http://www.columbia.edu/kermit/security80.html#x4
 419. http://www.columbia.edu/kermit/security80.html#x4.2
 420. http://www.columbia.edu/kermit/security80.html#glossary
 421. http://www.columbia.edu/kermit/security80.html#x2
 422. http://srp.stanford.edu/srp/
 423. http://www.columbia.edu/kermit/iksd.html
 424. http://www.columbia.edu/kermit/security80.html#top
 425. http://www.columbia.edu/kermit/security80.html#contents
 426. http://www.columbia.edu/kermit/security80.html#x4
 427. http://www.columbia.edu/kermit/security80.html#x4.2
 428. http://www.columbia.edu/kermit/security80.html#glossary
 429. http://www.columbia.edu/kermit/iksd.html
 430. http://www.columbia.edu/kermit/security80.html#x2
 431. http://www.openssl.org/
 432. http://www.columbia.edu/kermit/security80.html#xa3.11.2
 433. http://www.columbia.edu/kermit/security80.html#top
 434. http://www.columbia.edu/kermit/security80.html#contents
 435. http://www.columbia.edu/kermit/security80.html#x4
 436. http://www.columbia.edu/kermit/security80.html#x4.2
 437. http://www.columbia.edu/kermit/security80.html#glossary
 438. http://www.columbia.edu/kermit/security80.html#top
 439. http://www.columbia.edu/kermit/security80.html#contents
 440. http://www.columbia.edu/kermit/security80.html#x4
 441. http://www.columbia.edu/kermit/security80.html#x4.2
 442. http://www.columbia.edu/kermit/security80.html#glossary
 443. http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
 444. http://www.columbia.edu/kermit/security80.html#top
 445. http://www.columbia.edu/kermit/security80.html#contents
 446. http://www.columbia.edu/kermit/security80.html#x4
 447. http://www.columbia.edu/kermit/security80.html#x4.2
 448. http://www.columbia.edu/kermit/security80.html#glossary
 449. http://www.columbia.edu/kermit/ckermit2.htm#x2.7
 450. http://www.columbia.edu/kermit/ckermit2.htm
 451. http://www.columbia.edu/kermit/ckccfg.html#x8.1.1>Section8.1.1</a>ofthe<ahref=
 452. http://www.columbia.edu/kermit/ckermit.html
 453. http://www.columbia.edu/kermit/ck80.html
 454. http://www.columbia.edu/kermit/k95.html
 455. http://www.columbia.edu/kermit/security80.html#top
 456. http://www.columbia.edu/kermit/security80.html#contents
 457. http://www.columbia.edu/kermit/security80.html#glossary
 458. http://www.columbia.edu/kermit/index.html
 459. http://www.columbia.edu/kermit/security80.html#xa1.1
 460. http://www.columbia.edu/kermit/security80.html#xa1.2
 461. http://www.columbia.edu/kermit/security80.html#xa1.3
 462. http://www.columbia.edu/kermit/security80.html#xa1.4
 463. http://www.columbia.edu/kermit/security80.html#xa1.5
 464. http://www.columbia.edu/kermit/security80.html#references
 465. http://www.columbia.edu/kermit/security80.html#top
 466. http://www.columbia.edu/kermit/security80.html#contents
 467. http://www.columbia.edu/kermit/security80.html#xa1
 468. http://www.columbia.edu/kermit/security80.html#glossary
 469. http://www-1.ibm.com/servers/eserver/zseries/zos/commserver/kerberos.html
 470. http://web.mit.edu/kerberos/www/
 471. http://web.mit.edu/kerberos/www/
 472. http://www-cs-students.stanford.edu/~tjw/srp/
 473. http://www.openssl.org/
 474. ftp://ftp.runestig.com/pub/starttls/start_tls-telnet.current.tar.gz
 475. http://www.columbia.edu/kermit/security80.html#top
 476. http://www.columbia.edu/kermit/security80.html#contents
 477. http://www.columbia.edu/kermit/security80.html#xa1
 478. http://www.columbia.edu/kermit/security80.html#glossary
 479. http://web.mit.edu/kerberos/www/
 480. http://web.mit.edu/kerberos/www/
 481. http://www-cs-students.stanford.edu/~tjw/srp/
 482. http://www.openssl.org/
 483. ftp://ftp.runestig.com/pub/ftp-tls/
 484. ftp://ftp.runestig.com/pub/ftpd-tls/
 485. ftp://ftp.runestig.com/pub/proftpd-tls/
 486. http://www.columbia.edu/kermit/security80.html#top
 487. http://www.columbia.edu/kermit/security80.html#contents
 488. http://www.columbia.edu/kermit/security80.html#xa1
 489. http://www.columbia.edu/kermit/security80.html#glossary
 490. http://www.columbia.edu/kermit/cuiksd.html
 491. http://www.columbia.edu/kermit/iksd.html
 492. http://www.columbia.edu/kermit/security80.html#top
 493. http://www.columbia.edu/kermit/security80.html#contents
 494. http://www.columbia.edu/kermit/security80.html#xa1
 495. http://www.columbia.edu/kermit/security80.html#glossary
 496. http://www.columbia.edu/kermit/security80.html#top
 497. http://www.columbia.edu/kermit/security80.html#contents
 498. http://www.columbia.edu/kermit/security80.html#xa1
 499. http://www.columbia.edu/kermit/security80.html#glossary
 500. http://www.stunnel.org/
 501. http://www.columbia.edu/kermit/case21.html
 502. http://www.columbia.edu/kermit/security80.html#top
 503. http://www.columbia.edu/kermit/security80.html#contents
 504. http://www.columbia.edu/kermit/security80.html#glossary
 505. http://www.columbia.edu/kermit/security80.html#xa2.1
 506. http://www.columbia.edu/kermit/security80.html#xa2.2
 507. http://www.columbia.edu/kermit/security80.html#xa2.3
 508. http://www.columbia.edu/kermit/security80.html#top
 509. http://www.columbia.edu/kermit/security80.html#contents
 510. http://www.columbia.edu/kermit/security80.html#xa2
 511. http://www.columbia.edu/kermit/security80.html#glossary
 512. http://www.iana.org/assignments/port-numbers
 513. http://www.columbia.edu/kermit/security80.html#top
 514. http://www.columbia.edu/kermit/security80.html#contents
 515. http://www.columbia.edu/kermit/security80.html#xa2
 516. http://www.columbia.edu/kermit/security80.html#glossary
 517. http://www.columbia.edu/kermit/security80.html#top
 518. http://www.columbia.edu/kermit/security80.html#contents
 519. http://www.columbia.edu/kermit/security80.html#xa2
 520. http://www.columbia.edu/kermit/security80.html#glossary
 521. http://www.columbia.edu/kermit/security80.html#top
 522. http://www.columbia.edu/kermit/security80.html#contents
 523. http://www.columbia.edu/kermit/security80.html#xa2
 524. http://www.columbia.edu/kermit/security80.html#glossary
 525. ftp://ftp.isi.edu/in-notes/rfc1928.txt
 526. http://www.columbia.edu/kermit/security80.html#top
 527. http://www.columbia.edu/kermit/security80.html#contents
 528. http://www.columbia.edu/kermit/security80.html#xa2
 529. http://www.columbia.edu/kermit/security80.html#glossary
 530. ftp://kermit.columbia.edu/kermit/scripts/ckermit/linksys
 531. ftp://ftp.isi.edu/in-notes/rfc2993.txt
 532. ftp://ftp.isi.edu/in-notes/rfc2663.txt
 533. ftp://ftp.isi.edu/in-notes/rfc3002.txt
 534. http://www.ietf.org/internet-drafts/draft-ietf-nat-app-guide-06.txt
 535. http://www.cs.utk.edu/~moore/what-nats-break.html
 536. http://www.columbia.edu/kermit/security80.html#top
 537. http://www.columbia.edu/kermit/security80.html#contents
 538. http://www.columbia.edu/kermit/security80.html#xa2
 539. http://www.columbia.edu/kermit/security80.html#glossary
 540. http://www.columbia.edu/kermit/ckermit.html
 541. http://www.columbia.edu/kermit/ck80.html
 542. http://www.columbia.edu/kermit/k95.html
 543. http://www.columbia.edu/kermit/index.html
 544. http://www.columbia.edu/kermit/security80.html#top
 545. http://www.columbia.edu/kermit/security80.html#contents
 546. http://www.columbia.edu/kermit/security80.html#glossary
 547. http://www.columbia.edu/kermit/security80.html#xa3.1
 548. http://www.columbia.edu/kermit/security80.html#xa3.2
 549. http://www.columbia.edu/kermit/security80.html#xa3.3
 550. http://www.columbia.edu/kermit/security80.html#xa3.4
 551. http://www.columbia.edu/kermit/security80.html#xa3.5
 552. http://www.columbia.edu/kermit/security80.html#xa3.6
 553. http://www.columbia.edu/kermit/security80.html#xa3.7
 554. http://www.columbia.edu/kermit/security80.html#xa3.8
 555. http://www.columbia.edu/kermit/security80.html#xa3.9
 556. http://www.columbia.edu/kermit/security80.html#xa3.10
 557. http://www.columbia.edu/kermit/security80.html#xa3.11
 558. http://www.ietf.org/html.charters/pkix-charter.html
 559. http://www.ietf.org/rfc/rfc2459.txt
 560. http://www.imc.org/rfc2527
 561. http://www.imc.org/rfc2528
 562. http://www.rsasecurity.com/rsalabs/faq/questions.html
 563. http://www.columbia.edu/kermit/security80.html#top
 564. http://www.columbia.edu/kermit/security80.html#contents
 565. http://www.columbia.edu/kermit/security80.html#xa3
 566. http://www.columbia.edu/kermit/security80.html#glossary
 567. http://www.columbia.edu/kermit/security80.html#top
 568. http://www.columbia.edu/kermit/security80.html#contents
 569. http://www.columbia.edu/kermit/security80.html#xa3
 570. http://www.columbia.edu/kermit/security80.html#glossary
 571. http://www.columbia.edu/kermit/security80.html#top
 572. http://www.columbia.edu/kermit/security80.html#contents
 573. http://www.columbia.edu/kermit/security80.html#xa3
 574. http://www.columbia.edu/kermit/security80.html#glossary
 575. http://www.verisign.com/
 576. http://www.thawte.com/
 577. http://www.certisign.com.br/
 578. http://www.iks-jena.de/
 579. http://www.uptimecommerce.com/
 580. http://www.belsign.be/
 581. http://www.counterpane.com/pki-risks.html
 582. http://www.columbia.edu/kermit/security80.html#top
 583. http://www.columbia.edu/kermit/security80.html#contents
 584. http://www.columbia.edu/kermit/security80.html#xa3
 585. http://www.columbia.edu/kermit/security80.html#glossary
 586. http://www.columbia.edu/kermit/security80.html#top
 587. http://www.columbia.edu/kermit/security80.html#contents
 588. http://www.columbia.edu/kermit/security80.html#xa3
 589. http://www.columbia.edu/kermit/security80.html#glossary
 590. http://www.columbia.edu/kermit/security80.html#top
 591. http://www.columbia.edu/kermit/security80.html#contents
 592. http://www.columbia.edu/kermit/security80.html#xa3
 593. http://www.columbia.edu/kermit/security80.html#glossary
 594. http://www.columbia.edu/kermit/security80.html#top
 595. http://www.columbia.edu/kermit/security80.html#contents
 596. http://www.columbia.edu/kermit/security80.html#xa3
 597. http://www.columbia.edu/kermit/security80.html#glossary
 598. http://www.columbia.edu/kermit/security80.html#top
 599. http://www.columbia.edu/kermit/security80.html#contents
 600. http://www.columbia.edu/kermit/security80.html#xa3
 601. http://www.columbia.edu/kermit/security80.html#glossary
 602. http://www.columbia.edu/kermit/security80.html#top
 603. http://www.columbia.edu/kermit/security80.html#contents
 604. http://www.columbia.edu/kermit/security80.html#xa3
 605. http://www.columbia.edu/kermit/security80.html#glossary
 606. http://www.columbia.edu/kermit/security80.html#top
 607. http://www.columbia.edu/kermit/security80.html#contents
 608. http://www.columbia.edu/kermit/security80.html#xa3
 609. http://www.columbia.edu/kermit/security80.html#glossary
 610. http://www.columbia.edu/kermit/security80.html#top
 611. http://www.columbia.edu/kermit/security80.html#contents
 612. http://www.columbia.edu/kermit/security80.html#xa3
 613. http://www.columbia.edu/kermit/security80.html#glossary
 614. http://www.columbia.edu/kermit/security80.html#top
 615. http://www.columbia.edu/kermit/security80.html#contents
 616. http://www.columbia.edu/kermit/security80.html#xa3
 617. http://www.columbia.edu/kermit/security80.html#glossary
 618. http://www.openssl.org/
 619. http://www.geocities.com/SiliconValley/Hills/8057/files/openssl.html
 620. mailto:[e-mail]
 621. http://www.columbia.edu/kermit/security80.html#top
 622. http://www.columbia.edu/kermit/security80.html#contents
 623. http://www.columbia.edu/kermit/security80.html#xa3
 624. http://www.columbia.edu/kermit/security80.html#glossary
 625. mailto:[e-mail]
 626. http://www.columbia.edu/kermit/security80.html#top
 627. http://www.columbia.edu/kermit/security80.html#contents
 628. http://www.isoc.org/internet/history/
 629. http://www.itl.nist.gov/fipspubs/fip46-2.htm
 630. http://www.ietf.org/ids.by.wg/dnssec.html
 631. ftp://ftp.isi.edu/in-notes/rfc959.txt
 632. ftp://ftp.isi.edu/in-notes/rfc2616.txt
 633. http://www.ietf.org/
 634. http://www.columbia.edu/kermit/cuiksd.html
 635. http://www.ietf.org/html.charters/ipsec-charter.html
 636. http://www.ipv6.org/
 637. http://www.cypherspace.org/~adam/timeline/
 638. ftp://ftp.isi.edu/in-notes/rfc1928.txt
 639. ftp://ftp.isi.edu/in-notes/rfc854.txt
 640. ftp://ftp.isi.edu/in-notes/rfc2246.txt
 641. http://www.columbia.edu/kermit/security80.html#top
 642. http://www.columbia.edu/kermit/security80.html#contents
 643. http://www.columbia.edu/kermit/
 644. ftp://ftp.isi.edu/in-notes/rfc854.txt
 645. ftp://ftp.isi.edu/in-notes/rfc959.txt
 646. ftp://ftp.isi.edu/in-notes/rfc1282.txt
 647. ftp://ftp.isi.edu/in-notes/rfc1510.txt
 648. ftp://ftp.isi.edu/in-notes/rfc1928.txt
 649. ftp://ftp.isi.edu/in-notes/rfc1964.txt
 650. ftp://ftp.isi.edu/in-notes/rfc2217.txt
 651. ftp://ftp.isi.edu/in-notes/rfc2228.txt
 652. ftp://ftp.isi.edu/in-notes/rfc2246.txt
 653. ftp://ftp.isi.edu/in-notes/rfc2663.txt
 654. http://www.ietf.org/rfc/rfc2459.txt
 655. http://www.imc.org/rfc2527
 656. http://www.imc.org/rfc2528
 657. ftp://ftp.isi.edu/in-notes/rfc2616.txt
 658. ftp://ftp.isi.edu/in-notes/rfc2712.txt
 659. ftp://ftp.isi.edu/in-notes/rfc2818.txt
 660. ftp://ftp.isi.edu/in-notes/rfc2839.txt
 661. ftp://ftp.isi.edu/in-notes/rfc2840.txt
 662. ftp://ftp.isi.edu/in-notes/rfc2941.txt
 663. ftp://ftp.isi.edu/in-notes/rfc2942.txt
 664. ftp://ftp.isi.edu/in-notes/rfc2943.txt
 665. ftp://ftp.isi.edu/in-notes/rfc2944.txt
 666. ftp://ftp.isi.edu/in-notes/rfc2945.txt
 667. ftp://ftp.isi.edu/in-notes/rfc2946.txt
 668. ftp://ftp.isi.edu/in-notes/rfc2946.txt
 669. ftp://ftp.isi.edu/in-notes/rfc2948.txt
 670. ftp://ftp.isi.edu/in-notes/rfc2949.txt
 671. ftp://ftp.isi.edu/in-notes/rfc2950.txt
 672. ftp://ftp.isi.edu/in-notes/rfc2951.txt
 673. ftp://ftp.isi.edu/in-notes/rfc2952.txt
 674. ftp://ftp.isi.edu/in-notes/rfc2953.txt
 675. ftp://ftp.isi.edu/in-notes/rfc2993.txt
 676. ftp://ftp.isi.edu/in-notes/rfc3002.txt
 677. http://www.columbia.edu/kermit/standards.html
 678. http://www.columbia.edu/kermit/security80.html#top
 679. http://www.columbia.edu/kermit/security80.html#contents
 680. http://www.columbia.edu/kermit/security80.html#top
 681. http://www.columbia.edu/kermit/security80.html#contents
 682. http://www.columbia.edu/kermit/security80.html#glossary
 683. http://www.columbia.edu/kermit/ckermit.html
 684. http://www.columbia.edu/kermit/index.html
 685. http://www.columbia.edu/kermit/security80.html#top
 686. http://www.columbia.edu/kermit/index.html
 687. http://www.columbia.edu/
 688. mailto:[e-mail]