>> there's absolutely *no* need for crypto to make identd "secure".  a
>> simple identd could to the following:
>
>I didn't say "secure".  I said that an identd with crypto would "no
>longer be pointless or dangerous."
>
>Maybe strong crypto (depending on how you define it) is not necessary to
>do this from a strict technical point of view, but in the real world
>using an encrypted reply makes a great deal more sense all around.

it makes only slightly more sense than saying "six" each time your
ident server is queried.

>Perhaps you should read the file "why-encrypt.txt" that comes with the
>Pidentd distribution.  It gives a much more detailed outline of why
>encryption is necessary to make identd useful.

it only suffices to say that there is a nice (not "good") way to use
encryption to do ident service.  his four points can be addressed as
follows:

(1) about the remote administrator interpreting his ident logs without
contacting the local admin: the gettimeofday(2) string you pass is
*useless* to the remote administrator.

(2) about remote users gathering valid login names for cracking
purposes: not possible.

(3) about the remote admin lying about the contents of his logs:
serves no purpose, except to indicate to the local admin that the
remote admin is lying.

(4) about network attacks on the ident protocol: only upon examination
of the ident logs *in both places* will this become apparent, and will
be non-recoverable in all cases anyway.

by the way, that file is missing from any recent distributions.

>Obviously identd could always have supported sending encrypted replies
>all along by restricting itself to using an exportable strength
>algorithm, but it didn't, so now I've re-integrated the support again,
>but this time with at least 64-bit DES (if not even something better).

there's still no use for it.

>> i suppose if you want something that leaks less, you could do
>> something with a hash, the time stuff, the actual user, and send that
>> back.
>
>While a secure one-way hash of the unique contents of your local log
>entry is also theoretically all that's necessary, it's more sensible to
>send the entire log entry in strongly encrypted form since your local
>logs might have expired (or even been maliciously destroyed) by the time
>the law comes knocking on your door....  Not to mention but that
>searching for the exact entry again, even with a decently narrow time
>window, is a lot more trouble than it's worth if you've got to re-hash
>the entries to match the reply.

the ident protocol was originally designed as a thin authentication
scheme (cf, the title of the rfc: Authentication Server), however
everyone knows that it's basically *useless* for this now.

it's only use now is to give an opaque token to the remote admin that
they can later hand back to you if they need some sort of information.
if your logs have expired, then you can say "sorry...you took too long
to ask me about that."  it will be their loss, and they will be no
worse off than if you hadn't been running one in the first place.

i have yet to see a court case that *established* a statute of
limitations that implied a time period over which a system admin is
expected to archive his logs, so i don't expect the "law" can
reasonably find themselves put off by your inability to provide logs.
i keep mine only as long as they are interesting to me.  i have a
friend who reads (and deletes) his logs regularly.

searching for the entry requires only the use of the zgrep command
(grep would suffice, but i'm assuming that you roll over your log
files periodically using newsyslog).

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."