Re: Suggested extension

Peter Eriksson <pen@lysator.liu.se> Tue, 01 December 1992 00:10 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18652; 30 Nov 92 19:10 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18648; 30 Nov 92 19:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21172; 30 Nov 92 19:11 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18638; 30 Nov 92 19:10 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18634; 30 Nov 92 19:10 EST
Received: from lysator.liu.se by CNRI.Reston.VA.US id aa21161; 30 Nov 92 19:10 EST
Received: from robert.lysator.liu.se by lysator.liu.se with SMTP (5.65c8/1.34/Lysator-3.1) id AA27326; Tue, 1 Dec 1992 01:11:04 +0100 (rfc931-sender: pen@robert.lysator.liu.se)
Received: by robert.lysator.liu.se (5.65c8/1.34/Lysator-3.1) id AA04195; Tue, 1 Dec 1992 01:10:52 +0100 (rfc931-sender: pen@robert.lysator.liu.se)
Date: Tue, 01 Dec 1992 01:10:44 -0000
X-Orig-Sender: ident-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Eriksson <pen@lysator.liu.se>
To: James M Galvin <galvin@tis.com>
Cc: ident@CNRI.Reston.VA.US
Subject: Re: Suggested extension
In-Reply-To: Your message of Mon, 30 Nov 92 16:20:03 -0500
Message-Id: <CMM.0.90.0.723168644.pen@robert.lysator.liu.se>

James M Galvin <galvin@tis.com> writes:

> At a minimum, I would expect our Chair to tell us that it is too late to
> consider this suggestion in this version of the document, especially
> since it has already been submitted to the IESG for consideration as a
> proposed standard.  I do not know what his position will be when the
> document comes up for review again, not less than 6 months after its
> first publication.

I know that. On the other hand I want to get as many peoples input on
this extension as possible, or do you want all developement to stop
for 6 months or so? And it would be a bad thing if I invent one way
to do this, and someone else invent another incompatible way...

> In any case, although there are those who would suggest that passive
> eavesdropping is not a principle threat to the Internet, there are many
> more of those who would ask why take the chance?  In other words, if the
> password in the clear, why bother with it in the first place?

This extension is not intended to be used over the internet but rather
one local networks. Of course one could have removed the (optional)
password field and only rely on other methods for validating who
should be allowed to do these kinds of lookups. But I can't really see
the harm to have this field here. If a user can snoop the local
ethernet and catch this password, then he can probably also catch
login passwords and that way do *much* much more harm than he could
ever do by finding out this password (if used). One could also imagine
other ways to validate who should be allowed to do these kinds of
lookups ("secure" port numbers ala "rsh", Kerberos and other stuff)
but they are more or less outside the scope of this protocol (one
could use the password file to send a Kerberos token if Kerberos is
used at a particular site - it's all up to the local administrator).

/Peter




Peter Eriksson                                              pen@lysator.liu.se
Lysator Academic Computer Society                 ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden                I'm still bored. Flame me again.