Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!DDN2.UUCP!NS-DDN
From: NS-DDN@DDN2.UUCP.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Password Security for the UCLA ACP
Message-ID: <8701111430.AA00591@ucbvax.Berkeley.EDU>
Date: Sun, 11-Jan-87 08:35:00 EST
Article-I.D.: ucbvax.8701111430.AA00591
Posted: Sun Jan 11 08:35:00 1987
Date-Received: Sun, 11-Jan-87 12:38:28 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 39
Approved: tcp-ip@sri-nic.arpa



I heard of a fascinating alternative to standard access validation which may be
right up your alley. Instead of a password, the user is presented with five
random numbers and asked to compute the result using his secret access
validation algorithm. Traces and taps will only show a plaintext response to
the specific access request. The algorithm is not apparent unless many accesses
are traced and analyzed. A good algorithm mechanism would support conditionals;
e.g., If 3rd number is odd, then result is 4th number minus 5th number, else
result is 1st number times 1st number plus 2nd number. While this is complex,
it avoids the overhead of DES (I shudder to think what that would do to the
ACP's resource consumption).
 
The ICT ACACCESS module (invoked via the PACCESS macro) is not designed
to work this way since it assumes it is merely interfacing to an MVS security
package which is password-driven. Worse still, the commutator is not party to
TCP and VTAM sessions; hence, it cannot solicit the userid, prompt for the
result, and capture the result. Consequently, implementation of this idea
cannot be easily be centralized within the PACCESS service.
 
There is no standard routine for solicitation of the userid/password. I would
suggest adding an A-service to provide a common solicitor routine which would
be knowledgeable of both TELNET and VTAM connections to deal with each
appropriately. Then modify the modules which obtain this information to use the
A-service instead.
 
Another problem with this would be the creation of an access table containing
each user's id, privileges, and algorithm. This should be part of ACACCESS.
PACCESS and ACACCESS would have to modified to expect six numbers (the prompted
five and the user's response) instead of the existing eight-byte password.
 
Be very careful with enhancements to the commutator! While this is not a
trivial enhancement, I believe it would serve your needs (and maybe ours, as
well).
 
Best regards,
 
Dave Craig
Network Solutions, Inc.