[ On Wednesday, July 13, 2005 at 12:10:23 (-0400), Marc Sherman wrote: ]
> Subject: Re: [exim] MessageLabs 554 SMTP synchronisation error
>
> The relationship is that ident and well synched clocks are both tools
> that can be used to link events on multiple servers. Ident can be used
> by having usernames from server A appear in the logs on server B.
Actually the point of IDENT is to provide a server with additional (and
possibly private) information about the connection to be logged along
with the transaction so that if the server administrator ever comes back
to the client administrator and asks for more details about what human
person might be responsible for the connection then the client admin can
ask for a copy of the IDENT information back again so it can be used to
correlate local logs with the event the server admin is asking about.
Indeed it is often considered an invasion of privacy to send local
user-ID information via IDENT to the server to be logged, especially
when that information is only supposed to be used in some kind of
abnormal situation.
As a result of these considerations many of us who do still provide
IDENT services will only ever use the encrypted variety. For example I
run "identd -C" on my system called "building" and my mail server makes
IDENT queries:
$ telnet mail 25
220-most.weird.com Smail-3.2.0.121-Pre (#1 2005-Jul-13)
220-ready at Wed, 13 Jul 2005 14:09:55 -0400 (EDT)
220 ESMTP supported
HELO building
250 most.weird.com Hello building ([QpNNMiE+Eq+T4IAvs/SxrQ1qnw4HMksMXG1tstbkm8AqGk4VhgzD4n9ldoyX07i8zStf6dRhOQ/fBAswFkDt/A==]@building.weird.com from address [204.92.254.24]).
Note that big long string of gobbledygook in the square brackets before
the '@' in the comment text of the 250 reply to my HELO.
It decrypts as follows:
# idecrypt
[QpNNMiE+Eq+T4IAvs/SxrQ1qnw4HMksMXG1tstbkm8AqGk4VhgzD4n9ldoyX07i8zStf6dRhOQ/fBAswFkDt/A==]
[Wed Jul 13 14:09:55 2005 UID=1000 GID=1000 PID=27625 CMD=telnet 204.92.254.24.57552->204.92.254.2.25]
(Note that's extended from what the standard identd's '-C' format, but
that's the level of detail I wanted my version to provide.)
Now the encryption I happen to use is only standard crypt(2), so 56-bit
DES, and so someone with a few IDENT replies, and especially with the
example above showing what it should look like, could soon decode my
key, but note there's an easy mechanism in the identd and idecrypt
programs to provide new keys on a regular basis, which would somewhat
increase the difficulty, perhaps beyond the utility of the information
that can be gained from the effort.
Note also this from the identd(8) manual page:
SECURITY CONSIDERATIONS
May leak information generally considered "private" unless
the -e flag or either the -L or -C flags are used.
The protocol is unprotected and is vulnerable to man-in-
the-middle attacks.
Make of that what you will, but note that with encryption the attacker
really would have to break my _current_ key before they could forge my
IDENT replies.
> Well-synched clocks can be used by having log entries from both servers
> show the same time stamps.
Note the timestamp is included in my IDENT reply so it really doesn't
matter if the server's clocks are in sync with the client clocks since
the clients original timestamp is available on demand. That's not
saying one shouldn't keep one's system clocks in sync with network time,
but rather just that should such synchronisation fail there's still a
chance of correlating logs between foreign systems if IDENT is used.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
