home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
old
/
ckermit80
/
edit206
/
security.txt
< prev
next >
Wrap
Text File
|
2020-01-01
|
246KB
|
5,363 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
negotiatied by the Telnet Encryption Option. This additional security
is provided by a combination of the use of longer encryption keys, the
availability of stronger symmetric cryptographic algorithms, and the
signing of each transmitted block with a message-digest algorithm.
TLS 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
negotiatied 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 negotations 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
lanaguage.
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 appropropriate 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 encodiing
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
meesages 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
Kebreros 5 ciphers. However, OpenSSL releases prior to version 1.0
are not guarranteed 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 mututal
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 abiity 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 transfered. 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
actualy 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:
rcmd.hostb@CC.COLUMBIA.EDU
we get a ticket for:
rcmd.cunix@CC.COLUMBIA.EDU
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 extentions 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 extentions 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_externsions ]
section:
[ x509v3_extensions ]
subjectAltName = email:copy
Other formats of the subjectAltName field are:
subjectAltName = email:copy
subjectAltName = issuerl:copy
subjectAltName = email:fred@company.com
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 commerical 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 commerical 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 jdoe@mydomain.com whereas Jane Doe's subjectAltName
would be jdoe@someotherdomain.com. 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 determing 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 Addres 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]kermit-support@columbia.edu / 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:kermit-support@columbia.edu
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:kermit-support@columbia.edu
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:kermit-support@columbia.edu
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:kermit-support@columbia.edu