Chris Markle acc_gnsc (cam@columbia-pdn)
Tue, 8 Sep 87 18:40:17 EDT
I thought I could lay this subject to rest after my last response but
people still seem confused by what we're talking about here.
The average security package for MVS implements facilities to age passwords
and to not allow the user access to the system after his password has
expired UNLESS a new password is also provided; note that the expired password
must still be provided WITH a new password in order to login. These packages
also allow the user to change his/her password for whatever reason. In
addition, a user may exist in multiple "groups", each of which permits the
user different access privileges. These features are part of the security
package and are not a creation of ACC or ACCES/MVS (our software).
Now, given this, all well-behaved IBM subsystems that gather a userid/password
and validate that against the security system, provide a way for the user
to specify an optional new password and group at signon. The new password can
be specified to change your existing password at any time, or to change your
password if the old one has expired. The group can be specified to select a
group from the set of groups in which that user is a member. This list of
well-behaved subsystems is large and includes CICS, IMS, TSO, and NCCF.
In other words, the standard MVS environment supports the sort of thing
we're talking about here; we at ACC are merely trying to integrate our product
into that environment.
Regarding the notion that ACC has proposed an "FTP protocol modification":
1) The current FTP specs suggest that the USER/PASS command arguments are
"that which is required by the SERVER for access to its file system".
The specs do not say that the USER or PASS arguments take any particular
form. In fact, the USER argument is specified as a string of any of the
128 ASCII characters except CR and LF; ditto for the PASS argument. In my
opinion, the argument "oldpass/newpass GROUP(xxx)" does not violate or modify
the FTP spec. I am suggesting (strongly) that this is valid syntax for
a PASS argument, per the spec; whether or not this fits your notion of what a
userid or password "looks like" depends on whether you regularly work on
an MVS system or not.
Regarding the notion that we are creating a Server FTP that will not
interoperate with other Client FTP implementations:
1) Assuming that you are the average user who is only in one group and whose
password is not expired, all you will need to send our server is
"USER chris" and "PASS chris-pswd", just as is done now. Even if you are in
multiple groups, there is a default group associated with each user that
will be in effect if no group is specified. I see no interoperability problem
Regarding specification of new passwords and groups via the SITE command, I
see two problems:
1) Not all FTP Client implementations provide a SITE command, which is
understandable, but worse, not all those non-SITE providers provide a
"quote" facility either.
2) The use of the SITE command to provide new password group information
creates a second, unrelated place where this information must be specified;
the logical, intuitive place is in the USER/PASS command text.
Regarding the notion that people could access the MVS system via Telnet to
change their password if it expired:
1) This doesn't address the need to optionally specify a group name together
with a userid.
2) A site may allow a user to use the MVS system through FTP but not allow the
user access to any subsystem (eg. TSO, CICS, IMS) which would allow him to
change his password. Clearly this sort of user would have limited capabilites,
but it is not hard to envision this sort of environment.
Regarding ignoring the expired password condition and allowing the user to
1) This would not be popular with MVS customers that want to mandate the use
of aged passwords. MVS security auditors are not very keen on making exceptions
for certain security situations.
In conclusion, all ACC is trying to do is to integrate ACCES/MVS into the
MVS environment as a well-behaved software product (from the MVS perspective).
So long as we do this without violating the FTP spec (which I contend we
haven't) and without affecting interoperability with other implementations
(which I contend we don't) we should be free to make our product fit as
nicely and logically into MVS as possible.
Chris Markle - firstname.lastname@example.org - (301)290-8100
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:15 GMT