cam@columbia-pdn (Chris Markle acc_gnsc) (09/04/87)
Folks, ACC distributes an MVS implementation of the Internet protocol suite called ACCES/MVS. We are in the process of adding support to interface ACCES to various MVS security packages using the MVS-provided SAF (Security Authorization Facility) interface. SAF allows an application subsystem to use a common interface to the access control facility, be that RACF, ACF2, Top Secret or Alert/MVS (and possibly others). One problem has emerged that I want to present to this group for comments and/or suggestions. Systems like RACF will expire a user's password after a certain period of time; this is quite commonly used at the average MVS site. We coded the changes in the FTP server to detect this (after USER and PASS FTP commands have been issued) and if the password is expired to prompt the Client FTP for a new (second) password. If the Client is 4.3 BSD, it assumes that the second password prompt (331 response) is really a 332 response, prompts the user for an account, and sends an ACCT FTP command in response to our 331 password prompt. It looks something like this: ACCES/MVS UNIX 220 service ready ---> <--- USER chris 331 ok; need password ---> <--- PASS chris_pswd (obtained with Client FTP password prompt) 331 expired; need new password ---> At this point, 4.3 BSD prompts the Unix FTP user for an account and if one is entered in, sends it in an FTP ACCT command. Obviously the 4.3 FTP client is not vigorously checking the reply code; the "need acct" reply code is 332 not 331. By the way, if you send the USER, PASS, and 2nd PASS with the QUOTE command, everything works properly. Now before you tell me to look at the state diagrams in the FTP spec (which show a transition to the ACCT state after receipt of a 3xx response to the PASS command) let me point out that the spec section with state diagrams states: "Here we present state diagrams for a VERY SIMPLE MINDED FTP implementation. Only the FIRST DIGIT of the reply codes is used" (Capitalization is mine) This suggests to me that the spec does not say "implement your FTP using these simple-minded state diagrams" but "here are SAMPLE state diagrams to help you understand the FTP protocol". So --- a couple of questions for you folks to ponder (and hopefully to respond to): 1) Our position is that if the FTP server sends more than one 331 response in a row, this is legitimate and Client FTP implementations should properly handle this. Do you wise folks agree? 2) If you don't agree, what brilliant ideas can you give us on how to do this? (Please don't say that we should accept the ACCT info following the 1st PASS as the 2nd PASS!?!) Please respond to me or to this group; I will summarize at the end. Thanks in advance for your advice in this matter. Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100 PS - Do not try to respond to me at acc-md-unix.arpa; use acc-sb-unix.arpa which will forward to me at acc-md-unix PS - I know this isn't very exciting stuff but it is a real problem that will affect real users at real sites.
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (09/04/87)
UNIX uses the simple minded approach. Only the first digit is checked. (This is for infomration). I think ACCESS/MVS is doing the wrong thing. The reply strings are supposed to be informative only, the client is supposed to be able to make it's decisions based on the numbers alone. The only defined acceptable replies in the spec are 3XX meaning send account, 2XX Success, and 5XX error. Doing anything else is just asking for trouble. The last two digits are there to provide a finer differentiation of the error, but not to change the flow of control. Beyond that conceptual problem, if I understand what is going on here, you're second password string actually changes the password? This is a horrendous security problem and really ought not to be done in FTP. Better to just return an error (EXPIRED PASSWORD) and leave the user to correct the situation through other channels. -Ron
LYNCH@A.ISI.EDU (Dan Lynch) (09/05/87)
From my reading of this topic I could not tel if the password was being changed on a high frequency basis (like hourly) or on a low frequency basis (like monthly). If monthly, then returning an error is probably fine, but if it is hourly (or less) then something has to change so the user does not get completely frustrated. What are the facts? Dan -------
ks@a.cs.okstate.edu (Kurt F. Sauer) (09/07/87)
In article <8709041634.AA11908@topaz.rutgers.edu>, Ron Natalie writes: >Beyond that conceptual problem, if I understand what is going on here, >you're second password string actually changes the password? This is >a horrendous security problem and really ought not to be done in FTP. >Better to just return an error (EXPIRED PASSWORD) and leave the user >to correct the situation through other channels. I absolutely concur. Implementations of FTP were designed to perform file transfers, not the changing of authenticators used in login situations. This leaves one with a situation where subversion of local software (not normally regarded as a trusted implementation) would render distant-end protection useless. I suggest you think this design issue out with a security engineer, and I suspect that the median solution will probably be something like Ron's suggestion above. We would never allow user programs to control foreign host access; this is somewhat akin to doing just that. A couple of guidelines which might be helpful from a more generic stand- point: [PassMgtGuide85] 4.2.2.3 [Password] Change Procedure ...If the change is necesary due to an expired password, the user should be so informed. The user should be pre- sented with a brief summary of the major steps in changing a password, including a caution that the user should ensure that no one else is watching what the user is doing. ... The user should then enter the new password twice so the procedure can verify that the user can con- sistently enter the password correctly. The new password should be obliterated by techniques such as overprinting or terminal screen erasing. ... While it is true that many (tho not all!) UNIX implementations include a passwd program that gives instructions, some do. The more important con- sideration is immediate: Few FTP implementations here (none?) keep the value supplied for ACCT from being displayed. Further, it's true that several implementations of FTP don't even protect the PASS value when it's entered (unlike 4.3bsd UNIX implementations)! 4.3.2 [Password] Entry ... It is recommended that the system not echo pass- words that users type in. When the system cannot pre- vent a password from being echoed ..., it is recommen- ded that a random overprint mask be printed before or after the password is entered, as appropriate, to con- ceal the typed password. The complete password as entered by the user should be an exact match, character for character, with the user's current password. And, of course, using the ACCT feature won't allow for retyping the password for correctness, which is a big "lose." Think this out again and let us know what you decide. Kurt F. Sauer Tulsa, OK ---------- References: [PassMgtGuide85] National Computer Security Center, _D_e_p_a_r_t_m_e_n_t_ _o_f_ _D_e_f_e_n_s_e _P_a_s_s_w_o_r_d_ _M_a_n_a_g_e_m_e_n_t_ _G_u_i_d_e_l_i_n_e, Report CSC-STD-002-85 (Fort George G. Meade, MD: NCSC), April 1985.
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/10/87)
As one of the perpetrators of FTP--and, indeed, one of the primary perpetrators of the PASS command: cf. RFC 491--it might be appropriate for me to assure you that I do understand the necessity of periodic password changes. I even understood it in 1972/3, when I was perpetrating. However, I neither understand nor stipulate that the abstract necessity for accomplishing the action dictates a concrete necessity for so doing under the explicit cognizance of FTP, to this day. N.B., I said "explicit"; that is, if a given Server wants to make the function available via FTP and can come up with a syntax such that the User FTP implementations "all" think it's just a normal password being sent through them (say, use "\\\" as the separator, or some single character that isn't licit in the Server's passwords, or any trick that avoids there being a space in the line, since User FTPs shouldn't boggle at the length of a password but might well be doing next-non-blank parsing), there doesn't seem to be a (protocol) problem. Unless, of course, too many User FTPs don't implement my conviction that they can't possibly assume they know the length of a password, but that's a different problem.... Actually, I could side with an argument which held that User FTPs "should" be sending along everything input to them from whatever their local indications that a PASS comand is wanted are through to whatever their local indications that the command/line is ended are, if anybody wants to raise it. But I think the issue which should dominate is that a Server is within its "rights" to play games with the interpretations of given variables' internal syntax as long as the variables are sent correctly according to the protocol's gross syntax, so the above-sketched trick should work regardless-- provided I'm not overlooking any contrary-to-our-design-intent glitches which might have been introduced into the spec with regard to limitations on the length of the password string. If I have to, I'll dig out the spec from my piling system later; for now, though, I think I'll settle for casting my metaphorical vote in favor of having the ACCESS/MVS (or however they spell it) Server FTP simply treat the outdated password as the incorrect password that it in essence is and include text in the appropriate error message explaining what syntax they want used in a subsequent PASS command's argument field to make things right. After all, we wanted to make FTP "usable by automata" at the outset, but we never were so fanatic about it that we explicitly banned touching by human hands, as I recall. cheers, map -------