[ On Tuesday, December 12, 2000 at 17:17:38 (-0500), Andrew Brown wrote: ]
> Subject: Re: identd...
>
> >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 don't care if you or anyone else ever uses encrypted identd responses
or not.  And since it makes absolutely no difference to you whether or
not I send encrypted identd responses, *I* will!  In order to identify
the originating user you still have to hand a complete copy of the ident
repsonse to me either way.

Like I think I said before the use of encrypted replies is far more
secure from *my* point of view because it protects me from malicious or
accidental acts by my own users (such as trashing of my logs, etc.).

Note also that an encrypted reply cannot be spoofed either (at least not
without cracking the key).  If you want me to help you track down which
of my users opened a connection to your server you'll have to give me a
copy of the ident response my server generated that corresponds to the
stated connection.  When I decrypt that response I'll immediately know
if it's valid or not.  Now of course you could have captured that reply
in transit and be "replaying" it to me, so it's not a great deal more
secure -- though if I think there's any funny business going on I'll
report the results only to the contact address for the netblock of the
server, or some similarly verifiable authoritative contact responsible
for the server, perhaps via telephone, making it much harder for you to
intercept my results.

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

well, actually, if you read the "Security Considerations" section of
RFC-1413 you'll discover that IDENT was definitely *not* devised as an
authentication scheme, but rather *only* for auditing purposes.  Even
the original RFC-912 and RFC-931 documents purposefully never used the
word "authorise" but rather stuck to using derivations of the words
"identify" and "verify".

Indeed the author's original stated purpose was only to provide his
*identifictation* to an FTP server.  Clearly such a server could (and
normally should) still require that a user further *authenticate* his or
her identity before it *authorises* any activities under that identity.
As the original RFC says, "It is up to the various applications that
will use the server to determine the amount of trust they will place in
the returned information."  Clearly using the returned information only
for auditing purposes is well within this limitation.

It is very important to remember that identification, authentication,
and authorisation are all very separate concepts.  Confusion over these
concepts is what has given IDENT an undeserved bad name.

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

The "token" returned was always expected to be effectively an "opaque"
value.  Note this phrase from RFC 912:  "the system dependent user
identifier of the connection of interest is sent out", and this one too:
"The format of the returned user identifier is completely system
dependent."

In other words the token is only useful within the context of the
originating system to identify the actual real person who might be
responsible for a given connection.  (Of course any system-level
user-identifier is "opaque" in this manner since it is that identifier
in conjunction with some authentication token (eg. a password) which the
real user must know in order to assume a system-level identity.)

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

That's just an implementation "problem" that has been solved in a number
of ways, including through the use of encryption to store all of the
necessary information opaquely in the reply itself.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>