list of 73 problems with ident draft

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

I have been asked to provide a list of problems with this group's
current document, draft-ietf-ident-idserver-00.txt. Issues are labeled
as ``easy,'' ``factual,'' ``technical,'' ``larger,'' ``constituency,''
and ``process.'' (Larger issues are basically technical issues, but
include issues such as ``what's the point to this unnecessary
complexity?'' Process issues are mainly items which weren't properly
discussed on the list before being slipped into the document.
Constituency issues refer to implementations of RFC 931 variants in
general; obviously there's no existing implementation of the Ident
protocol per se.

I have not attempted here to outline methods to fix the problems listed
below, for two reasons: (1) I don't have the time; (2) the methods have
all been stated before.

I count seventy-three individual problems below. I hope, but have not
made any serious attempt to verify, that this list is complete. On the
other hand, if each of the seventy-three objections is properly
addressed, I'll be so pleased that I won't care about the few minor
problems which remain. Lest this promise be misinterpreted: If StJohns
continues to slip new extensions and changes into the document without
waiting for the group to agree on them, then I probably will object once
again.

> 			Identification Server

Easy: The document doesn't consistently name the protocol.

>    The Identification Server Protocol provides a means to determine the
>    identity of a user of a particular TCP connection.

Larger: This is unnecessarily limiting. Also see below about
interpretation of identifiers. Constituency: Some of the current use of
ident (analogous to the use of finger to transmit weather information)
would not be permitted.

> The server may then either shut the connection down or
>    it may continue to read/respond to multiple queries.

Larger: There is no demonstrated use for this extension. Technical: It
is more difficult to implement a multiple-query server than a
single-query server. Constituency: This has not been implemented on a
wide scale.

> The server
>    should close the connection down after a configurable amount of
>    time with no queries - a 60-180 second idle timeout is recommended. 

Technical: The suggested timeout is too small for many wide-area
connections on the current Internet. Technical: In practice it is the
client, not the server, which needs to worry about timeouts. Larger: We
should not dictate administrative policies such as how long servers
should run. Larger: This timeout is unnecessary. Constituency: This
timeout has not been implemented.

> This means a user
>    on address A may only query the server on address B about
>    connections between A and B.

Easy: The misplacement of ``only'' makes this sentence confusing.

>    N.B - "local" and "foreign" are relative.  If there is a TCP
>    connection from host A to host B, <local-port> on host A equals
>    <foreign-port> on host B and <foreign-port> on host A equals
>    <local-port> on host B.

Factual: This description confuses the protocol concepts of <local-port>
and <foreign-port> with certain symmetries in a TCP connection. It is
thus incorrect. Larger: Why don't we just give an example?

>       The character set (if present) is seperated from the operating
>       system name by "///".

(I will ignore the issue of which separator is chosen; it looks like
people have settled on comma.) Technical: This makes implementations
somewhat more difficult. Constituency: This has not been implemented
before. Easy: ``separated.''

> The character set identifier is used to
>       indicate the character set of the identification string.

Larger: What is ``the character set of the identification string''
supposed to *mean*? This is a serious question. If the character set
serves no purpose other than to indicate that certain characters will
not appear in the coming text, then it's an entirely useless field. If
the character set serves to complicate the syntax (see below), then it's
worse than useless. Finally, if the character set is meant to dictate
the *interpretation* of the identification string, then it is dangerous
(see below).

Larger: The protocol at hand cannot be implemented until character sets
are laid down somewhere. Why are we damaging the protocol in this way?

>       A particular operating system identifier implies a specific
>       consistent format for the user identification string.

Larger: This remnant of RFC 931 is obsolete. Larger: The questions above
about character sets apply equally to ``format.'' Process: This
statement has been objected to, repeatedly, by many people, and has not
been justified. It should not appear in the document. Constituency: No
existing implementation uses the OS identifier to determine identifier
format.

> E.g.
>       "UNIX" implies an 8 character user id.

Factual: Many UNIX systems---including locally modified variants of
otherwise quite standard systems---support longer userids than 8.
Technical: For a typical client to obey this restriction requires
special handling of userids longer than 8 characters. (This applies only
to clients meant to be portable---i.e., all the popular clients today.)
Constituency: Existing implementations violate this restriction.
Process: This definition was not discussed.

>       "OCTET" indicates the identifier is an unformatted octet string
>       - all octets are permissible EXCEPT \000 (NUL), \012 (LF) and
>       \015 (CR).

Technical: For an implementation to support character sets, OCTET, and
OTHER requires a significant amount of special-case handling. Larger:
Existing use dictates an interpretation of all identifiers in the way
specified above for OCTET---but then what happened to the operating
system identifier, which was useful for separate reasons? Constituency:
No existing implementation supports OCTET. Process: OCTET has not been
discussed properly.

> N.B. - space characters (\040) following the colon
>       seperator ARE part of the identifier string and may not be
>       ignored.

Technical: This demands even more special cases in implementation.
Larger: Why are we insisting upon making the protocol more complex than
it has to be? Why are we damaging the protocol in this way? Process:
This change was not agreed upon. Constituency: All implementations
ignore white space after the colon. (I admit that this won't be a
problem unless someone naively changes ``OTHER'' to ``OCTET'' in some
code.)

> "OTHER" must be specified if there is no
>       registered format for a user id for this operating system,

Larger: Why are we making this restriction? This is obsolete, just like
operating-system-determines-identifier-format. Of course, if the latter
is fixed, then this problem will go away too. Constituency: Existing
implementations violate this restriction.

>          Can't determine connection owner; reason unknown.  Any error
>          not covered above should return this error code value.

Technical: This contradicts the extensibility of X-errors defined later.

>    In addition, the server is allowed to drop the query connection
>    without responding.

Constituency: In existing implementations this generally happens 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.

  [ BNF ]

Technical: Does this BNF agree with the text?

>       1) White space (blanks and tab characters) between tokens is not
>       important and may be ignored. 

Technical: This contradicts the previous statement about OCTET, and the
latter is not explicitly identified as taking precedence.

> specifically, any amount of white space
>       is permitted at the beginning or end of a line both for queries
>       and responses.
  [ followed by a modification for USERID ]

Technical: It complicates server processing to allow for ignored white
space at the beginning or end of a line in any situation. Larger: What
conceivable purpose is served by allowing white space at the beginning
of a line? Constituency: Existing server implementations violate this
requirement.

>       2) For purposes of comparison for all fields the USERID
>       field, uppercase is not distinct from lower case.  I.e.
>       "Error" and "ERROR" are the same value.

Easy: There's some editing problem here. Technical: This equivalence
complicates server processing. Larger: Why are we even bothering to
address this issue? What is wrong with simply saying that ERROR is the
token and not worrying about it? Constituency: Some (though not all)
existing implementations *do* distinguish between upper and lower case
in the userid field. Constituency: Existing implementations do not allow
lowercase for USERID or ERROR.

>       4) The 512 character limit on user IDs and the 64 character
>       limit on tokens should be understood to mean as follows: a) No
>       new token (i.e. OPSYS or ERROR-TYPE) token will be defined that
>       has a length greater than 64 and b) a server SHOULD NOT send
>       more than 512 octets of user ID and a client MUST accept at
>       least 512 octets of user ID.  Because of this limitation, a
>       server MUST return the most significant portion of the user ID
>       in the first 512 octets.

Technical: The words ``accept'', ``SHOULD NOT'', and ``MUST'' have not
been defined.

>       6) Although <user-id> is defined as an <octet-string> above, it
>       must follow the format and character set constraints implied by
>       the <opsys-field>; see the discussion above.

Easy: This is hopelessly redundant.

> Security Considerations:

Larger: Why are we discussing security here? Process: Despite the
general agreement of nearly everyone involved in the development of this
protocol that we should split the security section off into a separate
document, there's still a security section here, and we're still arguing
about it.

Certain issues noted above have to do with the interpretation of
identifiers. Constituency: Existing implementations do not interpret
identifiers as anything beyond their intrinsic existence as octet
strings. Larger: If we define any sort of interpretation of identifiers
then we are encouraging people to act along the lines of Sun's idiotic
``+ in rhosts.'' From a security standpoint this is reckless.

>    The information returned by this protocol is at most as trustworthy
>    as the host providing it OR the organization operating the host.

Technical: The word ``trustworthy'' has not been defined. Technical: The
concept of ``operating'' is not relevant to this protocol. Factual: With
at least one definition of ``trustworthy,'' this statement is incorrect.
Process: This statement is a model of non-consensus and should not
appear in the document. (The same comments apply to the remainder of the
paragraph.)

>    The Identity Protocol is not intended as an authorization or access
>    control protocol.

Constituency, process, factual, technical, larger: this statement is
*wrong*. Take it away.

>    The use of the information returned by this protocol for other than
>    auditing is strongly discouraged.

Constituency, process, factual, technical, larger: this statement is
*stupid*. Take it away.

> Specifically, using Identity
>    Protocol information to make access control decisions - either as
>    the primary method (i.e no other checks) or as an adjunct to other
>    methods may result in a weakening of normal host security.

Factual: This statement is so obviously incorrect that I can't believe
it's being said with a straight face. Process: This statement has been
objected to, repeatedly, and not justified.

>    An Ident server may reveal information about users, entities,
>    objects or processes which might normally be considered private.
>    An Ident server provides service which is a rough analog of the
>    CallerID (tm) services provided by some phone companies and many of
>    the same privacy considerations and arguments that apply to the
>    CallerID service apply to Ident.  If you wouldn't run a "finger"
>    server due to privacy considerations you may not want to run this
>    protocol.

Factual: The CallerID analogy isn't even close to correct. Larger: What
is wrong with including *just the last sentence*?

---Dan