Provided by: sidentd_3.5-3_i386
sidentd - Kerberos S/Ident responder
The S/Ident protocol is used to authenticate a user who is connecting
to a remote network service using a protocol (or software) which does
not support authentication. The user connects to a remote server, that
server opens a connection back to the client (a callback), and the
callback is answered by a daemon on the client machine that returns the
user’s authentication out of band. In the S/Ident standard, the remote
server that is trying to authenticate the user is called the requester,
and the daemon on the client system that returns the authentication
information is called the responder.
sidentd is a responder that implements the S/Ident protocol, a modified
version of the standard Ident protocol that allows for strong
authentication of a user using SASL. The protocol is defined in
draft-morgan-ident-ext-04.txt, included with the S/Ident source.
Like identd, sidentd accepts a query from a remote system that
specifies the ports of an open network connection between the system on
which sidentd runs and the system querying it. It looks up the owner
of that connection and returns their authentication information. The
current implementation supports both the standard Ident protocol (which
returns the user’s Unix username or UID) and the Kerberos v4 and GSS-
API SASL mechanisms. (Only Kerberos v5 is supported as a GSS-API
When responding, sidentd assumes that the Kerberos service of the
requester is either ident.system (Kerberos v4) or ident/system
(GSS-API), where system is fully qualified for GSS-API but not for
Kerberos v4. The protocol requires that the identity chosen be based
entirely on the incoming connection, since otherwise S/Ident could be
used to steal tickets. This means that the requester must have an
appropriate srvtab or keytab for the DNS hostname corresponding to the
IP address it uses to connect to the responder. It also means that
sidentd depends on DNS resolution to find the appropriate service
ticket to use.
The responder should be started by ientd or some equivalent program
such as tcpserver or xinetd. It expects standard input to be connected
to the open network socket to the requester.
If the file .nosident exists in the user’s home directory, an error is
returned to the requester instead of any authentication information.
Normally, sidentd returns both the user’s authenticated identity and
their local Unix username to the requester along with the SASL
authentication information, but requires some form of SASL
authentication. See the -T flag if you want to allow normal Ident
protocol queries as well.
You can point sidentd at a different kernel image and kmem device by
passing it the kernel and kmem arguments. This is generally only
useful for debugging.
-d Enable additional debugging code. This is for testing only and
should not be enabled on any production server, as it breaks the
protocol and may leak information that should not be available to
-e Always return "UNKNOWN-ERROR" instead of the "NO-USER" or
"INVALID-PORT" errors to minimize the amount of information that a
remote requester could obtain.
-l Tells sidentd to use syslog(3) to report information about queries
it responds to. By default, sidentd does not log.
-n Instead of returning local Unix usernames, return the user’s UID
instead. This doesn’t change the information exchanged via SASL,
just the additional Ident protocol information that is also
supplied, and therefore is mostly useful in combination with the -T
-v Enables verbose output. This logs a great deal of additional trace
information about what the responder is doing to syslog(3) at the
debug log level.
-C Enables port checking. By default, this rejects any responder
ports (ports on the local system) that are under 1024 or equal to
6000 (the standard X port). The check can be modified in the
S/Ident source code by editing responder/identd.h.
Using this feature is highly recommended, as it limits the ability
of a remote system to get information about what user is running
various servers on your system. Ideally, the check should be
modified to exclude any port on your system that’s running a
-M Instructs the sidentd responder to disable mutual authentication in
its response. This signals the requester that it does not need to
do whatever mutual authentication procedure is specified by the
type of authentication being used.
-N Disable the check for a .nosident file in the user’s home directory
and respond as normal for all users.
-T Normally, sidentd requires that the requester negotiate some form
of SASL authentication. With this flag, sidentd will also respond
to normal Ident protocol requests as well (allowing it to serve as
a replacement for a stock identd server).
-V Display the version number of sidentd and then exit.
sidentd should be run by inetd or some equivalent service. The
inetd.conf configuration line should look something like:
ident stream tcp nowait root /usr/local/sbin/sidentd sidentd -l -C
This assumes that there’s an entry in /etc/services for the "ident"
service. The recommended /etc/services line is:
auth 113/tcp authentication tap ident
See inetd.conf(5) and services(5) for more information.
If you are supporting Kerberos v4 or GSS-API authentication, the
responder must run as root in order to be able to read the ticket
caches of users. If you are using TCP wrappers (highly recommended),
the inetd.conf invocation should instead be "/usr/sbin/tcpd
/usr/local/sbin/sidentd", replacing "/usr/sbin/tcpd" with your path to
The first place that sidentd will look for a user’s Kerberos v4
ticket (where %d is replaced by the user’s UID). If this ticket
isn’t present or isn’t valid, it will scan all of /tmp for files
beginning with "tkt", owned by the correct user, and containing a
valid ticket and will answer the S/Ident query with the first such
file that it finds.
The file name pattern that sidentd will use to look for a user’s
Kerberos v5 tickets for GSS-API authentication. As with Kerberos
v4 tickets, the file must be owned by the correct user and have
appropriate permissions and the first such matching file will be
used to answer requests.
The S/Ident protocol implemented by this package is inherently
vulnerable to an active man-in-the-middle attack. If an attacker can
interpose themselves into a network connection initiated by a victim
and both impersonate that victim and selectively control which of their
packets reach a server using S/Ident, the attacker can make use of the
victim’s authentication credentials. The attacker cannot initiate the
session, only hijack an existing authenticated session.
Because of this, you should very carefully analyze the security
requirements of any service for which you’re considering deploying
S/Ident authentication. Due to the requirements of the attack, S/Ident
may still be appropriate for very light authentication or in secure
network environments, but should not be used for general authentication
on untrusted networks.
Because S/Ident does a callback, it is vulnerable to a wide variety of
problems that in-band authentication is not. For example, suppose that
one system is doing NAT for several other systems. If one of the
systems behind NAT initiates a network connection, the S/Ident callback
will go back to the NAT gateway rather than the actual client machine
and authentication won’t be possible. The S/Ident protocol also
requires that remote systems be able to connect back to client systems
on the ident port, which is frequently blocked because it can leak
information to remote systems. S/Ident therefore only really works
well in a network environment where there are no firewalls or NAT
devices separating requester and responder.
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 have
done a setuid(3) call.
The handling of fatal errors could be better.
The reliance on DNS reverse name resolution to determine the
appropriate service ticket to use means that it may be possible to
steal S/Ident service tickets with DNS spoofing, although using the
stolen tickets is tricky and requires carefully chosing client ports.
Some of this danger can be reduced by restricting S/Ident responses to
only systems in the local domain or on the organization network. It’s
probably easier to just try the active man-in-the-middle attack
sident(3), inetd.conf(5), services(5), inetd(8), tcpd(8).
The S/Ident protocol is described in draft-morgan-ident-ext-04.txt,
included in the S/Ident source. This is an expired Internet Draft that
was never published as an RFC.
The basic Ident protocol is described in RFC 1413.
The S/Ident web page at <http://www.eyrie.org/~eagle/software/sident/>
will have the current version of sidentd and the libsident requester
Originally written by Booker Bense <email@example.com> based on the
S/Ident protocol proposed by Robert Morgan <firstname.lastname@example.org>. GSS-
API support added by Russ Allbery <email@example.com>, who currently
maintains this package.
The code is based on the pidentd/libident code from Peter Eriksson
<firstname.lastname@example.org> with the SASL-like kerberos exchange based on code
from CMU’s imapd-1.4 release.
COPYRIGHT AND LICENSE
Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Board of
Trustees, Leland Stanford Jr. University.
Portions based on source from Peter Eriksson <email@example.com>
contained in the libident library, released into the public domain.
Portions based on code copyright (c) 1994-2000 Carnegie Mellon
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The name "Carnegie Mellon University" must not be used to endorse or
promote products derived from this software without prior written
permission. For permission or any legal details, please contact
Office of Technology Transfer
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213-3890
(412) 268-4387, fax: (412) 268-7395
4. Redistributions of any form whatsoever must retain the following
"This product includes software developed by Computing Services
at Carnegie Mellon University (http://www.cmu.edu/computing/)."
STANFORD UNIVERSITY AND CARNEGIE MELLON UNIVERSITY DISCLAIM ALL
WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL STANFORD
UNIVERSITY OR CARNEGIE MELLON UNIVERSITY BE LIABLE FOR ANY SPECIAL,
INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.