sidentd(8)

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 soft

ware) 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 proto

col, a modified version of the standard Ident protocol that al

lows for strong authentication of a user using SASL. The proto

col 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 authenti

cation 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 de

pends on DNS resolution to find the appropriate service ticket to

use.

The responder should be started by ientd or some equiva

lent program such as tcpserver or xinetd. It expects standard

input to be connected to the open network socket to the re

quester.

If the file .nosident exists in the user's home directory,

an error is returned to the requester instead of any authentica

tion 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 gen

erally 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 ex

changed via SASL, just the additional Ident protocol information

that is also supplied, and therefore is mostly useful in combina

tion with the -T flag.

-v Enables verbose output. This logs a great deal of ad

ditional 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 modi

fied 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 run

ning a server.

-M Instructs the sidentd responder to disable mutual au

thentication 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 negoti

ate some form of SASL authentication. With this flag, sidentd

will also respond to normal Ident protocol requests as well (al

lowing 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 authentica

tion, the responder must run as root in order to be able to read

the ticket caches of users. If you are using TCP wrappers (high

ly 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 inher

ently vulnerable to an active man-in-the-middle attack. If an

attacker can interpose themselves into a network connection ini

tiated by a victim and both impersonate that victim and selec

tively 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 hi

jack an existing authenticated session.

Because of this, you should very carefully analyze the se

curity 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 authenti

cation 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 provi

sion for returning the "effective user ID." Thus, the UID re

turned 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 possi

ble 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 ac

tive 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/soft

ware/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 <mor

gan@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 ex

change 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 dis

claimer.

2. Redistributions in binary form must reproduce the above

copyright notice, this list of conditions and the following dis

claimer 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 Com

puting Services
at Carnegie Mellon University

(http://www.cmu.edu/computing/)."

STANFORD UNIVERSITY AND CARNEGIE MELLON UNIVERSITY DIS

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

3.6 2005-10-04

SIDENTD(8)