NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/infosyst/gopher/1314

Text File | 1992-11-23 | 5.2 KB | 97 lines

Newsgroups: comp.infosystems.gopher
Path: sparky!uunet!news.uiowa.edu!tinyblue.cs.uiowa.edu!lbrintle
From: [e-mail] (Lee Brintle)
Subject: Security and Gopher+ (Authentication)
Sender: [e-mail] (News)
Message-ID: <[e-mail]>
Date: Mon, 23 Nov 1992 22:31:07 GMT
Reply-To: [e-mail] (Lee Brintle)
Nntp-Posting-Host: tinyblue.cs.uiowa.edu
Organization: Project Panda, Iowa City, IA, USA
Lines: 84

   Right now, the only security or authentication system gopher has is the
ability to lock out certain machines from using resources.  For items like
Clarinet news, this serves the needs well (there are exceptions).
   However, many times distribution of information needs to be limited to a
finer granularity than machine names (such as particular people who are all
using the same machine) or the machine name doesn't identify the users very
well (such as a public-access system).
   We have been experimenting with various means of adding authentication and
security onto the Gopher+ protocol.  Our work has been primarily with the
Bamboo authentication system, but can easily be extended to include other
systems, such as Kerberos.  We've just been fiddling around, trying to find
a good solution.  What follows is just what we've hit so far; it's not formal
enough for an official proposal or anything like that.  Comments are what we
need at this point.


* Enhancement Needed *
   An enhancement to the Gopher+ protocol allows the server to verify the
identity of the recipient.  The server can then choose to send the actual
data encrypted (if it is feared that the network will be tapped) or sent
in plaintext (if all that was needed was verification of the user's identity).
   There were two main areas that we felt the authentication loop could
be inserted:
   o At menu-retrieve time.  The fact that a particular form of authentication
is needed would be transmitted to the client in the data following the port
number (the "plus" part of Gopher+).  We didn't explore this area too well
because of problems associated with trying to establish a session key.  If you
are interested, we can share our experiences with you.
   o When the document would normally be transmitted.  In order to make the
server work with generic Gopher+ clients, the following describes a retrieval
of a "secure" file from the gopher server:
  Client:  bar selector#+
  Server:  --1<CRLF>??? D32J1KC9QHND Bamboo|Kerberos Authentication
                             required for server <servername><CRLF>.<CRLF>

   At this point, a non-modified Gopher+ client would see the error and report
it, closing the connection. However, an authentication-aware client would
read the response as "You cannot have the file yet; however, if you
authenticate yourself with me using either the Bamboo or Kerberos protocols,
you may retrieve this file."  The authentication-aware client then goes into
"normal" authentication negotiation with the Gopher+ server in order to verify
identity.  After the negotiation, the client and server start over again with
the appropriate Gopher responses.

   The "???" after the error is a magic cookie that authentication-aware
clients look for in order to indicate that the server is trying to
authenticate the connection.
   The next word following the "???" is information needed by the
authentication protocol in order to establish a connection.  For example,
with Bamboo it is a 12-character uuencoded representation of an 8-character
8-bit string.
   The next part of the response is a "|"-delimited list of authentication
protocols that the server supports, listed in the preferred order of the
server (there are at least four I know of).
   The remainder of the message is human-readable, for non-aware clients,
with the exception of the data between the angle brackets.  The information
within those brackets is the server's name, which is needed for some protocols
(and does not have to be the same as the machine name, for obvious reasons).

   During testing, we also send (on additional lines) what stream cipher
schemes the server supports for sending back private data.  The client selects
one of those schemes (depending on how fast the client is and what was
programmed into the client when it was written).  However, this is confusing
enough so I'll leave that out for now.

   I know that sticking in a "special" response code into the failure
condition is a hairball, but it's the only way I could see to make existing
Gopher+ clients handle this correctly with an error.

   Yes, I know this means that there is a small amount of state involved with
the Gopher server as authentication is negotiated; however, it's required if
you wish to use really secure authentication measures, and it adds very little
real complexity to the server (the state manager, that is; the authentication
part of course adds a lot).

   I would appreciate any comments on how this modification looks to you.
I know that people have been struggling with adding Kerberos to Gopher for
quite some time, and so far we've had pretty good results (of course, we're
not using it in production yet, so take that with a grain of salt).



Lee Brintle                       | ``And so, I leave you with this final word:
Director, Project Panda           |                  twang.''