Multiple 331 password responses in FTP protocol

Chris Markle acc_gnsc (cam@columbia-pdn)
Thu, 3 Sep 87 17:03:48 EDT


ACC distributes an MVS implementation of the Internet protocol suite called

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:


        220 service ready --->

                                <--- USER chris

        331 ok; need password --->

                                <--- PASS chris_pswd (obtained
                                                with Client FTP password

        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

        "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 - - (301)290-8100

PS - Do not try to respond to me at; use
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.

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:15 GMT