configure Script to configure S/Ident
configure.ac Source file for configure
doc Protocol and extra docs (Directory)
-doc/RFC1413 The basic Ident protocol
-doc/TAP.doc The original TAP protocol
-doc/TAPvsIDENT A comparison of TAP and Ident
doc/draft-morgan-ident-ext-04.txt The S/Ident specification
-doc/why-encrypt.txt Why encrypt Ident replies?
-doc/why-ident.txt Why to use the Ident protocol
-doc/why-tap.txt Why to use the TAP protocol
include Shared headers (Directory)
include/sident.h The libsident interface
m4 Additional Autoconf macros (Directory)
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. St. Johns
-Request for Comments: 1413 US Department of Defense
-Obsoletes: 931 February 1993
-
-
- Identification Protocol
-
-Status of this Memo
-
- This RFC specifies an IAB standards track protocol for the Internet
- community, and requests discussion and suggestions for improvements.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
-1. INTRODUCTION
-
- The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident
- 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 string which identifies the owner of that connection on
- the server's system.
-
- The Identification Protocol was formerly called the Authentication
- Server Protocol. It has been renamed to better reflect its function.
- This document is a product of the TCP Client Identity Protocol
- Working Group of the Internet Engineering Task Force (IETF).
-
-2. 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 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 server should close the connection down after a configurable
- amount of time with no queries - a 60-180 second idle timeout is
- recommended. The client may close the connection down at any time;
- however to allow for network delays the client should wait at least
- 30 seconds (or longer) after a query before abandoning the query and
- closing the connection.
-
-
-
-
-
-
-
-St. Johns [Page 1]
-\f
-RFC 1413 Identification Protocol February 1993
-
-
-3. RESTRICTIONS
-
- Queries are permitted only for fully specified connections. The
- query contains the local/foreign port pair -- the local/foreign
- address pair used to fully specify the connection is taken from the
- local and foreign address of query connection. This means a user on
- address A may only query the server on address B about connections
- between A and B.
-
-4. QUERY/RESPONSE FORMAT
-
- The server accepts simple text query requests of the form:
-
- <port-on-server> , <port-on-client>
-
- where <port-on-server> is the TCP port (decimal) on the target (where
- the "ident" server is running) system, and <port-on-client> is the
- TCP port (decimal) on the source (client) system.
-
- N.B - If a client on host A wants to ask a server on host B about a
- connection specified locally (on the client's machine) as 23, 6191
- (an inbound TELNET connection), the client must actually ask about
- 6191, 23 - which is how the connection would be specified on host B.
-
- For example:
-
- 6191, 23
-
- The response is of the form
-
- <port-on-server> , <port-on-client> : <resp-type> : <add-info>
-
- where <port-on-server>,<port-on-client> are the same pair as the
- query, <resp-type> is a keyword identifying the type of response, and
- <add-info> is context dependent.
-
- The information returned is that associated with the fully specified
- TCP connection identified by <server-address>, <client-address>,
- <port-on-server>, <port-on-client>, where <server-address> and
- <client-address> are the local and foreign IP addresses of the
- querying connection -- i.e., the TCP connection to the Identification
- Protocol Server. (<port-on-server> and <port-on-client> are taken
- from the query.)
-
- For example:
-
- 6193, 23 : USERID : UNIX : stjohns
- 6195, 23 : ERROR : NO-USER
-
-
-
-St. Johns [Page 2]
-\f
-RFC 1413 Identification Protocol February 1993
-
-
-5. RESPONSE TYPES
-
-A response can be one of two types:
-
-USERID
-
- In this case, <add-info> is a string consisting of an
- operating system name (with an optional character set
- identifier), followed by ":", followed by an
- identification string.
-
- The character set (if present) is separated from the
- operating system name by ",". The character set
- identifier is used to indicate the character set of the
- identification string. The character set identifier,
- if omitted, defaults to "US-ASCII" (see below).
-
- Permitted operating system names and character set
- names are specified in RFC 1340, "Assigned Numbers" or
- its successors.
-
- In addition to those operating system and character set
- names specified in "Assigned Numbers" there is one
- special case operating system identifier - "OTHER".
-
- Unless "OTHER" is specified as the operating system
- type, the server is expected to return the "normal"
- user identification of the owner of this connection.
- "Normal" in this context may be taken to mean a string
- of characters which uniquely identifies the connection
- owner such as a user identifier assigned by the system
- administrator and used by such user as a mail
- identifier, or as the "user" part of a user/password
- pair used to gain access to system resources. When an
- operating system is specified (e.g., anything but
- "OTHER"), the user identifier is expected to be in a
- more or less immediately useful form - e.g., something
- that could be used as an argument to "finger" or as a
- mail address.
-
- "OTHER" indicates the identifier is an unformatted
- character string consisting of printable characters in
- the specified character set. "OTHER" should be
- specified if the user identifier does not meet the
- constraints of the previous paragraph. Sending an
- encrypted audit token, or returning other non-userid
- information about a user (such as the real name and
- phone number of a user from a UNIX passwd file) are
-
-
-
-St. Johns [Page 3]
-\f
-RFC 1413 Identification Protocol February 1993
-
-
- both examples of when "OTHER" should be used.
-
- Returned user identifiers are expected to be printable
- in the character set indicated.
-
- The identifier is an unformatted octet string - - all
- octets are permissible EXCEPT octal 000 (NUL), 012 (LF)
- and 015 (CR). N.B. - space characters (040) following the
- colon separator ARE part of the identifier string and
- may not be ignored. A response string is still
- terminated normally by a CR/LF. N.B. A string may be
- printable, but is not *necessarily* printable.
-
-ERROR
-
- For some reason the port owner could not be determined, <add-info>
- tells why. The following are the permitted values of <add-info> and
- their meanings:
-
- INVALID-PORT
-
- Either the local or foreign port was improperly
- specified. This should be returned if either or
- both of the port ids were out of range (TCP port
- numbers are from 1-65535), negative integers, reals or
- in any fashion not recognized as a non-negative
- integer.
-
- NO-USER
-
- The connection specified by the port pair is not
- currently in use or currently not owned by an
- identifiable entity.
-
- HIDDEN-USER
-
- The server was able to identify the user of this
- port, but the information was not returned at the
- request of the user.
-
- UNKNOWN-ERROR
-
- Can't determine connection owner; reason unknown.
- Any error not covered above should return this
- error code value. Optionally, this code MAY be
- returned in lieu of any other specific error code
- if, for example, the server desires to hide
- information implied by the return of that error
-
-
-
-St. Johns [Page 4]
-\f
-RFC 1413 Identification Protocol February 1993
-
-
- code, or for any other reason. If a server
- implements such a feature, it MUST be configurable
- and it MUST default to returning the proper error
- message.
-
- Other values may eventually be specified and defined in future
- revisions to this document. If an implementer has a need to specify
- a non-standard error code, that code must begin with "X".
-
- In addition, the server is allowed to drop the query connection
- without responding. Any premature close (i.e., one where the client
- does not receive the EOL, whether graceful or an abort should be
- considered to have the same meaning as "ERROR : UNKNOWN-ERROR".
-
-FORMAL SYNTAX
-
- <request> ::= <port-pair> <EOL>
-
- <port-pair> ::= <integer> "," <integer>
-
- <reply> ::= <reply-text> <EOL>
-
- <EOL> ::= "015 012" ; CR-LF End of Line Indicator
-
- <reply-text> ::= <error-reply> | <ident-reply>
-
- <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
-
- <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
- ":" <user-id>
-
- <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
- | "HIDDEN-USER" | <error-token>
-
- <opsys-field> ::= <opsys> [ "," <charset>]
-
- <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
- ; (See "Assigned Numbers")
-
- <charset> ::= "US-ASCII" | ...etc.
- ; (See "Assigned Numbers")
-
- <user-id> ::= <octet-string>
-
- <token> ::= 1*64<token-characters> ; 1-64 characters
-
- <error-token> ::= "X"1*63<token-characters>
- ; 2-64 chars beginning w/X
-
-
-
-St. Johns [Page 5]
-\f
-RFC 1413 Identification Protocol February 1993
-
-
- <integer> ::= 1*5<digit> ; 1-5 digits.
-
- <digit> ::= "0" | "1" ... "8" | "9" ; 0-9
-
- <token-characters> ::=
- <Any of these ASCII characters: a-z, A-Z,
- - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
- ; upper and lowercase a-z plus
- ; printables minus the colon ":"
- ; character.
-
- <octet-string> ::= 1*512<octet-characters>
-
- <octet-characters> ::=
- <any octet from 00 to 377 (octal) except for
- ASCII NUL (000), CR (015) and LF (012)>
-
-Notes on Syntax:
-
- 1) To promote interoperability among variant
- implementations, with respect to white space the above
- syntax is understood to embody the "be conservative in
- what you send and be liberal in what you accept"
- philosophy. Clients and servers should not generate
- unnecessary white space (space and tab characters) but
- should accept white space anywhere except within a
- token. In parsing responses, white space may occur
- anywhere, except within a token. Specifically, any
- amount of white space is permitted at the beginning or
- end of a line both for queries and responses. This
- does not apply for responses that contain a user ID
- because everything after the colon after the operating
- system type until the terminating CR/LF is taken as
- part of the user ID. The terminating CR/LF is NOT
- considered part of the user ID.
-
- 2) The above notwithstanding, servers should restrict the
- amount of inter-token white space they send to the
- smallest amount reasonable or useful. Clients should
- feel free to abort a connection if they receive 1000
- characters without receiving an <EOL>.
-
- 3) 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
-
-
-
-St. Johns [Page 6]
-\f
-RFC 1413 Identification Protocol February 1993
-
-
- user ID. Because of this limitation, a server MUST
- return the most significant portion of the user ID in
- the first 512 octets.
-
- 4) The character sets and character set identifiers should
- map directly to those defined in or referenced by RFC 1340,
- "Assigned Numbers" or its successors. Character set
- identifiers only apply to the user identification field
- - all other fields will be defined in and must be sent
- as US-ASCII.
-
- 5) 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.
-
- 6) The character set provides context for the client to
- print or store the returned user identification string.
- If the client does not recognize or implement the
- returned character set, it should handle the returned
- identification string as OCTET, but should in addition
- store or report the character set. An OCTET string
- should be printed, stored or handled in hex notation
- (0-9a-f) in addition to any other representation the
- client implements - this provides a standard
- representation among differing implementations.
-
-6. Security Considerations
-
- The information returned by this protocol is at most as trustworthy
- as the host providing it OR the organization operating the host. For
- example, a PC in an open lab has few if any controls on it to prevent
- a user from having this protocol return any identifier the user
- wants. Likewise, if the host has been compromised the information
- returned may be completely erroneous and misleading.
-
- The Identification Protocol 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.
-
- The use of the information returned by this protocol for other than
- auditing is strongly discouraged. Specifically, using Identification
- 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.
-
-
-
-
-St. Johns [Page 7]
-\f
-RFC 1413 Identification Protocol February 1993
-
-
- An Identification server may reveal information about users,
- entities, objects or processes which might normally be considered
- private. An Identification server provides service which is a rough
- analog of the CallerID services provided by some phone companies and
- many of the same privacy considerations and arguments that apply to
- the CallerID service apply to Identification. If you wouldn't run a
- "finger" server due to privacy considerations you may not want to run
- this protocol.
-
-7. ACKNOWLEDGEMENTS
-
- Acknowledgement is given to Dan Bernstein who is primarily
- responsible for renewing interest in this protocol and for pointing
- out some annoying errors in RFC 931.
-
-References
-
- [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January
- 1985.
-
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
-
-Author's Address
-
- Michael C. St. Johns
- DARPA/CSTO
- 3701 N. Fairfax Dr
- Arlington, VA 22203
-
- Phone: (703) 696-2271
- EMail: stjohns@DARPA.MIL
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-St. Johns [Page 8]
-\f
+++ /dev/null
-TAP-std working group D. Bernstein
-RFC NNNN IR
- June 1991, revised 17 August 1992
-
- TAP
-
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
-
-1. Introduction
-
- It is common for Internet hosts to associate relatively long-lived
- information to each TCP connection, often (but not always) including
- a ``username'' or ``owner name'' or some other information about the
- entity using the connection. TAP announces the information associated
- with a particular TCP connection to the host on the other end of the
- connection. TAP may be used on any host which associates relatively
- long-lived information to each connection.
-
-
-2. Overview
-
- This is a connection-based application which runs over TCP. The TAP
- server listens for TCP connections on port 113 (decimal). After a
- connection is established, the server reads one line of data which
- specifies the connection of interest. If that connection exists and
- is associated with system-dependent information, the server sends
- the information. Otherwise it sends an error line. After sending the
- information or error line, the server closes its connection. After
- reading the information or error line, the client closes the
- connection.
-
- The server will give information about TCP connections between the
- server's host and host H only to host H itself. The two hosts (i.e.,
- IP addresses) involved are not transmitted explicitly by the
- protocol; they are implicit in the connection made to the server.
-
-
-3. Request format
-
- The server accepts simple text query requests of the form
-
- <localport> , <foreignport>
-
-
-
-TAP-std working group [Page 1]
-\f
-RFC NNNN TAP August 1992
-
-
- where <localport> is the TCP port on the server's host and
- <foreignport> is the TCP port on the client's host. All numbers are
- expressed in decimal without a sign, and all text is ASCII. If the
- request is not in this format, the server may immediately drop the
- connection.
-
- For example, say rose is connected to the standard TELNET port on
- host tulip, through TCP ports 6191 on rose and 23 on tulip. (Note
- that rose and tulip are simply names used in this document to
- identify two IP-connected machines. They are not fully qualified
- domain names.) tulip connects to the TAP server at port 113 on rose.
- It sends this line:
-
- 6191 , 23
-
- Here 6191 is the TCP port on the TAP server's host (rose) and 23 is
- the TCP port on the TAP client's host (tulip). This uniquely
- specifies the given TELNET connection.
-
- The precise format of the request line is as follows: <localport>,
- followed by any amount of whitespace, followed by a comma and any
- amount of whitespace, followed by <foreignport>, followed by carriage
- return and line feed. Whitespace means space or tab; "any amount"
- means zero or more, though a client should not print excessively many
- spaces. The server should read until the line feed and respond
- immediately. The client should not send anything after the line feed,
- though future revisions of this specification may permit additional
- data. The client should not add initial zeros to its decimal numbers,
- but the server must accept such numbers. Future revisions of this
- standard may assign additional meaning to decimals with a leading 0.
-
-
-4. Response format
-
- The server sends a response line in one of these two formats:
-
- <localport> , <foreignport> : USERID : <systemtype> : <conn-info>
- or
- <localport> , <foreignport> : ERROR : <errortype>
-
- Here <localport> and <foreignport> are the same numbers as in the
- query. (If the client uses initial zeros, the server may do so as
- well, but otherwise it should not use initial zeros.) <systemtype> is
- an operating system name for the server's host as described in
- Assigned Numbers, RFC 1060 or its successors. <conn-info> is
- system-dependent information associated to the connection.
- <errortype> is text describing an error as outlined below.
-
-
-
-
-TAP-std working group [Page 2]
-\f
-RFC NNNN TAP August 1992
-
-
- <systemtype> may also be OTHER to specify any other operating system
- not yet listed in Assigned Numbers. Even if the server's system is
- listed in Assigned Numbers, the server may use OTHER for any reason,
- including operating system type privacy. Future revisions of this
- document may permit further values of <systemtype>.
-
- <conn-info> is in some format defined by the system. This document
- does not define the format or meaning of <conn-info>. Often
- <conn-info> is in the same format as a system-dependent mailbox name,
- which is typically in the same format as a system-dependent username,
- but these equivalences are not required. <conn-info> could be
- encrypted with a secret key; it could carry something other than
- information about the entity using the connection. For the purposes
- of this protocol, <conn-info> is an uninterpreted octet string. See
- section 5 for further details.
-
- For example, some possible responses to the 6191 , 23 query might be
- the following:
-
- 6191 , 23 : USERID : UNIX : joe
- 6191 , 23 : USERID : MULTICS : StJohns.DODCSC.a
- 6191 , 23 : USERID : OTHER : StJohns.DODCSC.a
- 6191 , 23 : USERID : TAC : MCSJ-MITMUL
- 6191 , 23 : USERID : UNIX : a6X#-Yp,3147,2910
- 6191,23 :USERID:OTHER:wewishyouamerrychristmasandahappynewyear
- 6191 , 23 : ERROR : NO-USER
-
- An ERROR line means that the server could not determine the
- information associated to the TCP connection. <errortype> tells why.
- <errortype> may be any of the following:
-
- INVALID-PORT
-
- <localport> or <foreignport> was improperly specified---out of
- the range 0 to 65535, for example---or the request was
- otherwise non-standard. In this case the server may drop the
- connection without replying.
-
- NO-USER
-
- The connection specified by the port pair is not currently in
- use.
-
- HIDDEN-USER
-
- The connection is in use, but the information associated to it
- is explicitly hidden.
-
-
-
-
-TAP-std working group [Page 3]
-\f
-RFC NNNN TAP August 1992
-
-
- UNKNOWN-ERROR
-
- Cannot determine the information associated to the connection,
- for an unknown reason. The server may give this <errortype> in
- any case and for any reason, including privacy, whether or not
- another <errortype> applies.
-
- Future revisions of this document may allow other <errortype> values.
- The server may also report an <errortype> beginning with the letter
- X; all such <errortype>s are reserved for experimental or
- non-standard use.
-
- The precise format of the response line is as follows: <localport>,
- followed by any amount of whitespace, followed by a comma and any
- amount of whitespace, followed by <foreignport>, followed by any
- amount of whitespace, followed by a colon and any amount of
- whitespace. In the USERID case, it is then followed by USERID and any
- amount of whitespace, a colon and any amount of whitespace,
- <systemtype> and any amount of whitespace, a colon and any amount of
- whitespace, one or more characters giving <conn-info>, and finally
- carriage return and line feed. In the ERROR case, it is followed by
- ERROR and any amount of whitespace, a colon and any amount of
- whitespace, one or more characters giving <errortype>, and finally
- carriage return and line feed.
-
- Note that this format is ambiguous if <systemtype> contains colons or
- whitespace. Assigned Numbers does not currently list any <systemtype>
- with colons or whitespace, but if it ever does, the TAP server must
- use OTHER for the <systemtype> on such a machine. The server should
- also not use a <systemtype> containing carriage return or line feed.
-
- Similarly, if <conn-info> or <errortype> begins with whitespace or
- contains carriage return-line feed, the response line format is
- ambiguous. The server must never use <errortype> containing
- whitespace, carriage return, or line feed, and future revisions of
- this RFC will never provide for such an <errortype>. The server
- cannot send <conn-info> beginning with whitespace or containing
- carriage return-line feed; it should not send <conn-info> containing
- whitespace, carriage return, or line feed. ERROR : UNKNOWN-ERROR is
- preferable.
-
- Finally, <systemtype>, <conn-info>, and <errortype> cannot be empty
- strings, and cannot contain ASCII NUL (character 0).
-
-
-
-
-
-
-
-
-TAP-std working group [Page 4]
-\f
-RFC NNNN TAP August 1992
-
-
- Later revisions of this protocol specification may further restrict
- the octets which may be transmitted. In light of this, servers
- should, if possible, limit <conn-info> to at most ASCII codes 33
- through 126. Clients should, however, be prepared to handle all
- octets.
-
- Note that there is no limit on line lengths: in particular, on the
- length of <conn-info>. The client may drop the connection at any
- time to avoid overflow. The server should, if possible, place the
- most useful information within the first 512 characters of
- <conn-info>.
-
-
-5. Applications and security
-
- A TAP server may place any information it wants into its responses to
- a TAP query. This protocol does not assign any meaning to <conn-info>
- beyond its intrinsic existence as an octet string. So, in most cases,
- a TAP client will simply record the bytes of <conn-info> in some
- manner for possible interpretation later by the server host. This is
- primarily useful as a form of remote auditing: if the client host
- judges that the TCP connection represents an accidental or malicious
- malfunction on the part of the server host, then <conn-info> may
- permit the server host's owner to track down the exact source of the
- malfunction. So the information returned by TAP in this case is of
- primary benefit to the host generating that information.
-
- The TAP client can do nothing more than this unless it has an
- external reason to assign meaning to <conn-info> received from that
- particular host. Beware that assigning <conn-info> an unjustified
- meaning will in general lead to security holes. Do not use TAP for
- access control without documenting the external knowledge you have
- which ensures that your use of <conn-info> for access control is
- justified. An attacker could subvert the security of a server host or
- of TCP/IP; and any host could send any information it wants along a
- TAP connection. Two dangers of weak methods of access control are
- that they may permit access which should be denied, and that they may
- deny access which should be permitted.
-
-
-6. Notes
-
- This section is not part of the TAP description proper. It provides
- historical information and pointers to further information.
-
-
-
-
-
-
-
-TAP-std working group [Page 5]
-\f
-RFC NNNN TAP August 1992
-
-
- TAP is derived from the protocol defined in RFC 931 by Mike StJohns.
- It was first implemented by this author in early 1990, then again in
- February 1991, and distributed via the USENET network under the name
- authd. Later in 1991 two more independent interoperable
- implementations were distributed through the Internet. In 1992
- another independent interoperable implementation was distributed.
- TAP, as defined in this document, is the same as the authd protocol,
- which has not changed since its first implementation in early 1990.
-
- This document is a cooperative effort of the TAP-std working group.
- TAP-std is an ad-hoc group with the following charter: ``This group
- is chartered to document the TAP protocol as used on TCP port 113
- around the Internet. Its first goal is to publish as quickly as
- possible an accurate, well-understood, complete TAP specification
- which reflects the consensus of the community. Afterwards it will
- keep track of TAP usage and produce further documents as necessary.
- This group will not publish as a standard any TAP variation which has
- not been tested on the Internet, though it will make all reasonable
- allowances for future extensions.''
-
- At the time of publication of this document, you can join the
- tap-std mailing list by sending a subscription request to
- tap-std-request@kramden.acf.nyu.edu, or by connecting to TCP port
- 39311 on 128.122.142.2 and typing your username. There is also a
- mailing list for people who want to use TAP to solve problems. To
- join, send mail to rfc931-users-request@kramden.acf.nyu.edu.
-
- The author would like to thank Chris Davis, Peter Eriksson, and Dave
- Borman for their helpful suggestions used in creating the TAP-std
- base document. Thanks go to all the participants in the TAP-std
- working group for their suggestions, comments, and criticism.
-
-
-Security Considerations
-
- Security issues are discussed in section 5.
-
-
-Author's Address
-
- Daniel J. Bernstein
- 5 Brewster Lane
- Bellport, NY 11713
-
- Email: brnstnd@nyu.edu
-
-
-
-
-
-
-TAP-std working group [Page 6]
-\f
-
+++ /dev/null
-TAP is an alternative protocol specification for a successor to RFC931
-that Pidentd is compatible with. TAP is a more "clean" protocol and
-doesn't include as many new "features" as IDENT does, but the basic
-functionality is more or less the same. If you don't use the extra
-features of the IDENT protocol (which has to be explicitly enabled in
-Pidentd), then it should be compatible.
-
-/Peter Eriksson <pen@lysator.liu.se>
+++ /dev/null
-``Why encrypt ident/TAP replies ?''
-Damien Doligez
-1994.02.22
-
-
-This text is a companion to ``Why TAP?'' by Daniel J. Bernstein.
-I will explain the reasons why your ident server should encrypt its
-replies before sending them.
-
-This is written from the point of view of a system administrator
-who wants to install an ident server. The local machine is the machine
-running the ident server, and the remote machine any machine on the
-Internet that keeps a log of ident replies from the local machine.
-
-This starts as a structured document and ends in random comments
-and implementation remarks.
-
-
-Problems with ident.
-
-The ident protocol, as implemented by pidentd return a cleartext
-identification of the user. This approach has the following problems:
-
-1. The remote administrator is tempted to interpret the ident logs
- without asking the local administrator. Everybody is supposed
- to know that ident replies are only meaningful to the local
- administrator, but in the real world, the remote administrator
- will forget that, especially if the ident data is mixed with
- data from his own machines (which is almost always the case).
-
-2. Any user on the remote system can call the local ident server
- and collect login names for guessing passwords, and usage
- patterns.
-
-3. The remote administrator might be malevolent and lie to you about
- the contents of his ident logs.
-
-4. Some network attacks on the ident protocol have been described
- on Usenet (comp.security.*). They involve intercepting ident
- requests and replying with bogus information, from another host
- on the network, with forged IP packets.
-
-
-The crypto solution.
-
-Dan Bernstein writes:
->An easy solution to [problems 2 and 3] is to encrypt your usernames
->(along with a timestamp, perhaps, though this defeats the selective
->blocking application outlined in the next section) in a secret key.
-
-This also solves problem 1, but it is not a complete solution to
-problems 3 and 4. If you only encrypt the date and user ID, you
-give to the remote administrator a piece of data that proves
-that the user had some active connection at that date. The remote
-administrator could still lie about what machines were involved
-and what ports the connection used (was it finger or telnet ?)
-
-And a network hacker could easily acquire such a piece of data
-(e.g. via network sniffing) and use it to spoof your ident server.
-
-And if you only encrypt the user ID (or user name), the situation
-is even worse. It is quite easy in this case to guess (by simple
-traffic analysis) which user is associated with a given encrypted
-user ID, and then encryption becomes useless.
-
-
-My solution is to encrypt a packet of data that contains:
-- The date
-- The user ID
-- Both machine addresses
-- Both port numbers.
-
-Then the piece of data becomes a proof that that user had an active
-connection at that date, between these machines and with these port
-numbers.
-
-Problem 1 is solved by forcing the remote administrator to ask you
-to decrypt the data.
-
-Problem 2 is solved by making the data unuseable except by yourself.
-
-Problem 3 and 4 are solved by making the piece of data self-contained
-and unforgeable.
-
-The biggest problem with this encryption is that the selective blocking
-described by Dan Bernstein becomes impossible. An other aspect of
-this problem is that simple measures to counter SMTP forgery (echoing
-his user ID back to the SMTP cracker) is also impossible. But
-identification of the hacker is still possible, with the help of the
-local administrator.
-
-
-Implementation.
-
-The packet of data is a 24-byte record with the following layout:
-
-block bytes contents
- 1 4 checksum
- 2 random
- 2 user ID
- 2 4 date
- 4 local IP address
- 3 4 remote IP address
- 2 local port number
- 2 remote port number
-
-The plaintext is divided in three 8-byte blocks p0, p1, p2 and encrypted
-into three 8-byte blocks of cyphertext c0, c1, c2 as follows:
-
- c0 = E (p0)
- c1 = E (p1 ^ c0)
- c2 = E (p2 ^ c1)
-
-Where E is DES with a secret key. The secret key is stored in a file
-only readable by root on the local machine.
-
-This is essentially CBC mode, without an initialization vector.
-The block chaining is used to prevent replacement of one block from
-another packet. Replacing c0 will garble the decrypted p1;
-replacing c1 will garble the decrypted p1 and p2; replacing c2 will
-garble the decrypted p2; replacing c0 and c1 will garble p2;
-replacing c1 and c2 will garble p1; and replacing c0 and c2 will garble
-p1 and p2. The checksum is here to ensure that the right key was used
-for decrypting and that the packet was not tampered with.
-
-The decryption program is a filter that will read stdin and copy
-it to stdout, replacing any encrypted block with the corresponding
-decrypted information. The decryption program uses the same key file
-as the encryption. The file may contain several keys. The encryption
-will use only the first one, but the decryption program will try each
-key in turn. This way, you just have to add a new key at the beginning
-of the file whenever you want to change the key (you should change your key
-often enough, depending on the level of confidentiality that you want).
-
-Be aware that a brute-force plaintext attack is very easy to set up
-against this system, and that finding the key for one packet will
-unlock all other packets encrypted with the same key. Changing
-the key often will force the attacker to redo the brute-force attack
-again and again.
-
-A key is a line of text (maximum 1023 characters) which is hashed into
-a 56-bit DES key. It might be a good idea to include the date in
-each line of the key file. The decryption program will only try
-the first 1024 keys from the key file. Be aware that having many keys
-in this file will slow down the decryption considerably. If this
-becomes a real problem, I could implement a simple hashing scheme to
-solve it.
-
-There are a number of holes in Unix that allow users to read (parts of)
-any file readable by group kmem. (The "ps" command is one such hole.)
-My advice is to make the key file only readable by root, and make pidentd
-run as root. The probability of a hole in pidentd itself is pretty small.
-
-WARNING: I am not a specialist in cryptology. It may well be the case
-that the absence of an IV in the CBC encryption weakens the encryption
-considerably. I do not guarantee any level of confidentiality whatsoever.
-Go ask sci.crypt if you want some serious answers.
-
-The DES implementation and hash function used are from the libdes
-library, written by Eric Young (eay@psych.psy.uq.oz.au) and available
-(among other sites) from ftp.funet.fi.
-
-The code is not too well integrated with the rest of pidentd, and
-somebody should change the man page to document the "-C" option
-for encryption and the format of the key file.
-The code is endian-independent, but I'm not sure it would work on
-a 64-bit machine.
-
-Maybe I should add an option to the decryption program for specifying
-an alternate key file.
+++ /dev/null
-Well... Go read "why-tap.txt". More or less the same arguments
-apply for the IDENT protocol. :-)
-
-I'm not sure the "rfc931-users" mailing list is alive anymore though.
-I've created a new mailing list "ident-users@lysator.liu.se" that you
-may wish to join instead. Send email to "ident-users-request@lysator.liu.se"
-to join/leave that list.
-
-/Peter Eriksson <pen@lysator.liu.se>, 3 Nov 1993
-
-
+++ /dev/null
-``Why TAP?'' A White Paper
-Daniel J. Bernstein
-draft 3
-920820
-
-
-1. Introduction
-
-Hundreds of hosts around the Internet run TAP servers. If there's a TCP
-connection from one of those hosts, say host H, to host Z, then host Z
-can use TAP to find out certain information from H about the connection.
-That's all the protocol does.
-
-What's the information? That's up to H. A typical TAP server runs on a
-multi-user host and announces the username on that host's side of the
-connection. Some hosts use the protocol to announce other kinds of
-information. And a few hosts run a server but don't announce any useful
-information at all.
-
-The purpose of this white paper is to show the reader two ways in which
-TAP is useful (and used!) in today's Internet: remote auditing and
-selective blocking. These applications work even though _you can't tell
-the difference_ between the different types of TAP servers mentioned
-above on a network of hosts you don't know---between a server which
-tries to be honest and a server which lies through its teeth.
-
-It is occasionally stated that TAP is useless on the Internet as a
-whole, or that it is useful in stopping attacks only because attackers
-(supposedly) don't know about it, or that it provides no ``real''
-security at all. These criticisms are usually justified by repetition
-rather than by a proper security analysis. At their heart they are based
-on the assumption that a host running a TAP server is trying to benefit
-the rest of the community. In fact the benefits of a TAP server _accrue
-to the host running the server_. This theme will show up again in the
-examples below.
-
-
-2. Remote auditing
-
-Say you manage a large computer, often supporting dozens of simultaneous
-users. One day you are informed of a series of network attacks emanating
-from your machine, by a very serious security officer who sounds ready
-to call the Secret Service. What do you do?
-
-If your machine has extraordinarily powerful logging facilities, perhaps
-you can figure out who was using the network at a given time. TAP
-provides a simpler solution: _remote auditing_. If you run a TAP server,
-then remote sites can find out which of your users was responsible for
-any given TCP connection (unless, of course, your machine has been
-compromised, in which case you have bigger problems). A remote site is
-probably better equipped to decide whether a connection from your
-machine is or is not a security problem, and can decide for itself what
-to do with the TAP data.
-
-You may not want to give away free information about your users. You may
-also want to verify, without having to keep your own logs, that the guy
-on the other end is telling the truth about what he heard from your TAP
-server. An easy solution to both problems is to encrypt your usernames
-(along with a timestamp, perhaps, though this defeats the selective
-blocking application outlined in the next section) in a secret key.
-
-Of course the scenario outlined above is a worst case. Less serious
-cases in which remote auditing is useful include mail forgery via SMTP
-and news forgery via NNTP. Or perhaps your host is the TCP Toaster, and
-you want an easy way to track down malfunctions. In all of these cases
-TAP at least removes the minor nuisances which constitute 99% of all
-network problems. In particular, it completely stops the problem of
-above-TCP mail forgery: anyone can send an anonymous message (through
-the post office if all else fails!), but, with TAP, normal users on your
-machine can't send messages which look like they came from other users.
-
-Notice that the benefit of running a TAP server comes right back to you.
-Certainly the security officer on the other end can't tell whether your
-TAP server is providing useful information---but if you are running a
-valid TAP server then you can assign blame properly. If you run a TAP
-server which provides useless information then you don't get this
-benefit.
-
-
-3. Selective blocking
-
-Now say you're that serious security officer, and you see someone
-attacking your machine. If your data is at stake then your first
-instinct may be to cut off service to the remote host while you track
-down the proper administrator. But what if you are providing valuable
-services to that host at the same time? Or, less dramatically, what if
-you want to keep an anonymous ftp archive as open as possible but find
-that someone is abusing your FTP server?
-
-You could cut off all access from any host until the problem is fixed.
-You could simply cut off service to the remote host and watch to make
-sure that the attacker doesn't start using another host. Or---if the
-remote host runs TAP---you can cut off the one userid causing trouble,
-and watch to make sure that other identifiers don't start attacking.
-This is _selective blocking_. The more selectivity your software
-provides, the more options you have.
-
-Notice that, once again, the benefit of a TAP server comes back to the
-host running the server. If the guy on the other end is running an
-honest TAP server, he's giving you the option of being nice to him---of
-keeping service open to most of his users even if one user is attacking.
-If he runs a useless TAP server then he doesn't get this benefit.
-
-
-4. Pointers to further information
-
-Everything mentioned here has been implemented. A recent BSD TAP server
-implementation, along with support for sendmail to catch forgeries, is
-available from ftp.lysator.liu.se:pub/tap. You can implement selective
-blocking with log_tcp, available from ftp.win.tue.nl. You can add TAP
-to BSD talkd from gatekeeper.dec.com:pub/bsd-sources/src/network/talk.tar.Z
-with wuarchive.wustl.edu:usenet/alt.sources/articles/2687.Z. nntpd
-support is in wuarchive.wustl.edu:usenet/alt.sources/articles/2746.Z.
-ftpd support is in wuarchive.wustl.edu:packages/ftpd.wuarchive.shar. For
-IRC support see cs.bu.edu:pub/irc/servers.
-
-There's a mailing list, rfc931-users, for people who want to use RFC 931
-(and its variants, including TAP) to solve problems. To join, contact
-rfc931-users-request@kramden.acf.nyu.edu. rfc931-users maintains a list
-of known server hosts, as well as current information on implementations
-and other useful items.
-
-In June 1992, approximately one out of every 7000 packets across the
-NSFNET T1 backbone was for port 113, the TAP port; only thirty named
-ports had higher packet counts. This information comes from
-nic.merit.edu:nsfnet/statistics/1992/t1-9206.ports.
-
projects / kerberos / sident.git / commitdiff