cam@columbia-pdn (Chris Markle acc_gnsc) (09/09/87)
Folks, 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 here. 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 login anyway: 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 - cam@acc-sb-unix.arpa - (301)290-8100
ron@topaz.rutgers.EDU (Ron Natalie) (09/09/87)
Weell, sorry, but the proper approach is not to allow the user to log in when the password is expired. Having passwords that don't really expire (just require the user to change them when they log in) are of no use whatsoever. Regardless of what the normal session login does, this cruft does not belong in FTP. As one of your customers, I suggest that you take this under advice. -Ron
TS0400@OHSTVMA.BITNET (Bob Dixon) (09/10/87)
As another customer, I agree that FTP has no business worrying about expired
passwords. Unless I misunderstand what is going on.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>