Provided by: sidentd_3.5-3_i386 bug

NAME

       sidentd - Kerberos S/Ident responder

SYNOPSIS

       sidentd [-deilnvCMNTV]

DESCRIPTION

       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
       mechanism.)

       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.

OPTIONS

       -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
           requesters.

       -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
           flag.

       -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
           server.

       -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.

INSTALLATION

       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
       tcpd.

FILES

       /tmp/tkt%d
           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.

       /tmp/krb5cc_%s
           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.

WARNING

       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.

CAVEATS

       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.

BUGS

       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
       mentioned above.

SEE ALSO

       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
       library.

AUTHORS

       Originally written by Booker Bense <bbense@stanford.edu> based on the
       S/Ident protocol proposed by Robert Morgan <morgan@stanford.edu>.  GSS-
       API support added by Russ Allbery <rra@stanford.edu>, who currently
       maintains this package.

       The code is based on the pidentd/libident code from Peter Eriksson
       <pen@lysator.liu.se> 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 <pen@lysator.liu.se>
       contained in the libident library, released into the public domain.

       Portions based on code copyright (c) 1994-2000 Carnegie Mellon
       University.

       Redistribution and use in source and binary forms, with or without
       modification, are permitted provided that the following conditions are
       met:

       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
              tech-transfer@andrew.cmu.edu

       4. Redistributions of any form whatsoever must retain the following
          acknowledgment:

              "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.