v29i126: pidentd-2.7 - Portable Ident Daemon, V2.7, Part03/09

[Peter Eriksson]

Submitted-By: pe...@ifm.liu.se (Peter Eriksson)
Posting-Number: Volume 29, Issue 126
Archive-Name: pidentd-2.7/part03

#!/bin/sh
# This is part 03 of a multipart archive.
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
if test "$gettext_dir" = FAILED && test -f $dir/gettext \
&& ($dir/gettext --version >/dev/null 2>&1)
then
set `$dir/gettext --version 2>&1`
if test "$3" = GNU
then
gettext_dir=$dir
fi
fi
if test "$locale_dir" = FAILED && test -f $dir/shar \
&& ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
then
locale_dir=`$dir/shar --print-text-domain-dir`
fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
echo=echo
else
TEXTDOMAINDIR=$locale_dir
export TEXTDOMAINDIR
TEXTDOMAIN=sharutils
export TEXTDOMAIN
echo="$gettext_dir/gettext -s"
fi
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
$echo 'WARNING: not restoring timestamps. Consider getting and'
$echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
if mkdir _sh08724; then
$echo 'x -' 'creating lock directory'
else
$echo 'failed to create lock directory'
exit 1
fi
# ============= pidentd-2.7/doc/TAP.doc ==============
if test ! -d 'pidentd-2.7'; then
$echo 'x -' 'creating directory' 'pidentd-2.7'
mkdir 'pidentd-2.7'
fi
if test ! -d 'pidentd-2.7/doc'; then
$echo 'x -' 'creating directory' 'pidentd-2.7/doc'
mkdir 'pidentd-2.7/doc'
fi
if test -f 'pidentd-2.7/doc/TAP.doc' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/doc/TAP.doc' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/doc/TAP.doc' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/doc/TAP.doc' &&
TAP-std working group D. Bernstein
RFC NNNN IR
X June 1991, revised 17 August 1992
X
X TAP
X
X
Status of this Memo
X
X This memo provides information for the Internet community. It does
X not specify an Internet standard. Distribution of this memo is
X unlimited.
X
X
1. Introduction
X
X It is common for Internet hosts to associate relatively long-lived
X information to each TCP connection, often (but not always) including
X a ``username'' or ``owner name'' or some other information about the
X entity using the connection. TAP announces the information associated
X with a particular TCP connection to the host on the other end of the
X connection. TAP may be used on any host which associates relatively
X long-lived information to each connection.
X
X
2. Overview
X
X This is a connection-based application which runs over TCP. The TAP
X server listens for TCP connections on port 113 (decimal). After a
X connection is established, the server reads one line of data which
X specifies the connection of interest. If that connection exists and
X is associated with system-dependent information, the server sends
X the information. Otherwise it sends an error line. After sending the
X information or error line, the server closes its connection. After
X reading the information or error line, the client closes the
X connection.
X
X The server will give information about TCP connections between the
X server's host and host H only to host H itself. The two hosts (i.e.,
X IP addresses) involved are not transmitted explicitly by the
X protocol; they are implicit in the connection made to the server.
X
X
3. Request format
X
X The server accepts simple text query requests of the form
X
X <localport> , <foreignport>
X
X
X
TAP-std working group [Page 1]
X
RFC NNNN TAP August 1992
X
X
X where <localport> is the TCP port on the server's host and
X <foreignport> is the TCP port on the client's host. All numbers are
X expressed in decimal without a sign, and all text is ASCII. If the
X request is not in this format, the server may immediately drop the
X connection.
X
X For example, say rose is connected to the standard TELNET port on
X host tulip, through TCP ports 6191 on rose and 23 on tulip. (Note
X that rose and tulip are simply names used in this document to
X identify two IP-connected machines. They are not fully qualified
X domain names.) tulip connects to the TAP server at port 113 on rose.
X It sends this line:
X
X 6191 , 23
X
X Here 6191 is the TCP port on the TAP server's host (rose) and 23 is
X the TCP port on the TAP client's host (tulip). This uniquely
X specifies the given TELNET connection.
X
X The precise format of the request line is as follows: <localport>,
X followed by any amount of whitespace, followed by a comma and any
X amount of whitespace, followed by <foreignport>, followed by carriage
X return and line feed. Whitespace means space or tab; "any amount"
X means zero or more, though a client should not print excessively many
X spaces. The server should read until the line feed and respond
X immediately. The client should not send anything after the line feed,
X though future revisions of this specification may permit additional
X data. The client should not add initial zeros to its decimal numbers,
X but the server must accept such numbers. Future revisions of this
X standard may assign additional meaning to decimals with a leading 0.
X
X
4. Response format
X
X The server sends a response line in one of these two formats:
X
X <localport> , <foreignport> : USERID : <systemtype> : <conn-info>
X or
X <localport> , <foreignport> : ERROR : <errortype>
X
X Here <localport> and <foreignport> are the same numbers as in the
X query. (If the client uses initial zeros, the server may do so as
X well, but otherwise it should not use initial zeros.) <systemtype> is
X an operating system name for the server's host as described in
X Assigned Numbers, RFC 1060 or its successors. <conn-info> is
X system-dependent information associated to the connection.
X <errortype> is text describing an error as outlined below.
X
X
X
X
TAP-std working group [Page 2]
X
RFC NNNN TAP August 1992
X
X
X <systemtype> may also be OTHER to specify any other operating system
X not yet listed in Assigned Numbers. Even if the server's system is
X listed in Assigned Numbers, the server may use OTHER for any reason,
X including operating system type privacy. Future revisions of this
X document may permit further values of <systemtype>.
X
X <conn-info> is in some format defined by the system. This document
X does not define the format or meaning of <conn-info>. Often
X <conn-info> is in the same format as a system-dependent mailbox name,
X which is typically in the same format as a system-dependent username,
X but these equivalences are not required. <conn-info> could be
X encrypted with a secret key; it could carry something other than
X information about the entity using the connection. For the purposes
X of this protocol, <conn-info> is an uninterpreted octet string. See
X section 5 for further details.
X
X For example, some possible responses to the 6191 , 23 query might be
X the following:
X
X 6191 , 23 : USERID : UNIX : joe
X 6191 , 23 : USERID : MULTICS : StJohns.DODCSC.a
X 6191 , 23 : USERID : OTHER : StJohns.DODCSC.a
X 6191 , 23 : USERID : TAC : MCSJ-MITMUL
X 6191 , 23 : USERID : UNIX : a6X#-Yp,3147,2910
X 6191,23 :USERID:OTHER:wewishyouamerrychristmasandahappynewyear
X 6191 , 23 : ERROR : NO-USER
X
X An ERROR line means that the server could not determine the
X information associated to the TCP connection. <errortype> tells why.
X <errortype> may be any of the following:
X
X INVALID-PORT
X
X <localport> or <foreignport> was improperly specified---out of
X the range 0 to 65535, for example---or the request was
X otherwise non-standard. In this case the server may drop the
X connection without replying.
X
X NO-USER
X
X The connection specified by the port pair is not currently in
X use.
X
X HIDDEN-USER
X
X The connection is in use, but the information associated to it
X is explicitly hidden.
X
X
X
X
TAP-std working group [Page 3]
X
RFC NNNN TAP August 1992
X
X
X UNKNOWN-ERROR
X
X Cannot determine the information associated to the connection,
X for an unknown reason. The server may give this <errortype> in
X any case and for any reason, including privacy, whether or not
X another <errortype> applies.
X
X Future revisions of this document may allow other <errortype> values.
X The server may also report an <errortype> beginning with the letter
X X; all such <errortype>s are reserved for experimental or
X non-standard use.
X
X The precise format of the response line is as follows: <localport>,
X followed by any amount of whitespace, followed by a comma and any
X amount of whitespace, followed by <foreignport>, followed by any
X amount of whitespace, followed by a colon and any amount of
X whitespace. In the USERID case, it is then followed by USERID and any
X amount of whitespace, a colon and any amount of whitespace,
X <systemtype> and any amount of whitespace, a colon and any amount of
X whitespace, one or more characters giving <conn-info>, and finally
X carriage return and line feed. In the ERROR case, it is followed by
X ERROR and any amount of whitespace, a colon and any amount of
X whitespace, one or more characters giving <errortype>, and finally
X carriage return and line feed.
X
X Note that this format is ambiguous if <systemtype> contains colons or
X whitespace. Assigned Numbers does not currently list any <systemtype>
X with colons or whitespace, but if it ever does, the TAP server must
X use OTHER for the <systemtype> on such a machine. The server should
X also not use a <systemtype> containing carriage return or line feed.
X
X Similarly, if <conn-info> or <errortype> begins with whitespace or
X contains carriage return-line feed, the response line format is
X ambiguous. The server must never use <errortype> containing
X whitespace, carriage return, or line feed, and future revisions of
X this RFC will never provide for such an <errortype>. The server
X cannot send <conn-info> beginning with whitespace or containing
X carriage return-line feed; it should not send <conn-info> containing
X whitespace, carriage return, or line feed. ERROR : UNKNOWN-ERROR is
X preferable.
X
X Finally, <systemtype>, <conn-info>, and <errortype> cannot be empty
X strings, and cannot contain ASCII NUL (character 0).
X
X
X
X
X
X
X
X
TAP-std working group [Page 4]
X
RFC NNNN TAP August 1992
X
X
X Later revisions of this protocol specification may further restrict
X the octets which may be transmitted. In light of this, servers
X should, if possible, limit <conn-info> to at most ASCII codes 33
X through 126. Clients should, however, be prepared to handle all
X octets.
X
X Note that there is no limit on line lengths: in particular, on the
X length of <conn-info>. The client may drop the connection at any
X time to avoid overflow. The server should, if possible, place the
X most useful information within the first 512 characters of
X <conn-info>.
X
X
5. Applications and security
X
X A TAP server may place any information it wants into its responses to
X a TAP query. This protocol does not assign any meaning to <conn-info>
X beyond its intrinsic existence as an octet string. So, in most cases,
X a TAP client will simply record the bytes of <conn-info> in some
X manner for possible interpretation later by the server host. This is
X primarily useful as a form of remote auditing: if the client host
X judges that the TCP connection represents an accidental or malicious
X malfunction on the part of the server host, then <conn-info> may
X permit the server host's owner to track down the exact source of the
X malfunction. So the information returned by TAP in this case is of
X primary benefit to the host generating that information.
X
X The TAP client can do nothing more than this unless it has an
X external reason to assign meaning to <conn-info> received from that
X particular host. Beware that assigning <conn-info> an unjustified
X meaning will in general lead to security holes. Do not use TAP for
X access control without documenting the external knowledge you have
X which ensures that your use of <conn-info> for access control is
X justified. An attacker could subvert the security of a server host or
X of TCP/IP; and any host could send any information it wants along a
X TAP connection. Two dangers of weak methods of access control are
X that they may permit access which should be denied, and that they may
X deny access which should be permitted.
X
X
6. Notes
X
X This section is not part of the TAP description proper. It provides
X historical information and pointers to further information.
X
X
X
X
X
X
X
TAP-std working group [Page 5]
X
RFC NNNN TAP August 1992
X
X
X TAP is derived from the protocol defined in RFC 931 by Mike StJohns.
X It was first implemented by this author in early 1990, then again in
X February 1991, and distributed via the USENET network under the name
X authd. Later in 1991 two more independent interoperable
X implementations were distributed through the Internet. In 1992
X another independent interoperable implementation was distributed.
X TAP, as defined in this document, is the same as the authd protocol,
X which has not changed since its first implementation in early 1990.
X
X This document is a cooperative effort of the TAP-std working group.
X TAP-std is an ad-hoc group with the following charter: ``This group
X is chartered to document the TAP protocol as used on TCP port 113
X around the Internet. Its first goal is to publish as quickly as
X possible an accurate, well-understood, complete TAP specification
X which reflects the consensus of the community. Afterwards it will
X keep track of TAP usage and produce further documents as necessary.
X This group will not publish as a standard any TAP variation which has
X not been tested on the Internet, though it will make all reasonable
X allowances for future extensions.''
X
X At the time of publication of this document, you can join the
X tap-std mailing list by sending a subscription request to
X tap-std...@kramden.acf.nyu.edu, or by connecting to TCP port
X 39311 on 128.122.142.2 and typing your username. There is also a
X mailing list for people who want to use TAP to solve problems. To
X join, send mail to rfc931-use...@kramden.acf.nyu.edu.
X
X The author would like to thank Chris Davis, Peter Eriksson, and Dave
X Borman for their helpful suggestions used in creating the TAP-std
X base document. Thanks go to all the participants in the TAP-std
X working group for their suggestions, comments, and criticism.
X
X
Security Considerations
X
X Security issues are discussed in section 5.
X
X
Author's Address
X
X Daniel J. Bernstein
X 5 Brewster Lane
X Bellport, NY 11713
X
X Email: brn...@nyu.edu
X
X
X
X
X
X
TAP-std working group [Page 6]
X
X
SHAR_EOF
$shar_touch -am 0906145392 'pidentd-2.7/doc/TAP.doc' &&
chmod 0644 'pidentd-2.7/doc/TAP.doc' ||
$echo 'restore of' 'pidentd-2.7/doc/TAP.doc' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/doc/TAP.doc:' 'MD5 check failed'
2771ac0324bcae345feec6bf86c1f2a9 pidentd-2.7/doc/TAP.doc
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/doc/TAP.doc'`"
test 13719 -eq "$shar_count" ||
$echo 'pidentd-2.7/doc/TAP.doc:' 'original size' '13719,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/doc/TAPvsIDENT ==============
if test -f 'pidentd-2.7/doc/TAPvsIDENT' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/doc/TAPvsIDENT' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/doc/TAPvsIDENT' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/doc/TAPvsIDENT' &&
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.
X
/Peter Eriksson <p...@lysator.liu.se>
SHAR_EOF
$shar_touch -am 0819132192 'pidentd-2.7/doc/TAPvsIDENT' &&
chmod 0644 'pidentd-2.7/doc/TAPvsIDENT' ||
$echo 'restore of' 'pidentd-2.7/doc/TAPvsIDENT' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/doc/TAPvsIDENT:' 'MD5 check failed'
6c24235ab2625d9587b2e6d11761d63a pidentd-2.7/doc/TAPvsIDENT
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/doc/TAPvsIDENT'`"
test 424 -eq "$shar_count" ||
$echo 'pidentd-2.7/doc/TAPvsIDENT:' 'original size' '424,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/doc/TESTRESULTS ==============
if test -f 'pidentd-2.7/doc/TESTRESULTS' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/doc/TESTRESULTS' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/doc/TESTRESULTS' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/doc/TESTRESULTS' &&
This daemon has been tested on the following machines/OS (please report
to me if you've tested a newer version, or if your machine/OS isn't among
the ones below):
X
Machine Operating System Pidentd version
---------------------- ---------------------- --------------------------
X IBM RS6000/320 AIX 3.2 2.7b4
X Sequent Balance Dynix 3.0.14 2.7b4
X Sun IPC NetBSD 1.1 2.7b4
X Sun 3/480 SunOS 4.0.3_U1 2.7b4
X Sun SS10/412 SunOS 4.1.3 2.7b4
X Sun 4/490 SunOS 5.4 2.7b4
X Sun SS1000/514 SunOS 5.5 2.7b4
X Sun SS10/402 SunOS 5.5.1 2.7b4
X Dell 433 Linux 2.0.0 2.7b4
X Vax6000/420 Ultrix 4.5 2.7b4
X
X
X
Old test results:
X
Machine Operating System Pidentd version
---------------------- ---------------------- --------------------------
X Sequent Balance Dynix 3.0.14 2.4
X Sequent Symmetry Dynix 3.1.2 2.1beta.3
X Sun 3/50 SunOS 3.5 2.1beta.8.1 (3)
X Sun 386i SunOS 4.0.2 2.2beta.2
X Sun 2/120 SunOS 4.0.3 2.1beta.10
X Sun 3/480 SunOS 4.1.1_U1 2.4
X HP 9000/375 HP-UX 7.0 2.1beta.10.1 (1)
X HP 9000/340 HP-UX 8.0 2.2beta.2
X HP 9000/720 HP-UX 8.07 2.1beta.10.1
X HP 9000/715 HP-UX 9.0 2.2beta.2
X HP 9000/827 HP-UX 8.02 2.1beta.8.1
X HP 9000/834 HP-UX 7.0 2.0beta.4
X HP 9000/835 HP-UX 8.00 2.1beta.10.1
X HP 9000/847 HP-UX 9.0 2.2beta.2
X MIPS RISC/OS 4.5x 2.1beta.8.1
X DECstation 2100 Ultrix 4.2-96 2.1beta.2 (2)
X DECstation 5000/133 Ultrix 4.2 2.1beta.9.1 (2)
X DEC VAXstation 2000 Ultrix-32 3.1 2.2beta.1 (2)
X DEC VAX vs3520 Ultrix 3.0 2.1beta.9.1 (2)
X DEC VAX 11/780 4.3BSD Reno 2.1beta.12 (2)
X i486-PC UHC SVR4 2.0 2.0beta.4 (2)
X i486-PC Dell SVR4 2.2 2.0beta.4 (2)
X i486-PC ESIX SVR4 4.0.4 2.1beta.2 (2)
X i486-PC 386BSD 0.1 2.1beta.3 (2)
X i486-PC Linux 0.99.13q 2.2beta.2
X Cray UNICOS 6.0.12 2.1beta.7
X NeXT NeXTSTEP 2.1 2.6.1
X NeXT NeXTSTEP 3.0 2.1beta.9.1 (3)
X Pyramid 90x dualPort OSx 4.1 2.1beta.12
X Silicon Graphics IRIX 4 2.1beta.10
X IBM RS/6000 AIX 3.2.4 2.4
X
Notes:
X 1) HP-UX 7.0 doesn't support running streams based services from
X Inetd with the "wait" option (and the "-w" flag to Pidentd).
X
X It also has problems with starting stuff as user "sys" from Inetd.
X (It doesn't correctly set the group id to "sys") so I suggest you
X either starts it as user "root" and use the "-u" and "-g" flags
X to setuid and setgid itself to user "sys", group "sys", or do a
X 'chgrp sys in.identd' and then a 'chmod g+s in.identd' and start
X it as user "sys" from Inetd.
X
X 2) These systems also doesn't support running streams based
X services from Inetd with the "wait" option.
X
X 3) See notes in the READMEs/README.<machine-type> specific files.
X
X
X - Peter Eriksson <p...@lysator.liu.se>, 14 Oct 1994
SHAR_EOF
$shar_touch -am 0813100096 'pidentd-2.7/doc/TESTRESULTS' &&
chmod 0644 'pidentd-2.7/doc/TESTRESULTS' ||
$echo 'restore of' 'pidentd-2.7/doc/TESTRESULTS' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/doc/TESTRESULTS:' 'MD5 check failed'
b8acd4c60da826d1c22924e2a782f9da pidentd-2.7/doc/TESTRESULTS
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/doc/TESTRESULTS'`"
test 3157 -eq "$shar_count" ||
$echo 'pidentd-2.7/doc/TESTRESULTS:' 'original size' '3157,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/doc/why-encrypt.txt ==============
if test -f 'pidentd-2.7/doc/why-encrypt.txt' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/doc/why-encrypt.txt' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/doc/why-encrypt.txt' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/doc/why-encrypt.txt' &&
``Why encrypt ident/TAP replies ?''
Damien Doligez
1994.02.22
X
X
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.
X
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.
X
This starts as a structured document and ends in random comments
and implementation remarks.
X
X
Problems with ident.
X
The ident protocol, as implemented by pidentd return a cleartext
identification of the user. This approach has the following problems:
X
1. The remote administrator is tempted to interpret the ident logs
X without asking the local administrator. Everybody is supposed
X to know that ident replies are only meaningful to the local
X administrator, but in the real world, the remote administrator
X will forget that, especially if the ident data is mixed with
X data from his own machines (which is almost always the case).
X
2. Any user on the remote system can call the local ident server
X and collect login names for guessing passwords, and usage
X patterns.
X
3. The remote administrator might be malevolent and lie to you about
X the contents of his ident logs.
X
4. Some network attacks on the ident protocol have been described
X on Usenet (comp.security.*). They involve intercepting ident
X requests and replying with bogus information, from another host
X on the network, with forged IP packets.
X
X
The crypto solution.
X
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.
X
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 ?)
X
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.
X
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.
X
X
My solution is to encrypt a packet of data that contains:
- The date
- The user ID
- Both machine addresses
- Both port numbers.
X
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.
X
Problem 1 is solved by forcing the remote administrator to ask you
to decrypt the data.
X
Problem 2 is solved by making the data unuseable except by yourself.
X
Problem 3 and 4 are solved by making the piece of data self-contained
and unforgeable.
X
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.
X
X
Implementation.
X
The packet of data is a 24-byte record with the following layout:
X
block bytes contents
X 1 4 checksum
X 2 random
X 2 user ID
X 2 4 date
X 4 local IP address
X 3 4 remote IP address
X 2 local port number
X 2 remote port number
X
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:
X
X c0 = E (p0)
X c1 = E (p1 ^ c0)
X c2 = E (p2 ^ c1)
X
Where E is DES with a secret key. The secret key is stored in a file
only readable by root on the local machine.
X
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.
X
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).
X
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.
X
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.
X
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.
X
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.
X
The DES implementation and hash function used are from the libdes
library, written by Eric Young (e...@psych.psy.uq.oz.au) and available
(among other sites) from ftp.funet.fi.
X
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.
X
Maybe I should add an option to the decryption program for specifying
an alternate key file.
SHAR_EOF
$shar_touch -am 0223221794 'pidentd-2.7/doc/why-encrypt.txt' &&
chmod 0644 'pidentd-2.7/doc/why-encrypt.txt' ||
$echo 'restore of' 'pidentd-2.7/doc/why-encrypt.txt' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/doc/why-encrypt.txt:' 'MD5 check failed'
0d137d1b37793d1d73049189c03828a7 pidentd-2.7/doc/why-encrypt.txt
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/doc/why-encrypt.txt'`"
test 7046 -eq "$shar_count" ||
$echo 'pidentd-2.7/doc/why-encrypt.txt:' 'original size' '7046,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/doc/why-ident.txt ==============
if test -f 'pidentd-2.7/doc/why-ident.txt' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/doc/why-ident.txt' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/doc/why-ident.txt' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/doc/why-ident.txt' &&
Well... Go read "why-tap.txt". More or less the same arguments
apply for the IDENT protocol. :-)
X
I'm not sure the "rfc931-users" mailing list is alive anymore though.
I've created a new mailing list "ident...@lysator.liu.se" that you
may wish to join instead. Send email to "ident-use...@lysator.liu.se"
to join/leave that list.
X
/Peter Eriksson <p...@lysator.liu.se>, 3 Nov 1993
X
X
SHAR_EOF
$shar_touch -am 0204173593 'pidentd-2.7/doc/why-ident.txt' &&
chmod 0644 'pidentd-2.7/doc/why-ident.txt' ||
$echo 'restore of' 'pidentd-2.7/doc/why-ident.txt' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/doc/why-ident.txt:' 'MD5 check failed'
3330750b057c9ec6f74a130db97221ef pidentd-2.7/doc/why-ident.txt
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/doc/why-ident.txt'`"
test 393 -eq "$shar_count" ||
$echo 'pidentd-2.7/doc/why-ident.txt:' 'original size' '393,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/doc/why-tap.txt ==============
if test -f 'pidentd-2.7/doc/why-tap.txt' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/doc/why-tap.txt' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/doc/why-tap.txt' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/doc/why-tap.txt' &&
``Why TAP?'' A White Paper
Daniel J. Bernstein
draft 3
920820
X
X
1. Introduction
X
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.
X
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.
X
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.
X
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.
X
X
2. Remote auditing
X
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?
X
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.
X
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.
X
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.
X
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.
X
X
3. Selective blocking
X
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?
X
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.
X
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.
X
X
4. Pointers to further information
X
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.
X
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-use...@kramden.acf.nyu.edu. rfc931-users maintains a list
of known server hosts, as well as current information on implementations
and other useful items.
X
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.
X
SHAR_EOF
$shar_touch -am 0827013392 'pidentd-2.7/doc/why-tap.txt' &&
chmod 0644 'pidentd-2.7/doc/why-tap.txt' ||
$echo 'restore of' 'pidentd-2.7/doc/why-tap.txt' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/doc/why-tap.txt:' 'MD5 check failed'
17f5895678ee9ffdf720deb29dc1204b pidentd-2.7/doc/why-tap.txt
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/doc/why-tap.txt'`"
test 6404 -eq "$shar_count" ||
$echo 'pidentd-2.7/doc/why-tap.txt:' 'original size' '6404,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/identd.man ==============
if test -f 'pidentd-2.7/identd.man' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/identd.man' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/identd.man' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/identd.man' &&
X.\" @(#)identd.8 1.9 92/02/11 Lysator
X.\" Copyright (c) 1992 Peter Eriksson, Lysator, Linkoping University.
X.\" This software has been released into the public domain.
X.\"
X.TH IDENTD 8 "27 May 1992"
X.SH NAME
identd, in.identd \- TCP/IP IDENT protocol server
X.SH SYNOPSIS
X.B xDESTDIRx/[in.]identd
X.RB [ \-i | \-w | \-b ]
X.RB [ \-t<seconds> ]
X.RB [ \-u<uid> ]
X.RB [ \-g<gid> ]
X.RB [ \-p<port> ]
X.RB [ \-a<address> ]
X.RB [ \-c<charset> ]
X.RB [ \-C [ <keyfile> ]]
X.RB [ \-o ]
X.RB [ \-e ]
X.RB [ \-l ]
X.RB [ \-V ]
X.RB [ \-m ]
X.RB [ \-N ]
X.RB [ \-d ]
X.RB [ \-F<format> ]
X.RB [ "kernelfile" [ "kmemfile" ] ]
X.SH DESCRIPTION
X.IX "identd daemon" "" \fLidentd\fP daemon"
X.B identd
is a server which implements the
X.SM TCP/IP
proposed standard
X.SM IDENT
user identification protocol as specified in the
X.SM RFC\s0 1413
document.
X.PP
X.B identd
operates by looking up specific
X.SM TCP/IP
connections and returning the user name of the
process owning the connection. It can optionally
return other information instead of a user name.
X.SH ARGUMENTS
The
X.B \-i
flag, which is the default mode, should be used when starting the
daemon from
X.B inetd
with the "nowait" option in the
X.B /etc/inetd.conf
file. Use of this mode will make
X.B inetd
start one
X.B identd
daemon for each connection request.
X.PP
The
X.B \-w
flag should be used when starting the daemon from
X.B inetd
with the "wait" option in the
X.B /etc/inetd.conf
file . This is the prefered mode of
operation since that will start a copy of
X.B identd
at the first connection request and then
X.B identd
will handle subsequent requests
without having to do the nlist lookup in the kernel file for
every request as in the
X.B \-i
mode above. The
X.B identd
daemon will run either forever, until a bug
makes it crash or a timeout, as specified by the
X.B \-t
flag, occurs.
X.PP
The
X.B \-b
flag can be used to make the daemon run in standalone mode without
the assistance from
X.BR inetd.
This mode is the least prefered mode since
a bug or any other fatal condition in the server will make it terminate
and it will then have to be restarted manually. Other than that it has the
same advantage as the
X.B \-w
mode in that it parses the nlist only once.
X.PP
The
X.B \-t<seconds>
option is used to specify the timeout limit. This is the number
of seconds a server started with the
X.B \-w
flag will wait for new connections before terminating. The server is
automatically restarted by
X.B inetd
whenever a new connection is requested
if it has terminated. A suitable value for this is 120 (2 minutes), if
used. It defaults to no timeout (i.e. will wait forever, or until a
fatal condition occurs in the server).
X.PP
The
X.B \-u<uid>
option is used to specify a user id number which the
X.BR ident
server should
switch to after binding itself to the
X.SM TCP/IP
port if using the
X.B \-b
mode of operation.
X.PP
The
X.B \-g<gid>
option is used to specify a group id number which the
X.BR ident
server should
switch to after binding itself to the
X.SM TCP/IP
port if using the
X.B \-b
mode of operation.
X.PP
The
X.B \-p<port>
option is used to specify an alternative port number to bind to if using
the
X.B \-b
mode of operation. It can be specified by name or by number. Defaults to the
X.SM IDENT
port (113).
X.PP
The
X.B \-a<address>
option is used to specify the local address to bind the socket to if using
the
X.B \-b
mode of operation. Can only be specified by IP address and not by domain
name. Defaults to the
X.SM INADDR_ANY
address which normally means all local addresses.
X.PP
The
X.B \-V
flag makes
X.B identd
display the version number and then exit.
X.PP
The
X.B \-l
flag tells
X.B identd
to use the System logging daemon
X.B syslogd
for logging purposes.
X.PP
The
X.B \-o
flag tells
X.B identd
to not reveal the operating system type it is run on and to instead
always return "OTHER".
X.PP
The
X.B \-e
flag tells
X.B identd
to always return "UNKNOWN-ERROR" instead of the "NO-USER" or
"INVALID-PORT" errors.
X.PP
The
X.B \-c<charset>
flags tells
X.B identd
to add the optional (according to the IDENT protocol) character set
designator to the reply generated.
X.I charset
should be a valid character set as described in the MIME RFC in upper
case characters.
X.PP
The
X.BR \-C [ <keyfile> ]
option tells
X.B identd
to return encrypted tokens instead of user names.
The local and remote IP
addresses and TCP port numbers, the local user's uid number, a timestamp,
a random number, and a checksum, are all encrypted using DES
with a secret key derived from the first line of the
X.I keyfile
(using
X.BR des_string_to_key (3)).
The encrypted binary information is then encoded in a base64 string
(32 characters in length) and enclosed in square brackets to produce
a token that is transmitted to the remote client.
The encrypted token can later be decrypted by
X.BR idecrypt (8).
There may not be a space between the
X.B \-C
and the name of the
X.IR keyfile .
If the
X.I keyfile
is not specified, it defaults to
X.BR /etc/identd.key .
X.PP
The
X.B \-n
flag tells
X.B identd
to always return user numbers instead of user names if you wish to
keep the user names a secret.
The
X.B \-N
flag makes
X.B identd
check for a file ".noident" in each homedirectory for a user which the
daemon is about to return the user name for. It that file exists then the
daemon will give the error
X.B HIDDEN-USER
instead of the normal USERID response.
X.PP
X.B \-m
flag makes
X.B identd
use a mode of operation that will allow multiple requests to be
processed per session. Each request is specified one per line and
the responses will be returned one per line. The connection will not
be closed until the connecting part closes it's end of the line.
PLEASE NOTE THAT THIS MODE VIOLATES THE PROTOCOL SPECIFICATION AS
IT CURRENTLY STANDS.
X.PP
The
X.B \-d
flag enables some debugging code that normally should NOT
be enabled since that breaks the protocol and may reveal information
that should not be available to outsiders.
X.PP
The
X.B \-F<format>
option makes
X.B identd
use the specified format to display info. The allowed format specifiers are:
X.in +.5i
X.nf
%u print user name
%U print user number
%g print (primary) group name
%G print (primary) group number
%l print list of all groups by name
%L print list of all groups by number
%p print process ID of running process
%c print command name
%C print command and arguments
X.in -.5i
X.fi
The lists of groups (%l, %L) are comma-separated, and start with the primary
group which is not repeated. The %p and the %c and %C formats are not
supported on all architecture implementations (printing 0 or empty string
instead).
X.br
Any other characters (preceded by %, and those not preceded by it) are
printed literally. The "default" format is %u, and you should not use
anything else without the
X.B \-o
flag.
X.br
Not implemented yet, but on my wish-list are the following:
X.in +.5i
X.nf
%w print working (current) directory
%h print home (login, naming) directory
%e print the environment
X.in -.5i
X.fi
X.PP
X.B kernelfile
defaults to the normally running kernel file.
X.PP
X.B kmemfile
defaults to the memory space of the normally running kernel.
X.SH UNDOCUMENTED FLAGS
The
X.B \-v
flag enables more verbose output or messages. (Further occurences of the
X.B -v
flag make things even more verbose.) Currently not used: ignored.
X.PP
The
X.B \-f<config-file>
option causes
X.B identd
to use the named config file (instead of the default /etc/identd.conf ?).
Currently not used: ignored, no config files are used.
X.PP
The
X.B \-r<indirect_host>
option is used in some way (for proxy queries?).
X.PP
The
X.B \-C<keyfile>
option is used in some way for DES encryption.
X.SH INSTALLATION
X.B identd
is invoked either by the internet server (see
X.BR inetd (8C)
) for requests to connect to the
X.SM IDENT
port as indicated by the
X.B /etc/services
file (see
X.BR services (5)
) when using the
X.B \-w
or
X.B \-i
modes of operation or started manually by using the
X.B \-b
mode of operation.
X.SH EXAMPLES
Assuming the server is located in
X.B /usr/etc/in.identd
one can put either:
X.PP
ident stream tcp wait sys /usr/etc/in.identd in.identd -w -t120
X.PP
or:
X.PP
ident stream tcp nowait sys /usr/etc/in.identd in.identd -i
X.PP
into the
X.B /etc/inetd.conf
file. User "sys" should have enough rights to READ the kernel
but NOT to write to it.
X.PP
To start it using the
X.B \-b
mode of operation one can put a line like this into the
X.B /etc/rc.local
file:
X.PP
/usr/etc/in.identd -b -u2 -g2
X.PP
This will make it run in the background as user 2, group 2 (user "sys",
group "kmem" on SunOS 4.1.1).
X.SH NOTES
The username (or UID) returned ought to be the login name. However it
(probably, for most architecture implementations) is the "real user ID" as
stored with the process; there is no provision for returning the "effective
user ID". Thus the UID returned may be different from the login name for
setuid programs (or those running as root) which done a
X.BR setuid (3)
call and their children. For example, it may (should?) be wrong for an
incoming
X.B ftpd
; and we are probably interested in the running shell, not the
X.B telnetd
for an incoming telnet session. (But of course
X.B identd
returns info for outgoing connections, not incoming ones.)
X.PP
The group or list of groups returned (with the
X.B \-F
option) are as looked up in the
X.B /etc/passwd
and
X.B /etc/group
files, based on the UID returned. Thus these may not relate well to the
group(s) of the running process for setuid or setgid programs or their
children.
X.PP
The command names returned with formats %c and %C may be different, use
one or the other or both.
X.SH FILES
X.TP
X.B xCONFDIRx/identd.conf
This file is as yet un-used, but will eventually contain configuration
options for
X.B identd
X.TP
X.B xCONFDIRx/identd.key
If compiled with
X.I \-ldes
this file can be used to specify a secret key for encrypting replies.
X.SH "SEE ALSO"
X.BR authuser (3)
,
X.BR inetd.conf (5)
,
X.BR idecrypt (8)
X.SH BUGS
The handling of fatal errors could be better.
SHAR_EOF
$shar_touch -am 0811225896 'pidentd-2.7/identd.man' &&
chmod 0644 'pidentd-2.7/identd.man' ||
$echo 'restore of' 'pidentd-2.7/identd.man' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/identd.man:' 'MD5 check failed'
3b2992bb5b5925831ed28fbf5de74b83 pidentd-2.7/identd.man
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/identd.man'`"
test 9915 -eq "$shar_count" ||
$echo 'pidentd-2.7/identd.man:' 'original size' '9915,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/idecrypt.man ==============
if test -f 'pidentd-2.7/idecrypt.man' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/idecrypt.man' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/idecrypt.man' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/idecrypt.man' &&
X.TH IDECRYPT 8 "19 May 1996"
X.SH NAME
idecrypt \- Decrypt tokens obtained from identd
X.SH SYNOPSIS
X.B /usr/sbin/idecrypt
X.SH DESCRIPTION
X.B idecrypt
is a utility for decrypting the encrypted tokens that
X.BR identd (8)
provided instead of usernames when it is
run in encrypted-token mode (that is, with the
X.B \-C
flag).
X.PP
X.B idecrypt
reads up to 1024 lines from the
X.B /etc/identd.key
file, converting each line to a DES key using
X.BR des_string_to_key (3).
It then reads standard input, searching for encrypted tokens
in the format produced by
X.BR identd (8),
decrypts the tokens if possible, and copies all unrecognised text from
standard input to standard output without modification.
X.PP
If more than one key appears in the key file, then
X.BR identd (8)
will use the first key for encryption, and
X.B idecrypt
will attempt to use all the keys for decryption.
This allows new keys to be used by
X.BR identd (8)
without losing the ability for
X.B idecrypt
to decrypt old tokens (until there are more than 1024 keys in the key file).
X.PP
Each encrypted token consists of 32 base64 characters, enclosed in
square brackets. To make it easier to process logs generated by
versions of
X.B tcpd (8)
that convert the square brackets to underlines,
X.B idecrypt
permits underline characters instead of square brackets
in its input.
X.PP
X.BR idecrypt 's
output from decrypting each token is a human readable string
containing the timestamp (displayed as a local time in
X.BR ctime (3)
format), the numeric uid, the local IP address, the local port number,
the remote IP address and the remote port number.
X.SH EXAMPLE
Suppose that the local host has IP address 10.2.3.4, the local
X.B /etc/identd.key
file contains
X.PP
foobar
X.PP
and the local host is running the
X.BR identd (8)
server in encrypted-token mode.
X.PP
Now, if a local user
with uid 501 telnets to a remote host with IP address 10.9.8.7,
the remote host may choose to make an ident query back to the
local host, in order to obtain some information to be logged for
possible use later. The local
X.BR identd (8)
might send the following encrypted token to the remote host
instead of sending a username:
X.PP
[aALdNYxh2496K4DDTel2Nk0Jzj5mRbok]
X.PP
If the administrator of the remote host later provides the administrator
of the local host with a copy of the encrypted token, and if
the secret key has not been removed from the local
X.B /etc/identd.key
file, then the administrator of the local host can run
X.B idecrypt
and can provide the encrypted token in standard input.
X.PP
X.B idecrypt
will then print the following decrypted information:
X.PP
Sun May 19 00:25:23 1996 501 10.2.3.4 2304 10.9.8.7 23
X.PP
This represents the time the encrypted token was created,
the local user id, the local IP address and port number, and the
remote IP address and port number.
X.SH SEE ALSO
X.BR identd (8)
X.BR tcpd (8)
X.SH BUGS
The handling of fatal errors could be better.
SHAR_EOF
$shar_touch -am 0811230996 'pidentd-2.7/idecrypt.man' &&
chmod 0644 'pidentd-2.7/idecrypt.man' ||
$echo 'restore of' 'pidentd-2.7/idecrypt.man' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/idecrypt.man:' 'MD5 check failed'
73f1d960d02eca45cc7e3722c8f2fdab pidentd-2.7/idecrypt.man
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/idecrypt.man'`"
test 2907 -eq "$shar_count" ||
$echo 'pidentd-2.7/idecrypt.man:' 'original size' '2907,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/src/Makefile ==============
if test ! -d 'pidentd-2.7/src'; then
$echo 'x -' 'creating directory' 'pidentd-2.7/src'
mkdir 'pidentd-2.7/src'
fi
if test -f 'pidentd-2.7/src/Makefile' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/src/Makefile' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/src/Makefile' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/src/Makefile' &&
#
# Makefile
#
# Makefile for the Pidentd daemon
#
# Author: Peter Eriksson <p...@lysator.liu.se>
#
X
SHELL=/bin/sh
KSRC=kernel.c
COBJS= parse.o kernel.o kvm.o version.o proxy.o config.o crypto.o
X
foo:
X @echo 'Nono! Don't type "make" in this directory, use the one above!'
X
$(PREFIX)identd: identd.o $(COBJS) idecrypt itest
X $(CC) $(LDFLAGS) -o $(PREFIX)identd identd.o $(COBJS) $(LIBS)
X mv $(PREFIX)identd ..
X
idecrypt: idecrypt.o crypto.o
X $(CC) $(LDFLAGS) -o idecrypt idecrypt.o crypto.o $(LIBS)
X mv idecrypt ..
X
identd.o: identd.c identd.h error.h crypto.h Makefile
parse.o: parse.c identd.h error.h crypto.h Makefile
kvm.o: kvm.c kernel/kvm.h paths.h Makefile
config.o: config.c Makefile
proxy.o: proxy.c Makefile
version.o: version.c Makefile
crypto.o: crypto.c Makefile
idecrypt.o: idecrypt.c crypto.h Makefile
X
kernel.o: kernel/$(KSRC).c identd.h error.h kernel/kvm.h Makefile
X $(CC) $(CFLAGS) -c -o kernel.o -I. kernel/$(KSRC).c
X
libkvm.a: kvm.o
X @rm -f libkvm.a
X ar cq libkvm.a kvm.o
X
itest: itest.o kernel.o kvm.o
X $(CC) $(LDFLAGS) -o itest itest.o kernel.o kvm.o $(LIBS)
X mv itest ..
X
clean:
X -rm -f $(PREFIX)identd core *.o kernel/*.o
SHAR_EOF
$shar_touch -am 0811215496 'pidentd-2.7/src/Makefile' &&
chmod 0644 'pidentd-2.7/src/Makefile' ||
$echo 'restore of' 'pidentd-2.7/src/Makefile' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/src/Makefile:' 'MD5 check failed'
b86883d038b7ed9c7849c1324491157c pidentd-2.7/src/Makefile
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/src/Makefile'`"
test 1167 -eq "$shar_count" ||
$echo 'pidentd-2.7/src/Makefile:' 'original size' '1167,' 'current size' "$shar_count!"
fi
fi
# ============= pidentd-2.7/src/config.c ==============
if test -f 'pidentd-2.7/src/config.c' && test "$first_param" != -c; then
$echo 'x -' SKIPPING 'pidentd-2.7/src/config.c' '(file already exists)'
else
$echo 'x -' extracting 'pidentd-2.7/src/config.c' '(text)'
sed 's/^X//' << 'SHAR_EOF' > 'pidentd-2.7/src/config.c' &&
/*
** config.c This file handles the config file
**
** This program is in the public domain and may be used freely by anyone
** who wants to.
**
** Last update: 6 Dec 1992
**
** Please send bug fixes/bug reports to: Peter Eriksson <p...@lysator.liu.se>
*/
X
#include <stdio.h>
#include <errno.h>
X
#include "error.h"
#include "identd.h"
#include "paths.h"
X
X
int parse_config(path, silent_flag)
X char *path;
X int silent_flag;
{
X FILE *fp;
X
X if (!path)
X path = PATH_CONFIG;
X
X fp = fopen(path, "r");
X if (!fp)
X {
X if (silent_flag)
X return 0;
X
X ERROR1("error opening %s", path);
X }
X
X /*
X ** Code should go here to parse the config file data.
X ** For now we just ignore the contents...
X */
X
X
X fclose(fp);
X return 0;
}
SHAR_EOF
$shar_touch -am 1206225292 'pidentd-2.7/src/config.c' &&
chmod 0644 'pidentd-2.7/src/config.c' ||
$echo 'restore of' 'pidentd-2.7/src/config.c' 'failed'
if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
&& ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
md5sum -c << SHAR_EOF >/dev/null 2>&1 \
|| $echo 'pidentd-2.7/src/config.c:' 'MD5 check failed'
4ca219fea5ee9f2b9888e87fab8f2666 pidentd-2.7/src/config.c
SHAR_EOF
else
shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'pidentd-2.7/src/config.c'`"
test 769 -eq "$shar_count" ||
$echo 'pidentd-2.7/src/config.c:' 'original size' '769,' 'current size' "$shar_count!"
fi
fi
: || $echo 'restore of' 'pidentd-2.7/src/crypto.c' 'failed'
$echo 'End of part' '3,' 'continue with part' '4'
exit 0