sidentd - Kerberos S/Ident responder

sidentd [-deilnvCMNTV]

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.

-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 CWUNKNOWN-ERROR instead of the CWNO-USER or CWINVALID-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.

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 CWident 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 CW/usr/sbin/tcpd /usr/local/sbin/sidentd, replacing CW/usr/sbin/tcpd with your path to tcpd.

/tmp/tkt%d

The first place that sidentd will look for a user's Kerberos v4 ticket (where CW%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 CWtkt, 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.

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

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.

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