RFC 912 UNKNOWN SECURITY · AUTHENTICATION

Authentication service

Query a server to learn who owns a TCP connection

On rfc-editor.org ↗
PUBLISHED
September 1984
AUTHORS
M. St. Johns
STREAM
Legacy
OBSOLETED BY
RFC 931 — Authentication server
TCP PORT
113 (decimal)
PROTOCOL
TCP connection-based, text query and response
RESPONSE TYPES
USERID (success) or ERROR (failure)
DOI
10.17487/RFC0912

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                       Mike StJohns
Request for Comments: 912                                           TPSC
                                                          September 1984

                         Authentication Service


STATUS OF THIS MEMO

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and  requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

INTRODUCTION

   The Authentication Server provides a means to determine the identity
   of a user of a particular TCP connection.  Given a TCP port number
   pair, it returns a character string which identifies the owner of
   that connection on the server's system.  Suggested uses include
   automatic identification and verification of a user during an FTP
   session, additional verification of a TAC dial up user, and access
   verification for a generalized network file server.

OVERVIEW

   This is a connection based application on TCP.  A server listens for
   TCP connections on TCP port 113 (decimal).  Once a connection is
   established, the server reads one line of data which specifies the
   connection of interest.  If it exists, the system dependent user
   identifier of the connection of interest is sent out the connection.
   The service closes the connection after sending the user identifier.

RESTRICTIONS

   Queries are permitted only for fully specified connections.  The
   local/foreign host pair used to fully specify the connection are
   taken from the query connection.  This means a user on Host A may
   only query the server on Host B about connections between A and B.

QUERY/RESPONSE FORMAT

   The server accepts simple text query requests of the form

      <local-port>, <foreign-port>

   where <local-port>, is the TCP port (decimal) on the target (server)
   system, and <foreign-port> is the TCP port (decimal) on the source
   (user) system.

      For example:

Authentication Service


         23, 6191

   The response is of the form

      <local-port>, <foreign-port> : <response-type> : <additional-info>

   where <local-port>, <foreign-port> are the same pair as the query,
   <response-type> is a keyword identifying the type of response, and
   <additional info> is context dependent.

      For example:

         23, 6191 : USERID : StJohns

RESPONSE TYPES

   A response can be one of two types:

   USERID

      In this case, <additional-info> is the printable representation of
      the user identifier of the owner of the connection.  The format of
      the returned user identifier is completely system dependent.

   ERROR

      For some reason the owner of the TCP port could not be determined,
      <additional-info> tells why.  The following are suggested values
      of <additional-info> and their meanings.

         INVALID PORT

            Either the local or foreign port was improperly specified.

         NO USER

            The connection specified by the port pair is not currently
            in use.

         UNKNOWN ERROR

            Can't determine connection owner; reason unknown.
            Other values may be specified as necessary.

Authentication Service


CAVEATS

   Unfortunately, the trustworthiness of the various host systems that
   might implement an authentication server will vary quite a bit.  It
   is up to the various applications that will use the server to
   determine the amount of trust they will place in the returned
   information.  It may be appropriate in some cases restrict the use of
   the server to within a locally controlled subnet.

APPLICATIONS

   1) Automatic user authentication for FTP.

   2) Verification for privileged network operations.  For example,
   having the server start or stop special purpose servers.

DISCLAIMER

   I designed this protocol to allow me to eliminate the bother of
   having to identify myself before continuing an FTP session.

   Since I started work on it, other applications appeared.  I have
   tried to consider all of our applications while still making this as
   general as possible.

AI ELI5

On this page
PROBLEMWhen a connection is made between two hosts, there is no standard way to ask a server who owns the connection on that server's side.
MECHANISMRFC 912 proposes a service on TCP port 113 that accepts a query specifying a port pair and returns the user identifier owning that connection.
REPLACED BY RFC 931This approach was superseded by RFC 931, which is still used today as the Ident protocol.

§1Purpose

RFC 912 proposes the Authentication Service, which provides a way to determine the identity of a user on a TCP connection. Given a pair of TCP port numbers (local and foreign), an authentication server returns a character string identifying the owner of that connection on the server's system.

Suggested uses include automatic user identification during FTP sessions, additional verification for dial-up users, and access verification for network file servers. The motivation was personal: the author designed this protocol to avoid having to identify himself each time he used FTP.

The service lets you find out who is on the other end of a connection by asking the remote computer.

§2Query and Response Format

A client establishes a TCP connection to the authentication server's port 113 (decimal) and sends a simple query of the form <local-port>, <foreign-port>, where <local-port> is the TCP port on the target (server) system and <foreign-port> is the TCP port on the source (client) system. For example, a query might be 23, 6191 to ask about a Telnet connection.

The server responds with <local-port>, <foreign-port> : <response-type> : <additional-info>. A successful response has type USERID with the printable user identifier. An error response has type ERROR with a reason code such as INVALID PORT, NO USER, or UNKNOWN ERROR. The server closes the connection after sending the response.

You send two port numbers to the server, and it replies with a name or an error message.

§3Trustworthiness and Caveats

RFC 912 explicitly cautions that the trustworthiness of authentication servers varies widely. Different systems have different security policies and user identifier formats, and the information is only as reliable as the server that provides it. Implementations are advised to determine how much trust to place in returned identifiers.

The RFC suggests that use of the authentication service might be restricted to locally controlled subnets where administrators can verify the trustworthiness of the servers involved. Applications should not make security-critical decisions based solely on authentication service responses.

The answer is only as trustworthy as the computer providing it. You have to decide whether you believe what it says.

§4References