Protocol Action: Identity Protocol and MIB to Proposed Standard

IESG Secretary <iesg-secretary@CNRI.Reston.VA.US> Mon, 07 December 1992 22:49 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23387; 7 Dec 92 17:49 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23383; 7 Dec 92 17:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23416; 7 Dec 92 17:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23356; 7 Dec 92 17:49 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23352; 7 Dec 92 17:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23355; 7 Dec 92 17:49 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa23340; 7 Dec 92 17:48 EST
To: Jon Postel -- RFC Editor <postel@isi.edu>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@isi.edu>
Cc: The Internet Engineering Steering Group <IESG@IETF.CNRI.Reston.VA.US>
Cc: ident@CNRI.Reston.VA.US
X-Orig-Sender: ident-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US>
Subject: Protocol Action: Identity Protocol and MIB to Proposed Standard
Date: Mon, 07 Dec 1992 17:48:11 -0500
X-Orig-Sender: gvaudre@CNRI.Reston.VA.US
Message-ID: <9212071748.aa23340@IETF.CNRI.Reston.VA.US>

   The IESG has approved the Ident protocol and the Ident MIB as
   Proposed Standards.  The protocols are documented in the Internet
   Drafts:

   "Identification Server" <draft-ietf-ident-idserver-03.txt>

   "Ident MIB"  <draft-ietf-ident-mib-03.txt>  

   These protocols are the product of the TCP Client Identity Protocol
   Working Group.  The IESG contact person is Steve Crocker.

Technical Summary

   The Identification Server Protocol (aka "Ident", aka "the Ident
   Protocol", aka "the Identification Protocol") 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 or octet string
   which identifies the owner of that connection on the server's
   system.

   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 a line of data which specifies the
   connection of interest.  If it exists, the system dependent user
   identifier of the connection of interest is sent as the reply.  The
   server may then either shut the connection down or it may continue
   to read/respond to multiple queries.  The client may close the
   connection down at any time.

   This protocol was originally proposed as an authentication
   protocol.  It has since been thoroughly understood that the
   infrastructure is generally too weak for this protocol to serve as
   an authnetication protocol, but the information supplied by this
   protocol is useful for auditing.  It is not intended as an
   authorization or access control protocol.  At best, it provides
   some additional auditing information with respect to TCP
   connections.  At worst, it can provide misleading, incorrect, or
   maliciously incorrect information.

   An important aspect of this protocol is that it is backward
   compatible with RFC 931 and TAP.

   The Identification MIB is defined to identifying the users
   associated with TCP connections.  It provides functionality
   approximately equivalent to that provided by the Ident protocol.

Working Group Summary

   This working group worked hard for its consensus.  There were two
   other approaches suggested for this protocol: RFC 931 (the
   predecessor to this work) and TAP (contributed principally by Dan
   Bernstein).  Consensus was elusive and achieving it often required
   the firm hand of the Chair.

   RFC 931 was an experimental protocol.  However, the specification was
   imprecise in a few areas and a small, informal group formed to revise
   the document.  The group blossomed into a working group when it was
   suggested to make the revised document a standards track document.

   TAP was proposed when consensus on how to present the security ---
   or rather the lack thereof --- of the protocol could not be
   reached.  Ultimately the revision to RFC 931 became the consensus of
   the group.

Protocol Quaility

   The Ident documents have been prepared according to expected
   Internet practice and represent readable documents.  Although no
   implementations of Ident are known to exist, there were a couple of
   implementations of RFC 931 and TAP.

Greg Vaudreuil
IESG Secretary