[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
identd: return audit tokens? (prevent information gathering)
- To: tech_(_at_)_openbsd_(_dot_)_org
- Subject: identd: return audit tokens? (prevent information gathering)
- From: stanislav shalunov <shalunov_(_at_)_mccme_(_dot_)_ru>
- Date: Wed, 16 Sep 1998 14:08:09 GMT
- Delivery-date: Wed Sep 16 07:11:23 1998
It makes sense for me to have identd return something that does not
reveal any actual information about user owning a connection (except
whether the connection exists which the remote can check anyway, e.g.,
with netstat). Moreover it makes sense to have this behaviour by
Returning numerical UID doesn't do the trick as remote site still can
gather valuable information: just as an example, whether SMTP delivery
program runs as root or not, and much more.
The default behaviour now does not even prevent spammers from getting
valid email addresses on IRC or via a web server.
Identing the same connection twice should give different results as
there must be no way to build a correspondence between audit tokens
and usernames (think: guessing what's the token for root in some way
and then using this to gather information).
The version of pidentd that ships with OpenBSD does not support such
`audit token' feature.
RFC1413 allows such behaviour:
# "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 both examples of when "OTHER" should be
I vision the design as follows: there are two executables that make
the ident system: /usr/libexec/identd and /usr/sbin/deident; the
latter program takes an audit token and writes the username to stdout.
So the superuser of the host running identd can reconstruct the
username by an audit token but no-one else can get any information
about it. Some might argue that local users should be allowed to use
deident. It might be reasonable but then the file /etc/ident.key
should _not_ be world-readable but rather the deident program should
be made setgid.
There is a file /etc/ident.key containing a small amount (16 bytes) of
random data that will be used as a symmetrical key to encrypt and
decrypt usernames. File should be user/group root/ident mode 0640.
The identd process has to be able to read but not write it while no
normal users should have any access to the file.
Before returning a username to the remote side the following is done
to it by identd if invoked with appropriate option:
* It is filled with spaces up to MAXLOGNAME;
* Three NULs and some given number of random bytes are
appended to it;
* The result is encrypted with IDEA using /etc/ident.key;
* This is base64'ed or whatever and used as the audit token.
The program deident would do the reverse to the token and will
complain if it doesn't find the three NULs, or give the username
Does this make sense to you all?
Theo, should I write the necessary stuff? (If you think I should I'll
have some more questions)
Stanislav Shalunov System Administrator, MCCME (http://www.mccme.ru/)
Visit your host, monkey.org