objection to ident submission

["Daniel J. Bernstein" <[e-mail]>]

I apologize for the length of this message; I lack the time to make it
shorter. It will be just a few days before the IESG renders its decision
on IDENT.

---Dan

Objection to IDENT submission
Daniel J. Bernstein
12 September 1992


Table of contents:

Abstract
1. Introduction
2. Technical incompetence
3. Incompatibility	
4. History
5. Further information


Abstract

Mike StJohns wrote a document describing a protocol, IDENT, which runs
on TCP port 113. IDENT is a request-response protocol. An IDENT server
is allowed to close the TCP connection after the first request, or to
continue reading and responding to requests; it can also negatively
respond to a request by closing the connection. A client can _never_
safely take advantage of the multiple-request feature, because TCP does
not guarantee instant delivery. IDENT includes many similar examples of
technical incompetence. It shows severe incompatibilities with current
use of TCP port 113. It does not represent the consensus of any
significant fraction of the Internet community. It was developed in a
haphazard way conducive to technical problems and not conducive to
consensus. Mike StJohns submitted his document to the IESG for
publication as a Proposed Standard. His submission should be rejected.


1. Introduction

According to RFC 1310, ``an Internet Standard is a specification that is
stable and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with operational
experience, enjoys significant public support, and is recognizably
useful in some or all parts of the Internet.''

RFC 1310 identifies four goals of the standards process: ``high
quality,'' ``prior implementation and testing,'' ``openness and
fairness,'' and ``timeliness.''

Finally, RFC 1310 characterizes a Proposed Standard: ``A Proposed
Standard specification is generally stable, has resolved known design
choices, is believed to be well-understood, has received significant
community review, and appears to enjoy enough community interest to be
considered valuable.''

In August 1992, Mike StJohns submitted a document (henceforth ``the
StJohns document'') to the IESG for publication as a Proposed Standard
RFC. The document defines a protocol (henceforth ``IDENT'') which runs
on TCP port 113.

I request that the IESG reject the StJohns document, on several grounds.
The document (and the protocol it defines) are technically incompetent,
of low quality, unstable, and poorly understood; they do not enjoy
enough community interest to be considered valuable, and they have not
received significant review by the community. The protocol has never
been implemented and has no user base. The protocol is not recognizably
useful in the Internet, primarily because it conflicts with current use
of TCP port 113 for a different protocol (henceforth ``TAP'').

As detailed in section 2, an IDENT server is allowed to close the TCP
connection after the first request, or to continue reading and
responding to requests; it can also negatively respond to a request by
closing the connection. A client can _never_ safely take advantage of
the multiple-request feature, because TCP does not guarantee instant
delivery. This example alone demonstrates that IDENT is technically
incompetent, of low quality, and poorly understood. It alone should be
sufficient reason for the IESG to reject the StJohns document. Yet it is
only one of the dozens of problems detailed below.

Except for brief summaries at the beginning of each section, this
message is highly technical and highly detailed. My intent is to leave
no doubt in the reader's mind that whenever I say there is a problem,
there is indeed a problem. The price for this level of technical detail
is length. I apologize for this, but it is a necessary evil.

The StJohns document was distributed (on 26 August, after submission to
the IESG) as internet-drafts/draft-ietf-ident-idserver-01.txt from
nri.reston.va.us. (The latest version appears to be idserver-02.txt.) On
3 September the IESG issued its Last Call for the document (violating
the rule in RFC 1310, lines 323ff). TAP has been documented by the
ad-hoc TAP-std working group; see section 5 for further details. Some of
the multiple implementations of TAP for a variety of machines are
available from ftp.lysator.liu.se:pub/tap.


2. Technical incompetence

IDENT is technically incompetent and of low quality. It does not
interoperate with itself. It is far too complex for the job it performs;
it requires far more implementation effort than TAP, which supports the
same applications. The primary reference for this section is the StJohns
document.

For this section it is useful to have the following view of the
relationship between IDENT and the Finger protocol: Finger returns
host-specific information about a specified username; IDENT returns
host-specific information about a specified TCP connection.

***** The most incompetent technical feature in IDENT

IDENT, like Finger, is a request-response protocol. The client connects
to the server and sends a request. If something goes very wrong, the
server closes the connection (this is a negative response); otherwise
the server sends a response to the client.

In Finger (and TAP), both sides then close the connection. This is not
true of IDENT. The StJohns document states ``The server may then either
shut the connection down or it may continue to read/respond to multiple
queries.'' The apparent purpose of this provision is to let the client
fire off a sequence of requests to the same host. It is not clear when,
if ever, this feature would be desired, or why it is a significant
improvement over having the client make a new connection for each
request; but I will not address these issues in detail.

The fundamental problem with this feature is that _it cannot be used
safely_. To put it bluntly, _IDENT does not interoperate with itself_.

Here is the explanation. How is a client supposed to take advantage of
the multiple-request feature, even if it wants to? If it is talking to a
single-shot server then it has to package its requests separately.
Unfortunately a client cannot tell reliably whether this is the case.

Many flawed protocols are designed under the assumption that TCP
transmits packets instantly from one side to the other. (See RFC 854 for
an example; RFC 1143 describes two flaws which showed up in BSD UNIX
implementations of RFC 854.) If TCP were indeed instant then the IDENT
client would know instantly if the server were a single-shot server,
because the TCP connection would be closed immediately after the first
response.

But TCP suffers delays. The client might not find out that the TCP
connection has been closed until after it has sent a second request. In
this situation it has absolutely no way to tell whether the closed
connection comes from a single-shot server behaving normally or from a
multiple-shot server giving a negative response. If it assumes the
first and retries its connection, then it will end up wasting time and
sending useless data to single-shot servers, and it may loop in talking
to multiple-shot servers. If it assumes the second, it will lose data in
talking to single-shot servers.

When the first IDENT client implementors attempt to use this feature,
they will either lose data or send useless data. This protocol feature
is of extremely low quality and is technically incompetent. It
encourages an extraordinarily unreliable style of network programming.

***** Identifier interpretation

As documented below, IDENT defines several aspects of the interpretation
of identifiers _internal_ to one of the hosts. This complexity is, in
general, unnecessary: Finger (and TAP) transmit data between hosts which
have never talked before, perhaps with some conventions but never with
any guarantees as to the interpretation of the data, and still they are
useful (and used) in the global Internet. These protocols simply
transmit octet strings. So such interpretation serves no purpose.

Furthermore, protocol-based interpretation of identifiers is the problem
at the heart of many security failures in the Internet. For instance,
the global ``+ in rhosts'' problem arises from an unwarranted
interpretation of identifiers in the rlogin protocol. It is reckless
from a security standpoint to encourage people to act along these lines
by defining any sort of internal interpretation of the data transmitted
by IDENT.

***** Miscellaneous

The StJohns document defines the information returned by IDENT as ``the
identity of a user of a particular TCP connection.'' This is
unnecessarily limiting: the syntax and structure of IDENT are perfectly
capable of handling per-connection information other than usernames.
Because ``user'' is not defined in the StJohns document, some clients
will assume that it has a particular meaning (such as an SMTP address)
and will not work properly if given ``user'' information which does not
conform to that meaning. Furthermore, as noted above, a protocol has no
business dictating the interpretation of an identifier _internal_ to one
end of the connection: it should be of no relevance to IDENT whether the
information represents usernames, process identifiers, system locations,
or anything else.

An IDENT server is supposed to close a connection down ``after a
configurable amount of time with no queries - a 60-180 second idle
timeout is recommended.'' First of all, in practice, there is no need
for the _server_ to worry about timeouts. Second, the suggested timeout
is far too short for many wide-area connections in the current Internet,
and will certainly cause data loss. A two-hour timeout as in most NNTP
implementations would have been a far more competent choice. Third, the
timeout requires extra implementation effort (including a
user-configurable option!) with no obvious applications. Finally, it is
not reasonable for the StJohns document to dictate administrative
policies such as how long servers should run.

IDENT includes a character set identifier. This identifier must be
recognized by all client implementations and thus makes implementations
much more complex. Finger has no character set identifier; why does
IDENT need one?

According to the StJohns document, ``the character set identifier is
used to indicate the character set of the identification string.''
However, the document does not define what ``the character set'' is
supposed to _mean_. If the character set serves no purpose other than to
indicate that certain characters will not appear in the coming text,
then it is an entirely useless field, because that purpose is equally
well served by an inspection of the text. If, on the other hand, the
character set is meant to dictate the _interpretation_ of the
information returned by IDENT, then it is dangerous for the reasons
mentioned above. One might also wonder why a character set is necessary
for data which does not have to be printed for human consumption.

Some existing character sets (such as UNICODE) permit meaningful text
strings which include octets with the values 10 or 13. These octets
could easily cause trouble for an IDENT implementation. How should a
server behave if it wants to send such a string? The StJohns document
does not say. This omission is incomprehensible.

The StJohns document requires that the username information be linked to
the OS information returned by the protocol: if the OS field is anything
but ``OTHER'' then the username information is supposed to be usable
with finger or mail. This linkage is unfortunately not well enough
defined to be usable in any applications: the server system is not
_required_ to support finger, let alone to allow IDENT identifiers as
finger arguments, even if it uses an OS field which is not ``OTHER''.
If the client wants to know whether an identifier is usable as a mail
address, it has no choice but to try out the identifier---exactly as if
the information had not been transmitted. So this linkage serves no
purpose. Also, it dictates the _interpretation_ of the information
returned by IDENT and thus is dangerous for the reasons mentioned above.

An IDENT server may send predefined tokens (such as ERROR) in any
combination of uppercase and lowercase. So a client must be prepared to
translate lowercase ASCII into uppercase ASCII before checking the
result against an expected sequence of bytes. This complexity is utterly
pointless: an IDENT server is not a human and does not see any
convenience in sending lowercase tokens.

When the character-set field of IDENT is anything but OCTET, whitespace
at the beginning of an identifier is ignored. But when the character-set
field is OCTET, whitespace is significant, and is considered part of the
identifier. What rhyme or reason dictates this distinction? This
requires that clients use _content_-dependent parsing, where the later
parts of a line are not parsed until the earlier parts have been
decomposed and checked against OCTET---an especially onerous detail on
many machines as OcTEt is a permissible replacement for OCTET.

The StJohns document provides a BNF grammar, but the BNF is incorrect.
For instance, 3 , 5 : ERROR : HIDDEN-USER is (and should be) permitted
as a reply, but the BNF does not generate it. I do not know what other
errors are lurking in the BNF; in any case, this is not the mark of a
high-quality document.

The StJohns document states ``Any error not covered above should return
this error code value,'' namely UNKNOWN-ERROR. This directly contradicts
the later statement that an implementor can define his own X-errors. One
might assume that the second statement takes precedence, but unresolved
contradictions are not the mark of a high-quality document.

An IDENT server ``is allowed to drop the query connection without
responding'' in all cases; this is given the same meaning as
UNKNOWN-ERROR. (For comparison: In TAP implementations this is allowed
only for INVALID-PORT. The point is to give the server an out if the
client is misbehaving, not to let the server be obnoxious.) In IDENT a
perfectly valid client request may be answered by a closed connection.
Why, then, does IDENT even bother defining an error code for
UNKNOWN-ERROR? Furthermore, if the network or server host has temporary
trouble, the IDENT connection may be closed accidentally; a conforming
IDENT client will have to assume that this was intentional, because it
obviously cannot make a policy of retrying upon any error. (For
comparison: In TAP, a client which sends a valid request can safely
retry---or check its request format---upon a closed connection.) It is
not clear how often this will cause serious data loss.

The StJohns document states ``The information returned by this protocol
is at most as trustworthy as the host providing it OR the organization
operating the host.'' The concept of ``operating'' is an internal matter
with no relevance to this protocol. Furthermore, the document does not
define ``trustworthy,'' and with at least one definition of
``trustworthy,'' the statement is false. Trust (or its lack) in some
data is dependent upon having assigned an _interpretation_ to the data.
If a client interprets its receipt of the identifier ``joe'' from a
server as conveying the (intrinsic) information ``According to TCP I
received the identifier joe from that server,'' then this information is
unquestionably true and does not depend on the trust which can be placed
in the server host.

The StJohns document states ``The Identity Protocol is not intended as
an authorization or access control protocol.'' It goes on to say ``The
use of the information returned by this protocol for other than auditing
is strongly discouraged'' and several similar statements. This
restriction, known as ``the auditing restriction,'' eliminates many
valid applications of IDENT. For one example of a perfectly valid access
control application of TAP (for which IDENT could also be used) used on
the Internet today, see ftp.lysator.liu.se:pub/ident/doc/why-tap.txt.
The application is called ``selective blocking'' and has traditionally
been the competent security officer's first response to an attack.

The StJohns document contains ample evidence of carelessness on the part
of its author, ranging from inconsistent use of the protocol's name
through a factually incorrect analogy between IDENT and Caller-ID.
(Caller-ID is a service on the part of the network provider which shows
the origin of a connection in the telephone network. It is _the return
address in a TCP/IP packet_, not IDENT, which shows the origin of a
connection in the Internet. IDENT is not even a service on the part of
the network provider.) These mistakes together form a very low-quality
document.


3. Incompatibility

IDENT is incompatible with current use of TCP port 113 for the TAP
protocol. Current use of TAP is heavy, and IDENT's incompatibilities
with TAP are severe. Because of this, IDENT cannot possibly be useful in
the Internet. Note that this problem stems directly from IDENT's use of
port 113; if IDENT used a different port then all compatibility issues
would disappear. The four references for this section are the StJohns
document, the TAP specification, the NIC NSFNET statistics available
from nic.merit.edu:nsfnet/statistics, and the multiple available
implementations of TAP.

***** Current use of port 113

According to the most recent available NSFNET statistics, there were
nearly half a million packets for port 113 across the T1 backbone in
June 1992. Only thirty protocols out of several hundred named in the NIC
report had higher packet counts.

To my knowledge, all existing use of port 113 complies with the TAP
specification (and thus is compatible with my first TAP implementations
from early 1990). Six independent TAP server implementations (which are
not the only ones available) are available from ftp.lysator.liu.se; two
of the servers support various BSD machines, and the others support AIX,
Apollo, NeXT, and TOPS-20. At least two independent TAP client
implementations are available.

I know of 179 Internet hosts running TAP servers. I will not reproduce
the list here. You can pick up the list from 128.122.142.2 port 19313.

I believe that, for every feature permitted in the TAP specification,
there is an implementation which uses that feature. I thus believe that
any incompatibility with the TAP specification is automatically an
incompatibility with current use of port 113. However, I am not sure of
this, and in the descriptions below I will restrict my comments to TAP
features which I have seen used on the Internet.

***** IDENT incompatibilities with TAP

Note that many of the incompatibilities listed below are probably not
serious incompatibilities---I doubt they'll have much effect. However,
some of the incompatibilities are serious, in the sense that they _will_
cause data loss or other real problems if IDENT servers and clients are
allowed to talk to the servers and clients currently using port 113.

The StJohns document limits IDENT to transmitting usernames. Some of the
current use of TAP for transmitting information other than usernames,
analogous to the use of finger to transmit weather information, is not
permitted by IDENT. (This is probably not a serious incompatibility.)

An IDENT server may accept multiple requests. Except as experiments, TAP
servers do not read past the initial request line. Even if IDENT could
interoperate properly with itself in this respect (see section 2), an
IDENT client would be allowed to send multiple requests, which a TAP
server would simply throw away. (This is probably not a serious
incompatibility.)

A TAP client has the right to take its time forming a query, and can
expect the TAP connection to be just as reliable as any TCP connection.
However, if it is talking to an IDENT server, it may find the connection
closed for no good reason after 60 seconds. This ``timeout'' will cause
data loss, as current TAP servers do not retry connections. I have
measured network and machine delays exceeding three minutes.

IDENT character sets have no parallel in TAP. Fortunately the IDENT
character set default has been changed so that an IDENT server will
correctly assume it is receiving pure octets when it talks to a TAP
client. However, an IDENT server is permitted to send an identifier
containing (e.g.) a zero octet as part of UNICODE text. Any remaining
data on the line will be lost by existing TAP clients.

The OS linkage defined by the StJohns document is an entirely obsolete
and never-implemented remnant of RFC 931. Some existing TAP servers send
a <systemtype> of UNIX but send connection information which cannot be
used as SMTP identifiers, or Finger identifiers, in violation of Ident.
Furthermore many existing TAP servers send a <systemtype> of UNIX even
though they are actually running under, e.g., SunOS, again in violation
of Ident. (This is probably not a serious incompatibility.)

IDENT gives special treatment to OCTET, the default character set. An
IDENT server may send ``3,5:USERID:OTHER: f!^'' and expect the client to
notice the space before the ``f!^''; a TAP server will throw such spaces
away. (This is probably not a serious incompatibility.)

IDENT's spacing in general is not compatible with TAP's. An IDENT client
may send the line `` 3,5''; a few existing TAP servers will fail to
parse this line because of the leading space. The same problem may occur
between an IDENT server and a TAP client. This will cause data loss.

An IDENT server may send tokens such as ``octet''. I do not know of any
existing TAP client which will recognize this as an alternative spelling
of ``OCTET''. This will cause data loss.


4. History

The history of IDENT explains the incompatibilities and technical
failures documented above. It also provides several reasons for the IESG
to reject the StJohns document. The absence of an event from the
historical summary below does not imply that the event did not happen,
except where the summary specifically says so. The primary reference for
this section is the IDENT mailing list.

The single most important source of contention is ``the auditing
restriction,'' which has been in the StJohns document since its
inception. As documented below, at least seven of the twenty-odd group
participants have objected to this restriction, proposed compromises,
and given examples where the restriction is a bad idea; yet Mike StJohns
continues to insist that ``the issue is CLOSED.'' The auditing
restriction illustrates practically all the reasons that the StJohns
document does not reflect the consensus of the community, and it is the
primary topic below.

***** History of earlier RFC 931 variants

Here is some background information.

In September 1984 Mike StJohns published RFC 912, a proposed protocol
describing the first version of the Authentication Server. In January
1985 he updated it to RFC 931, which specified the syntax a bit more
carefully and added a system type field to the server's output. Some
time after that the protocol was demoted from ``proposed protocol'' down
to ``experimental protocol.'' However, port 113 was still assigned to
the protocol.

In early 1990 I implemented RFC 931 and distributed the ``auth'' and
``authutil'' packages on comp.sources.unix. auth included a portable
server implementation for BSD 4.2 and up, but the server depended on
people making connections through the authtcp and attachport programs
included in the package.

In February 1991 I distributed authd 3.01, which worked fine with
connections made by standard programs like telnet, sendmail, and so on.
This implementation caught on. Since then the use of port 113 has
increased dramatically. Before the end of that year there was a second
independent interoperable server implementation, and then a third, as
well as a wide variety of client applications (for sendmail, talk,
nntpd, inetd, ftpd, irc, et al.). In the meantime new server sites began
to spring up everywhere.

In June 1991 I wrote an RFC 931 revision describing what I had done. The
protocol described there is now known as ``TAP''; it is mostly but not
completely compatible with the never-implemented RFC 931. (Specifically,
TAP does not recognize quoted usernames which an RFC 931-compliant
server might send; and TAP defines many vague areas in RFC 931 which
could lead to incompatibility, such as spacing.)

In July 1991 I submitted my RFC 931 revision to Steve Crocker. This
began a year-long attempt to publish the revision as a Proposed Standard
to guarantee future interoperability. The attempt failed. There was an
interoperability problem in November 1991, which was corrected quickly.
Between January 1992 and April 1992 TAP was known as ``Ident''; this has
caused some confusion. In July 1992 I created the ad-hoc TAP-std working
group to finish documenting TAP. As of August 1992 TAP-std had
essentially completed its first spec. See section 5 for further details.

***** Broad outline of IDENT history

In March 1992 Steve Crocker created an IETF mailing list, ident, to
define a protocol in place of RFC 931. (ident was supposedly created in
response to my request from July 1991, though its charter did not
reflect my desire to ensure compatibility with current use.) Soon
afterwards ident became an IETF working group. Crocker placed Mike
StJohns in charge of the group.

Roughly 500 messages were sent to the ident list in April, May, June,
July, and August by twenty-six people. Fourteen of these people (Bob
Forrest, Icarus Sparry, Christopher Davis, Dave Crocker, David Borman,
Anders Andersson, Theodore Ts'o, Steve Crocker, Steve Bellovin, Mark
Baushke, Peter Eriksson, Steve Kent, Mike StJohns, and me) were heavy
participants, sending more than five messages each. Other participants
were Ned Freed, Phill Gross, Mark Andrews, Marshall Rose, Simon Leinen,
Hank Nussbacher, James Galvin, Dean Throop, Stefan Linnemann, Wes
Morgan, Alexander Dupuy, and Vint Cerf; I believe but am not sure that
this list is complete.

There was an Ident meeting on 14 July 1992; Mike StJohns never announced
it on the Ident list, and nobody brought it up on the Ident list before
early July. Of the group participants, the only attendees were Mike
StJohns, Steve Crocker, David Borman, Theodore Ts'o, Marshall Rose, Mark
Baushke, and Ned Freed. Of the dozens of ident mailing list recipients
who did not participate in mailing list discussions, fourteen attended:
Brad Rhodes, Walt Wimer, Steve Alexander, Jeremy Siegel, April
Richstein, Tom Farinelli, Cliff Frost, Peter DiCamillo, John Wagner, Luc
Boulianne, Barbara Fraser, Rob Shirey, Pria Graves, and Chas DiFatta.

There have been no other Ident activities to my knowledge.

***** There is no consensus on the security section

The StJohns document includes a security section, although Phill Gross
told me ``probably yes'' when I asked if it would be a good idea to
split off the security section into a separate document. StJohns wrote a
restriction, known as ``the auditing restriction,'' in his first
security section, and this restriction has remained unchanged through
the current StJohns document. In essence the auditing restriction
prohibits all use of Ident except for auditing.

I intend to demonstrate here an extraordinary lack of consensus on the
security section---in particular, the auditing restriction. The auditing
restriction has been the single most important source of contention in
the StJohns document, is responsible for far more messages on the ident
mailing list than any other topic, and has not to date been settled.

Background: I would prefer an empty security section to the current
security section, simply because of the horrendous damage that the
auditing restriction will do to the current and future use of this
protocol. In particular, the auditing restriction prohibits selective
blocking, as described in the why-tap paper referenced above. I have
proposed three compromises, labelled ``proposed a-a compromise,''
``second proposed a-a compromise,'' and ``different proposed
compromise''; Peter Eriksson has proposed a compromise; and Dave Borman
has proposed a compromise. All of these compromises have been ignored.

Here are some historical facts demonstrating that a significant number
of group participants have objected to the auditing restriction. By any
reasonable definition of ``consensus,'' there is no consensus on the
security section.

A. On 8 April 1992 Stefan Linneman pointed out the selective blocking
application and explained why it is useful in the real world. He stated
that the auditing restriction ``is wrong'' and stated ``So if you want
an accurate RFC, you should acknowledge the fact, that it can and will
be used for authentification of sorts.'' He supported my proposed a-a
compromise.

B. On 6 April 1992 Bob Forrest stated ``This sounds good'' in response
to my proposed a-a compromise. In support of my second proposed a-a
compromise, he stated that he was in favor of leaving in the possibility
of using the protocol as a supplemental security measure for
authentication, and gave an example where this is useful. In May 1992,
after Steve Kent's objection to the ``style'' of my different proposed
compromise, he asked where the ``style'' was documented (he was never
answered)---see below. He asked ``How do we get past this difference in
opinion about whether the protocol should be restricted to not be used
as any form of authentication or not? Do you vote on it?'' On 19 May
1992 he supported Peter's proposed compromise.

C. On 11 July 1992 Icarus Sparry stated ``Let me put on record that I am
not happy with the current security section, and I think it should be
removed rather than left in its current form. This applies to any
version which has the same security section.'' He maintained the same
position in other messages.

D. On 11 July 1992 Christopher Davis expressed his agreement with the
statement of Icarus Sparry quoted above. He said that he thought
Borman's compromise was better than the current security section. Back
in April he had given two examples of valid authorization uses of the
protocol.

E. In mid-July 1992 Anders Andersson pointed out the situations in which
an SMTP server could validly be set up to reject mail not accompanied by
the proper IDENT information; of course, this application is prohibited
by the auditing restriction.

F. On 6 April 1992 Peter Eriksson supported Dave Borman's proposed
compromise. Later he supported my different proposed compromise.

There; that makes a total of seven people (counting me) who have, on the
mailing list, expressed their objections to the security section and
supported changes. How can one possibly justify the statement that there
is consensus on the section?

***** Other comments on the security section

Some people who haven't objected to the security section have
nevertheless made comments demonstrating the lack of consensus. Here are
three examples: In early April Dave Borman talked about ``where I am
hearing the disagreement'' and proposed a compromise security section,
though he did not express support for one side or the other; in July he
did the same thing. On 25 May Steve Bellovin stated that he did not
believe that IDENT had achieved ``any consensus.'' On 15 May Steve Kent
stated ``Your claim of consensus for the appropriateness of using Ident
for more than auditing is no better substantiated than the claim of
others on this list that there is a consensus for restricting Ident to
audit applications.''

I do not recall seeing any defense of the security section from anyone
other than Steve Kent, Mike StJohns, Steve Crocker, Ted Ts'o, and Mark
Baushke, though I am not sure. Unfortunately Kent, StJohns, and Crocker
are in a position to ignore any number of objections: StJohns has power
as working group chair, Crocker has power within the IESG, and Kent
apparently has power within the IAB.

I still believe that my ``different proposed compromise'' would be
workable. I have brought it up three times now on the ident mailing
list. Here is a complete summary of all reactions to it: 12 April: Peter
Eriksson states ``it sounds good'' but points out a wording problem.
12 April: Vint Cerf talks about it and does not mention any problems.
13 April: Icarus Sparry agrees with Peter on the wording problem (which
I subsequently fixed). 13 April: Steve Kent lists his objections: ``The
long series of warnings is too obscure, extremely ugly, and not
consistent with RFC style.'' 14 April: Ted Ts'o agrees with Steve's
objections. 19 April: Mike StJohns comments on a separate issue and
doesn't bring up any problems. There were no other responses.

So on one side we have the StJohns document, with a security section
which has more public enemies than supporters---a security section which
has been criticized on several theoretical and practical grounds. On the
other side we have ``different proposed compromise,'' which two people
have criticized because they say it is long and ugly. Why has the former
not been replaced with the latter?

Since April, StJohns has explicitly refused to discuss the security
section. He has not conducted any votes on the ident list. Because he
did not announce the one ident meeting on the ident list, many group
participants---in particular, the seven people who objected to the
security section---were unable to attend; Mike StJohns did conduct a
vote on the security section at that meeting, and based on that vote
(where he ignored some votes in absentia which were stated in advance)
stated that the security section was closed. That vote was a sham.

StJohns has sent approximately 50 messages to the Ident mailing list.
In those messages he has made each of the following statements: ``draft
has been removed from consideration for cause''; ``Statement stands...
I'm not planning on addressing this issue''; ``As such it will go
forward with those mods and no others''; ``I'm declaring it out of order
for the Ident list''; ``I've basically taken to ignoring your
objections''; ``I'm saying that one complaint does not a problem make'';
``section is CLOSED''; ``As I've said before I will not contemplate any
further changes in the security section.''

This is dictatorship on the part of Mike StJohns. Mike StJohns has
repeatedly stated his _personal_ refusal to consider objections or to
change the StJohns document in ways requested by the bulk of the working
group. He has _personally_ declared items out of order despite the
desire of the rest of the mailing list to discuss those items.

In particular, despite the complete lack of consensus on the auditing
restriction, StJohns has gone ahead and submitted his document to the
IESG. This is a travesty of an otherwise honorable standards process.

***** Comparison of StJohns group to Bernstein group

In this section I will compare StJohns's handling of the ident working
group, an IETF effort, to my handling of the TAP-std working group, a
non-IETF effort. For obvious reasons I will restrict my comments to
objectively verifiable summaries.

The corresponding mailing lists each have several dozen subscribers
(with considerable overlap). The ident group was created in April; the
TAP-std group was created in July. Each group chairman had a supposedly
finished document by the end of August.

Every issue discussed on the TAP-std mailing list has been summarized by
the chairman on a ``TAP-std summary sheet,'' which lists motions, all
views brought up, tentative resolutions, and actions, with dates. Issues
were opened or closed solely by virtue of the presence or lack of
discussion; no issue was acted upon if it was still being discussed.
Some issues have been reopened by request of group participants. Every
change to the TAP-std document from the base TAP-std document was the
result of a motion discussed on the mailing list.

In contrast, the ident mailing list has had items closed by fiat. The
chairman has failed to follow the usual rules of order by refusing to
allow motions to be discussed _even when the motions were seconded_.
(Example: ``different proposed compromise.'') Most changes to the
StJohns document were the personal actions of the author; in the cases
where issues were discussed on the mailing list, the chairman often
acted before the group participants finished discussing the issue, and
often refused to open the issue for reconsideration.

The TAP-std mailing list has not suffered any procedural complaints. Its
chairman has stated an explicit policy of reading every message and
handling every issue according to the wishes of the group. No TAP-std
participant has claimed that the final TAP-std document does not reflect
the consensus of the group.

In contrast, the ident mailing list has suffered procedural complaints
from several people: its chairman has been accused of incompetence and
malicious interference with group business. The chairman has stated an
explicit policy of ignoring messages and ignoring objections, and has
not stated a policy of obeying the wishes of the group. Some ident
participants have stated that the StJohns document does not reflect the
consensus of the group.

***** Other historical information

There are many technical problems listed in section 2 of this document,
and many compatibility problems listed in section 3. This is certainly
not the first time they've been brought up. In fact most of them were
brought up by various people in April and May, along with a wide variety
of suggested fixes. On 26 June, upon request, I sent to the ident
mailing list a summary of the 73 problems I knew about with the StJohns
document. StJohns ignored my list completely. Nobody responded to the
complaints.

The truth came out two weeks later: StJohns admitted that he had a
policy of ignoring my objections. Three people immediately leaped to my
defense and asked StJohns to pay attention to my list. StJohns did not
did so. Nobody defended StJohns's behavior---he simply ignored the
objections. This is why so many problems still remain with the StJohns
document. This history also demonstrates an incredible lack of consensus
on the document.

***** Some extended quotes

Here are some quotes backing up the summaries above. Stefan Linneman:
``Excuse me, but I'm getting sick of this constant failure of
understanding of <people of the IETF, including but not restricted to
Stephen Crocker> of Dan Bernstein's point of view... Dan Bernstein has
repeatedly written, that all and any input on the text describing the
standard, whether from the IETF or from elsewhere, will be considered
and argued, and, if appropriate, included in the document. When reading
the latest revisions, he also showed quite clearly, that this is so:
several comments from <members of the IETF> have been accpeted by Dan
and were included in these revisions. Any comment from <members of the
IETF> on that have as yet to appear. Instead the have waged some kind
of war on Dan in order to gain full control of the text of the document,
never commenting on the *reasons* why Dan is reluctant to give this.''
(This was at the creation of ident, when Steve Crocker was removing my
control over the document and placing it under control of Mike StJohns.)
``We're trying to get a standard here, and Dan has proven himself, which
the IETF has as yet to do.''

Mike StJohns: ``From my point of view, there was enough "consensus" to
move the MIB document along - i.e. no pending complaints or actions. And
before you react about the security section - read further.'' (The ident
MIB has essentially the same security section, with the same auditing
restriction.) ``Dan - you appear to live in a dream world... We've
wasted enough time on the [security] section and I have no plans to
reopen it for revision... I've basically taken to ignoring your
objections *UNLESS* they are also made by someone else - I figured if
the objections were *real* someone else would come to your defense.''

Icarus Sparry, in response to StJohns's comments above: ``OK, I leap to
Dan's defence. I will agree that some of Dan's 73 points are amusing,
but they should still be considered. Dan did a very good job of getting
people interested in a protocol which ran on port 113, and as such
deserves to be listened to with great care... If you were unwilling to
take on the workload, then perhaps you should not have accepted the job
in the first place. I for one have not sent in messages saying 'I agree
with Dan' each time I think he is right. This mailing list appears to
have far too much in the way of politics and noise as it is. If you were
going to ignore everything which Dan said, unless it was supported by
someone else, then you should have said so clearly. I would then have
chipped in when I thought he was right. While there have been hints that
you were ignoring him, i.e. you very rarly replied to the points he
made, it should have been made clear.''

Christopher Davis: ``I wholeheartedly agree with the preceding
paragraph. Had I known that even technical items brought up by Dan were
going to be ignored, I would have taken the time to bring them up myself
(when I concurred with them, of course). I have certainly not been a
sycophant for Dan Bernstein in general (indeed, I've gone out of my way
more than once to needle him) but I feel that, within the constraints
inherent in the approach, some form of TAP/ident/RFC931 protocol is
*useful* and *important* and I am getting rather tired of playing
political games about it when I could be spending time on other things...
I'm still not sure where the whole character set thing came from (nor
why)...''

Anders Andersson, in respose to StJohns's comments above: ``Now, this
came as a surprise to me. I joined the IDENT list by the beginning of
June, and I thought I received enough input that I wouldn't need to
locate an archive to read all messages that had already passed. I had no
indication that Dan was considered persona non grata on the list. If you
have a personal squabble with Dan, please carry it out elsewhere, and
try to restrain yourself to technical arguments on the IDENT list. I
have myself complained about the username issue, but I feel I have not
been understood. I've read Dan's comments on the same issue and various
other things, and I believe I agree with him at least on the points I
feel concerned with. I didn't feel I had to repost his opinions for mere
quantitative reasons (that's what you do in politics, but I feel we
could use a slightly more systematic approach here), nor did I believe I
could provide his thoughts with a better wording (hey, English isn't
*my* native language here). I waited for some response. The fact that a
new version of the draft without any significant changes were announced
on the IDENT list a few days *after* some of these technical complaints
is something I attributed to somebody's e-mail processing lag. As I saw
no technical objections being raised to Dan's comments (or mine, however
diminutive), I thought maybe some appropriate changes were about to
appear in the *next* version anyway, so I didn't raise a fuss then. I
also sent you (Mike) personally a message asking for the specifics
regarding any schedules, deadlines or the like for this draft, since
I was totally unfamiliar with this RFC drafting procedure... What you in
effect is saying is that members of the list should repost everything on
the list they agree with, simply because you may not be on speaking
terms with everybody who contributes. I consider this an extremely
counterproductive and wasteful procedure. Sticking to technical
arguments (as I think many would like to do) does not only mean avoiding
non-technical arguments. It also means responding to technical arguments
with something else than silence.''

***** Community review of the StJohns document

A separate issue from consensus is that of community review. It is not
at all clear that the StJohns document has received adequate community
review.

Mike StJohns has a habit of being mysterious about exactly what the
current document contains. At one point he sent two alternate versions
of his document to the mailing list! It seems that every document he
sends is prefaced by a note ``I still have to change X and Y and Z.''
The only exceptions were the two revisions submitted as Internet Drafts,
one (by now hopelessly obsolete) in early June and one on 25 August.

There has not been sufficient time since 25 August for anyone to explore
the latest draft in detail. One would expect that a document which had
been adequately reviewed by the community would not contain such
bloopers as the entirely useless multiple-request feature in the StJohns
document (see section 2).

I question whether the StJohns document has received adequate community
review. StJohns's practices in dealing with the mailing list, together
with his extremely rushed schedule (he submitted his document to the
IESG before it even appeared as an Internet Draft), conspire to remove
nearly all opportunity that a typical IETF member might have to review
the document.

***** Summary

It is not an accident that the StJohns document---and thus the IDENT
protocol---has all the problems I described in sections 2 and 3: the
document is the personal creation of Mike StJohns, who _repeatedly_ and
_explicitly_ refused to tolerate the discussion of those flaws on the
ident mailing list. He ignored my list of 73 problems, and when three
people (plus me) criticized (and nobody defended) this behavior, he
continued to ignore the problems.

The StJohns document cannot possibly be construed as the consensus of
the community. Seven ident participants have criticized the current
security section---in particular, the auditing restriction---yet Mike
StJohns has repeatedly declared that the issue has closed and repeatedly
refused to consider alternatives (even my ``different proposed
compromise,'' which seemed reasonably well liked). Three more group
participants have indicated that there is no consensus on the security
section. Even if the other fifteen or so group participants had all
stated their support for the security section (and in fact only a few of
them did), who is to say that the fifteen are right and the ten are to
be ignored?

StJohns never held any votes on the ident list, even when he was asked
to do so. He did hold one vote, at an ident meeting which he did not
announce beforehand---where the seven people who criticized the auditing
restriction were not present. StJohns repeatedly acted before checking
his actions with the group.

Put simply, the StJohns document is not in fact a submission of the
ident working group. It is the sole responsibility of its author.


5. Further information

This section does not detail problems with the StJohns spec. It gives
further information and some personal comments.

In July 1991 I tried to publish what I had done with port 113---to
propose it as a standard for the Internet community. I'm sorry I ever
made the attempt. Let me explain this. There was only one
interoperability problem (to my knowledge), and that was fixed quickly.
Now, a year and a half after my first really usable TAP implementation,
TAP use has taken off---half a million packets for the port per month
on the T1 backbone alone. The rfc931-users mailing list maintains a
record of all server sites brought to its knowledge---179 right now. And
there are more TAP applications than I had ever dreamed would arise. All
of this happened _without IAB/IESG publication_.

So why am I sorry? Because my attempt to publish the TAP spec is leading
to disaster. If the StJohns document is published then (as I pointed out
in full detail in section 3 above) port 113 will be rendered practically
useless by incompatible IDENT use. The IESG is getting involved, via
Steve Crocker, and TAP's future no longer looks so bright. Is this
really what the IAB/IESG is supposed to do?

The TAP-std group has been remarkably cooperative. Thanks go to all its
participants; as per the TAP-std charter, we seem to have a complete,
accurate specification of the protocol used on port 113 of the Internet
today. (See ftp.lysator.liu.se:pub/tap/doc/TAP.RFC.) Right now there's a
motion on the floor to publish the spec by whatever means are at our
disposal; I don't know if the motion will pass.

Unfortunately, no matter what happens, we won't be able to publish our
document as an Informational RFC. I had asked the RFC editors (who were,
in the past, somewhat cooperative) what changes would be necessary if
TAP-std were to decide to publish the spec this way. On 4 September 1992
I received a message from one of the editors stating ``After careful
consideration, your request for publication of TAP as an informational
RFC is hereby declined.'' Never mind the fact that I hadn't yet made any
such request; here was the reason: ``It is important that informational
RFCs be clearly distinguished from RFCs documenting protocols on the IAB
standards track... It is clear that the functional capabilities and
protocol mechanisms of TAP and IDENT are so similar that there is little
information to be gained by comparing the two. It is the RFC Editor's
determination that publishing the TAP document as an informational RFC
at this time would not make significant additional information available
to the Internet community and could lead to confusion.''

First of all, what is ``significant additional information'' supposed to
mean? Wake up, IESG: in the eyes of the 150 people receiving the
rfc931-users mailing list, it's pretty damn important information
_what's actually done on port 113_! This is something which the StJohns
document doesn't provide. Second, I must say that I resent the
comparison of TAP, a technically sound protocol, with IDENT, a protocol
with such serious technical problems that it doesn't even interoperate
with itself. Finally, ``confusion'' is such a red herring that I can
hardly believe that the RFC editors' decision wasn't mere politicking.
If you people can publish both POP-2 and POP-3, then you can publish
both IDENT and TAP. Please stop this censorship.

Some people have asked me why I don't support IDENT. ``You're getting
what you wanted,'' they say; ``the protocol is being standardized.'' But
it's _not_ the protocol which runs on port 113. It's a different
protocol. Oh, sure, the incompatibilities would be easy to fix, but they
aren't fixed, and they're severe enough to cause really serious
interoperability problems (like lost data). That's why I'm not happy.
(I'm also extremely displeased with the auditing restriction, but that's
something which anyone with a brain can ignore.)

Actually, it's not just the incompatibilities which would be easy to
fix. The technical problems are also easy to fix. I have a constructive
proof of this: TAP. The protocol has remained unchanged for more than
two years and, unlike IDENT, is technically sound.

I don't understand what Steve Crocker and Mike StJohns are trying to do.
They seem to be in a position to push the StJohns document forward no
matter how many objections are raised. All their actions are
_consistent_ with the theory that they are trying to destroy TAP by
standardizing an incompatible protocol which uses the same port, though
I can't rule out the possibility that there's some other explanation for
their behavior. If they're really trying to act on behalf of the
community, why don't they stop shoving IDENT so hard and start listening
to what the community has to say? Neither StJohns nor Crocker uses the
protocol.

Here's a relevant quote. Jon Kamens to one Dan Bernstein, 1 May 1990,
trying to convince the latter that this protocol was utterly useless:
``Anecdote time. The last time our Kerberos team talked to the NIC about
getting an official port for Kerberos, Mike StJohns (the guy who wrote
RFC 931) said (somewhat jokingly) something to the effect of, "Well, why
don't you just use the auth port? We'll never use it for anything, after
all -- it was a bad idea." '' Has Mike StJohns now decided that he has
to publish a de jure ``standard'' in order to kill the port?

When I try to convince the IETF (or the IESG---just because Steve
Crocker has been able to blind them so far doesn't mean they're all bad)
that there's a serious problem here, my worst enemy is stark disbelief.
``Oh, this can't possibly have happened---the StJohns document says it's
a submission of the ident group, so it must represent the consensus of
the group!'' I don't know how to overcome people's faith in a standards
process which certainly _appears_ to be as open as RFC 1310 might lead
one to believe. What I tried to do here (see the abstract above) was
shock the reader, by pointing out a truly idiotic technical problem in
the IDENT protocol. I hope that this shock will open people's minds
enough that they consider the possibility that I'm right.

I fear that StJohns will make a few trivial changes to his document and
assert ``the compatibility problems are gone.'' Then the IESG will
standardize his protocol, despite the remaining compatibility problems,
technical problems, and lack of consensus. I hope the IETF doesn't stand
for this behavior. We have to demand that the document be _rejected_:
sent back to StJohns with the message that he _has_ to pay attention to
his working group, _has_ to ensure _full_ backwards compatibility, and
_has_ to ensure adequate community review of his document.

One parting comment. Steve Crocker states that the current use of port
113 is ``poaching.'' If this is the attitude that the IESG takes towards
the Internet community, then I can understand why I'm having such
difficulties---I always thought of the IAB as _documenting_ what people
do on the Internet. I hope Steve Crocker is an isolated case. (His
behavior can perhaps be explained by his position within TIS, a company
which is doing significant business with RSADSI. I've worked for a long
time to destroy RSADSI. Crocker knows this.)

If you have any questions or would like further information, please send
a message to [e-mail]. I'll be happy to explain anything which
may be unclear.