This README.DES file should probably be cleaned up. But for an alpha
release of Pidentd it might do for now.. :-)
Also see the file DES-DOC (included last in this file) for more
information, especially regarding the format of the identd.key file.
Don't believe all I say below about it. DES-DOC is more correct. I'll
write better documentation for a Beta verison of Pidentd 2.3 ...
Do install an encrypting version of Pidentd you'll need to create a
1024 byte big file "/etc/identd.key" that should contain the DES key
Pidentd should use. I created one with:
dd if=/bin/passwd of=/etc/identd.key bs=1024 count=1
which seemed to work. But then again, I'm not really into this crypto
thing. Anybody know the a correct way to generate a DES key?
Then use the 'idecrypt' command to decrypt to identifier returned.
You can test your Pidentd by installing it and then typing:
telnet lysator.liu.se 114 | idecrypt
That should translate the encrypted identifier returned into
some usable information (date, uid, local and foreign port and addresses).
/Peter Eriksson <pen@lysator.liu.se>, 23 Feb 1994
Below follows the original letter:
From doligez@lix.polytechnique.fr Wed Feb 23 14:09:41 1994
Flags: 000000000001
Received: from polytechnique.polytechnique.fr (root@polytechnique.polytechnique.fr [129.104.30.1]) by godot.lysator.liu.se (8.6.6.Beta2/8.6.6.Beta2) with ESMTP id OAA12199 for <pen@lysator.liu.se>; Wed, 23 Feb 1994 14:09:22 +0100
Received: from lix.polytechnique.fr (lix.polytechnique.fr [129.104.11.2]) by polytechnique.polytechnique.fr (8.6.4/8.6.4) with SMTP id OAA03246 for <pen@lysator.liu.se>; Wed, 23 Feb 1994 14:16:56 +0100
Received: by lix.polytechnique.fr (5.65/5.65c-IDA-polytechnique)
id AA10927; Wed, 23 Feb 1994 14:07:56 +0100
Date: Wed, 23 Feb 1994 14:07:56 +0100
From: doligez@lix.polytechnique.fr (Damien Doligez)
Message-Id: <9402231307.AA10927@lix.polytechnique.fr>
To: pen@lysator.liu.se
Subject: Re: pidentd
Keywords: pidentd-crypt
>Yes, please send me the diffs! I would very much like to integrate
>them into the standard pidentd distribution!
I was hoping you would say that.
This is the patch, along with a list of things that I should have done :-)
How to install the patch:
^^^^^^^^^^^^^^^^^^^^^^^^^
- Extract the pidentd-2.2 directory from its distribution.
- Move this file into the pidentd-2.2 directory under the name
"patch-crypto".
- Go to the pidentd-2.2 directory and type: patch -p <patch.crypto
- remove the patch.crypto file.
How to compile:
^^^^^^^^^^^^^^^
- Transfer libdes.tar.92-10-13.Z from
ftp.funet.fi:/pub/crypt/libdes/libdes.tar.92-10-13.Z
create a pidentd-2.2/libdes directory and extract the tar file in
that directory.
- Type "make" in the libdes directory.
- Type "make <ostype>" in the pidentd-2.2 directory.
Things to do: (If you insist, I can do some of these myself.)
^^^^^^^^^^^^^
- Document the crypto option and how it uses libdes in the INSTALL file.
- Do something to #include <des.h> and link with -ldes if libdes is
already installed on the machine (see libdes/INSTALLATION).
- Change the man page to document the -C option and the format of the
key file.
- Document the idecrypt command. The output fields are:
<date> <uid> <local-IP> <local-port> <remote-IP> <remote-port>
- Change the TODO file to remove the line about encryption.
- Tell the user to compare the outputs of "make" and "make | idecrypt" in
testdir (in INSTALL).
- Check the portability of the encryption code. (esp. on 64-bit machines).
- Integrate the make in libdes into the main Makefile.
- Rework the "why-encrypt" document. Some parts of it should be in the
man page.
- Find out how secure the CBC encryption without an IV really is.
- crypto.h should have an #ifdef KEY_FILE #endif around it.
- Test the make without the crypto option. Did I break something ?
==== DES-DOC =================================================================
From doligez@lix.polytechnique.fr Thu Mar 31 13:55:09 1994
Flags: 000000000001
Received: from polytechnique.polytechnique.fr (root@polytechnique.polytechnique.fr [129.104.30.1]) by godot.lysator.liu.se (8.6.7/8.6.6) with ESMTP id NAA04629 for <pen@lysator.liu.se>; Thu, 31 Mar 1994 13:55:01 +0200
Received: from lix.polytechnique.fr (lix.polytechnique.fr [129.104.11.2]) by polytechnique.polytechnique.fr (8.6.4/8.6.4) with SMTP id OAA18795 for <pen@lysator.liu.se>; Thu, 31 Mar 1994 14:04:47 +0200
Received: by lix.polytechnique.fr (5.65/5.65c-IDA-polytechnique)
id AA26554; Thu, 31 Mar 1994 13:55:19 +0200
Date: Thu, 31 Mar 1994 13:55:19 +0200
From: doligez@lix.polytechnique.fr (Damien Doligez)
Message-Id: <9403311155.AA26554@lix.polytechnique.fr>
To: pen@lysator.liu.se
Subject: pidentd-2.3alpha1
I have just read the README.DES file from the alpha release of
pidentd. I'm afraid I have not been clear in describing the format of
the key file.
What follows is a more thorough description. Feel free to ask me for
more details, I am not too good at writing documentation.
>>>
You write that the key file has to be 1024 bytes long. This is not
quite true. The key file is a text file. Each line of text is a key.
The 1024-byte limit is the maximum length of a key, so each line in
the key file must be less than 1024 characters in length (or maybe
1023).
The key file is used by the programs as follows:
The pidentd daemon will use the first line of the file as a key to
encrypt its responses, and ignore the rest of the file.
The decryption utility (idecrypt) will try every key in the file on
each encrypted packet, until it finds the right one. (Decrypted
packets have a checksum, so the decryption utility knows when it has
found the right key.)
The intended use of the key file is as follows:
When you want to change your key, you add a new line at the top of the
key file. Since this is a text file and the line can be quite long,
it might be a good idea to include the date, the name of the machine,
and maybe your own name. Don't forget to add a good number of random
characters, or your key will be too easy to find. The daemon will use
the new key as soon as you save the file. idecrypt will also know
about this new key, but it will still be able to try the old ones as
well. Thus if you have to decrypt an old log, it will work
transparently.
An other limitation of the key file is that only the 1024 fist keys
are taken into account by idecrypt. And since the decryption utility
tries all the keys on every packet that it cannot decrypt, it will be
slowed down by a big key file. So it is a good idea to remove very
old keys from this file.
Also, if you have several machines, it is better to use a different
key on each machine, in case one of the machines is compromised, and
you can add the keys for all the machines on your central (most
secure) machine so that you can decrypt ident responses from all your
machines by running idecrypt on that central machine.
An example:
At first, my key file looked like this:
----
1994.02.20 titus.polytechnique.fr doligez 624153126351241562
----
The series of digits at the end of the line was generated by rolling a
dice. (And it is too short for good security.)
Two weeks later, I felt paranoid and I decided to change my key, so
the file looked like:
----
1994.03.07 titus.polytechnique.fr doligez 215656215656361252
1994.02.20 titus.polytechnique.fr doligez 624153126351241562
----
Note that I kept the old key, which allows idecrypt to interpret my
old ident responses.
Then I noticed a break-in on my machine, and (after cleaning up and
plugging the holes) changed the key file to:
----
1994.03.19 titus.polytechnique.fr doligez 564125642156124665
1994.03.19 vlsi.polytechnique.fr doligez 635245623415621251
1994.03.07 titus.polytechnique.fr doligez 215656215656361252
----
I removed the key dated 1994.02.20, because I'm not interested in
1-month-old log entries, and I added the key for my second machine,
because I am logged on titus as root most of the time, so if I get a
mail from another administrator about a security problem, I can
decrypt the log even if the attempts came from vlsi.
You may use any part of this text for the user documentation for
pidentd/idecrypt.
Here are some tips&tricks for IBM users:
From Chris Moller (moller@vnet.ibm.com, moller@futserv.austin.ibm.com):
"Under IBM weirdness, after you modify /etc/services or /etc/inetd.conf,
you have to update the ODM by running, from root, the following:
inetimp
chrctcp -S -c inetd -f debug='no' -f file='/etc/inetd.conf'
or the changes don't take effect. Other than that, everything worked
fine out of the box."
From James Carlson <carlson@xylogics.com>:
One minor note, this program suffers from the same problem that a lot
of other kernel-reading programs do on AIX. Gcc doesn't align the
contents of the user structure correctly. Users have to add a "long
foo" element right before U_irss in a private copy of sys/user.h in
order to make it work.
Machine Type: Sequent Dynix 3.* Make using: make dynix3 Make optimised: make "CFLAGS=-O" "LDFLAGS=-s" dynix3 Person(s) porting: Peter Eriksson <pen@lysator.liu.se> Frank Maas <maas@dutiws.tudelft.nl> Port date: A long time ago... Verified working: OS version(s) Pident vers Person 3.0.14 2.1beta10 <pen@lysator.liu.se> Build comments: Nothing unusual Install comments: Generally install into /usr/etc Usage comments: Works as daemon (started from rc.local), or from inetd (if you port an Inetd yourself from for example 4.3BSD-net2). We run as user root, but any user with read access to /dev/kmem would be fine.
Machine Type: Silicon Graphics IRIX 4.* Make using: make irix4 Make optimised: make "CFLAGS=-O" "LDFLAGS=-s" irix4 Person(s) porting: Simon Leinen <simon@lia.di.epfl.ch> Port date: A long time ago... Verified working: OS version(s) Pident vers Person 4 2.1beta.10 <simon@lia.di.epfl.ch> Build comments: Nothing unusual Install comments: Generally install into /usr/etc Usage comments: Works as daemon or from inetd with wait/nowait Known bugs: It returns the <uid> of the process owning the socket in question instead of the <ruid>. Ie, it returns "root" instead of the actual user when the user runs a setuid-root program like rsh..
Frank Maas says: I have had this question a couple of times, so I wondered if you could add the following comment just before the #include <sys/vnode.h> state- ment in src/kernel/irix5.c... (we are talking pident2.5.1 here ;-): /** Well... here some problems begin: when upgrading IRIX to 5.3 the **/ /** `inst' program shows one of its peculiar bugs: the file vnode.h **/ /** has changed location in between versions and now the file is up- **/ /** grade first (new package) and then deleted (old package). So if **/ /** you have problems finding this file: reinstall eoe1.sw.unix. **/
Machine Type: NeXTstep 2.x/3.0 Make using: make next Make optimised: make "CFLAGS=-O -pipe" "LDFLAGS=-object" next Person(s) porting: Nigel Metheringham <nigelm@ohm.york.ac.uk> Port date: 5 April, 1993 Verified working: OS version Pident vers Person 3.0 2.1beta9 <nigelm@ohm.york.ac.uk> 2.1 2.1beta9 <Piete.Brooks@cl.cam.ac.uk> Build comments: Build using the optimising make line above - makes a much smaller tighter daemon. Edit the destination part of the Makefile to suit your system - common values are:- DESTROOT= DESTDIR=/usr/etc MANROOT=/usr/man MANDIR=$(MANROOT)/man8 This has only been tested on black (ie NeXT) hardware, however there is no reason why it should not run on white (486) hardware under NeXTstep for Intel Processors. Install comments: Generally install into /usr/etc Start from inetd (or as daemon if you prefer) Usage comments: Make sure that the user this runs under from inetd can read /dev/kmem. Alternatively run it as root - its quite safe!
Machine Type: NeXTstep 3.1 for Motorola (or Intel - untested) Make using: make nextmab Make optimised: make "CFLAGS=-O2 -pipe" "LDFLAGS=-object -s" nextmab (is the default) Build-Architecture: make "NEXTARCHS=-arch m68k -arch i386" for Multi-Architecture-Binary (default) make "NEXTARCHS=-arch m68k" for Motorola M68000 Binary make "NEXTARCHS=-arch i386" for Intel i486 Binary Person(s) porting: Nigel Metheringham <nigelm@ohm.york.ac.uk> (original NeXTSTEP 2.x / 3.0 version) Michael Kuch (NeXTSTEP 3.1 version) <mike@atlas.physchem.chemie.uni-tuebingen.de> others (?) Port date: 5 April, 1993 - NeXTSTEP 2.x / 3.0 version 11 August, 1993 - NeXTSTEP 3.1 version Verified working: OS version Pident vers Person 3.1-m68k 2.2alpha1 <mike@atlas.physchem.chemie. uni-tuebingen.de> Build comments: Edit the destination part of the Makefile to suit your system - common values are:- DESTROOT= DESTDIR=/usr/etc MANROOT=/usr/man MANDIR=$(MANROOT)/man8 Edit the NEXTARCH part of the Makefile if you want build a Single-Architecture-Binary (smaller). This has only been tested on black (ie NeXT) hardware, however there is no reason why it should not run on white (i486) hardware under NeXTstep 3.1 for Intel Processors. Install comments: Generally install into /usr/local/etc Start from inetd (or as daemon if you prefer) Usage comments: Make sure that the user this runs under from inetd can read /dev/kmem. Alternatively run it as root - its quite safe!
Machine Type: Sequent Dynix/ptx versions 2 & 4 Make using: make ptx or make ptx4 Make optimised: make "CFLAGS=-O" "LDFLAGS=-s" ptx2/4 Person(s) porting: Tim Wright <timw@sequent.com> Port date: Wed 19 Apr 1995 Verified working: OS version(s) Pident vers Person 2.1.6 2.5.2 <timw@sequent.com> 4.1beta 2.5.2 <timw@sequent.com> Build comments: Nothing unusual Install comments: Generally install into /usr/etc Usage comments: Tested running under inetd. This will *not* work unless you have ptx TCP/IP v2.4.0 or later. This was the first version where inetd will (optionally) pass a socket instead of a TLI endpoint. Has been tested in standalone mode. It has also not been tested under ptx 4.0.X. It may be necessary to change ptx4.c to open /dev/mem instead of /dev/kmem for this release.
Machine Type: MIPS RISC/OS 4.5x Make using: make riscos4 Make optimised: make "CFLAGS=-O" "LDFLAGS=-s" riscos4 Person(s) porting: Nigel Metheringham <nigelm@ohm.york.ac.uk> Port date: 5 April, 1993 Verified working: OS version Pident vers Person 4.51, 4.52 2.1beta10 <nigelm@ohm.york.ac.uk> Build comments: Nothing unusual Install comments: Generally install into /usr/etc Usage comments: Works as daemon or from inetd with wait/nowait We run as user bin, but as root would be fine.
Machine Type: SunOS 3.5 (other v3 SunOSs may work) Make using: make sunos3 Make optimised: make "CFLAGS=-O" "LDFLAGS=-s" sunos3 Person(s) porting: Nigel Metheringham <nigelm@ohm.york.ac.uk> [We are disposing of our Sun3s soon, so no further support will be done for this architecture] Port date: 5 April, 1993 Verified working: OS version Pident vers Person 3.5 2.1beta10 <nigelm@ohm.york.ac.uk> Build comments: A link is needed to allow compilation (due to code in the sys/file.h include file). This can be put in place by executing: ln -s /usr/include/sys h in the current directory (ie top directory of pidentd). Gcc works OK - probably rather better than system cc. Install comments: Generally install into /usr/etc Start from inetd (/etc/servers) (or as daemon if you prefer) Since this is an *old* BSD system, several of the inetd options are missing. You can only start it as a one shot daemon from inetd (edit /etc/servers), and you can specify no parameters. Remember there are limits on the number of lines in /etc/servers Usage comments: Since inetd calls identd with a parameter made up of the calling IP and port address (identd does not use this parameter), identd drops one argument if there are no options set! To get round this (ie from the command line) specify at least one option.
Machine Type: Sun SunOS 4.* Make using: make sunos4 Make optimised: make "CFLAGS=-O" "LDFLAGS=-s" sunos4 Person(s) porting: Peter Eriksson <pen@lysator.liu.se> Port date: A long time ago... Verified working: OS version(s) Pident vers Person 4.0.3, 4.1.1, 2.1beta10 <pen@lysator.liu.se> 4.1.3 Build comments: Nothing unusual Install comments: Generally install into /usr/etc Usage comments: Works as daemon or from inetd with wait/nowait We run as user sys, but as root would be fine.
Please note that the Solaris 2 port of Pidentd is very dependant on the version of Solaris. So when you upgrade to a new version of Solaris you most probably also must upgrade the Pidentd server. You can always find the latest version of Pidentd on ftp.lysator.liu.se in pub/ident/servers. Some common problems that may occur when compiling under Solaris 2: * You use /usr/ucb/cc - NEVER ever EVER use that compiler * You use GCC, but didn't run "fixincludes" correctly when installing it * You use GCC and have just upgraded from Solaris 2.3 to 2.4 (for example) and have forgotten to RERUN the "fixincludes". This just *MUST* do or things will fail in mysterious ways. You may have to enable the "SOLARIS24_WORKAROUND" feature in the file "src/kernel/sunos5.c" if you have problems getting "-b" and/or "-w" to work correctly under Solaris 2.4. Please tell me if you do and it helps you (send an email to pen@lysator.liu.se). Casper Dik <casper@fwi.uva.nl> says: I found a bug in Solaris 2.x inetd which may affect identd installations: if you change a tcp service from "nowait" to "wait" mode, inetd will still pass the connected socket (as happens in nowait mode) instead of the socket to do accept() on. The workaround is to first comment out the service and -HUP inetd, then reinstall the service as wait service and resend -HUP. Inetd apparently needs to forget all about this service. The symptom is accept returing errno 22.
I got the following message about the problems with Ultrix and connections that suddenly are closed: From sendmail-r8-request@CS.Berkeley.EDU Tue Oct 12 15:55:12 1993 Flags: 000000000001 Received: from hofmann.CS.Berkeley.EDU (hofmann.CS.Berkeley.EDU [128.32.131.12]) by godot.lysator.liu.se (8.5/8.5) with ESMTP id PAA02066; Tue, 12 Oct 1993 15:55:02 +0100 Received: from mastodon.CS.Berkeley.EDU (mastodon.CS.Berkeley.EDU [128.32.149.68]) by hofmann.CS.Berkeley.EDU (8.6.beta.13/8.6.beta.4) with ESMTP id HAA02072 for <sendmail-r8@CS.Berkeley.EDU>; Tue, 12 Oct 1993 07:45:15 -0700 Received: from localhost (eric@localhost) by mastodon.CS.Berkeley.EDU (8.5/8.5) id HAA19535; Tue, 12 Oct 1993 07:47:26 -0700 Message-Id: <199310121447.HAA19535@mastodon.CS.Berkeley.EDU> To: sendmail-r8@CS.Berkeley.EDU From: Eric Allman <eric@CS.Berkeley.EDU> Subject: IDENT protocol info Date: Tue, 12 Oct 1993 07:47:26 -0700 Sender: eric@mastodon.CS.Berkeley.EDU Keywords: pidentd I received the following describing the changes needed to run IDENT on Ultrix. eric ------- Forwarded Message From: Dan Mosedale <mosedale@genome.stanford.edu> Message-Id: <199310111806.AA06654@aeffle.Stanford.EDU> Subject: Re: anonymous mail To: eric@CS.Berkeley.EDU Date: Mon, 11 Oct 1993 11:06:25 +119303928 (PDT) Newsgroups: comp.security.misc Organization: Stanford University Genetics Department In article <294d8i$il8@agate.berkeley.edu> you write: >In article <2948np$6eu@usenet.INS.CWRU.Edu>, mcn@nostromo.cwru.edu (Michael Neuman) writes: >|> 2) Hack up sendmail to use rfc931. > >Unfortunately, TCP/IP bugs in many operating systems make it impossible >to implement RFC931 (actually RFC 1413 -- 931 has been obsoleted). In >particular, I've had problems with HP-UX and Ultrix, among others. FWIW, I've got pidentd 2.1.2 running under Ultrix 4.3 with a few caveats. For one thing, it doesn't work properly from inetd, it has to be run in daemon mode. However, the fact that it runs at all is probably due to the fact that I've got the following patch installed: /usr/sys/MIPS/BINARY/in_pcb.o (CLD CXO-8919) CHECKSUM: 56412 72 /usr/sys/MIPS/BINARY/ip_icmp.o CHECKSUM: 30060 43 /usr/sys/MIPS/BINARY/tcp_subr.o CHECKSUM: 58085 56 /usr/sys/MIPS/BINARY/udp_usrreq.o CHECKSUM: 24862 74 /usr/sys/MIPS/BINARY/uipc_domain.o CHECKSUM: 29573 17 - ---------------------------------- Establish an ftp session with a host across the gateway and put the process in background. Telnet to the same host using an unused port to force a "Host Unreachable" situation. Go back to the ftp session and it is dead. In order to fix the problem, the in_pcbnotify() routine in in_pcb.c should be aware of the local and foreign ports for a given connection. To fascilitate this the lport and fport parameters were added to in_pcbnotify. This required the calling routines (tcp_ctlinput and udp_ctlinput) to be called with an additional parameter, a pointer to the ip structure. The tcp header can be accessed in this ip structure. The tcp header yields the foreign and local ports. - -Dan ------- End of Forwarded Message
Machine Type: Cray UNICOS 6 Make using: make unicos6 Make optimised: make "CFLAGS=-O" "LDFLAGS=-s" sunos6 Person(s) porting: Douglas Lee Schales <Doug.Schales@sc.tamu.edu> Port date: A long time ago... Verified working: OS version(s) Pident vers Person 6.0.12 2.1beta.7 <Doug.Schales@sc.tamu.edu> Build comments: Nothing unusual Install comments: Generally install into /usr/etc Usage comments: Works as daemon or from inetd with wait/nowait Known bugs: It returns the <uid> of the process owning the socket in question instead of the <ruid>. Ie, it returns "root" instead of the actual user when the user runs a setuid-root program like rsh..
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.