Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!MIT-MULTICS.ARPA!Klensin
From: Klensin@MIT-MULTICS.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: Excelan TCP/IP
Message-ID: <870121090328.084770@MIT-MULTICS.ARPA>
Date: Wed, 21-Jan-87 04:03:00 EST
Article-I.D.: MIT-MULT.870121090328.084770
Posted: Wed Jan 21 04:03:00 1987
Date-Received: Wed, 21-Jan-87 19:45:07 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 41
Approved: info-vax@sri-kl.arpa

Just to close the loop, I spoke to Excelan Tuesday afternoon about
another issue and they mentioned that they had finally tracked the PSU
problem down and were getting a fix (or a patch) out.  "None of the
above".  Difficulty had to do with PSU's having modified the UAF format
in a way that created longer records which, in turn, fouled up Excelan's
testing as to whether or not login was permitted.

For the information of people trying to check out Server FTP and similar
software, one of the sensible ways to implement one of those things (I
don't know what other VMS implementations do, but I've seen analogues on
several other systems) involves running the server code as a highly
privileged process.  When an FTP "login" request comes in, the server
code itself goes off to the UAF (or whatever it is called on the host
system) and verifies that login would be permitted if the user were
logging in (with whatever name, password(s), privileges, times of day,
etc., are needed).  Then it sends or receives the relevant file(s) on
behalf of the user (whatever "on behalf of" means locally).

If there is not a good, vendor/system supplied and supported subroutine
call for "tell me if this combination of user-password-whatever is legal
for login", this approach provides all sorts of opportunities for an FTP
server to not work in some way (accepting the illegitimate or rejecting
the legitimate) when interactive logins (Telnet in this case) work fine.
At least one of the suggestions mentioned above would have caused Telnet
logins to fail also; a characteristic of these TCP/IP FTP server
failures is that the same user ids and passwords work fine with Telnet.

Incidentally, another characteristic of this approach is that generating
"logfail" accounting records and auditing records when an FTP login
attempt fails (and maybe even auditing records when it succeeds) gets a
little dicey.  Excelan does not now do it and has no immediate plans,
having not heard an outcry from anyone but us.  Other Excelan users who
see this as a problem should probably let them know; this is the sort of
non-functional feature that they are [quite reasonably] likely to do
something about only if several people tell them that it is important.

Has anyone ever requested a supported and documented a "please validate
this user/password/..." routine from Digital, and, if so, what was the
response?

   John Klensin, MIT