Re: [ftpext] HOST back to FTPEXT2 WG for more review

[Paul Ford-Hutchinson <[e-mail]>]

Daniel Stenberg wrote on 22/07/2011 21:43:33:

> ... I think even more strongly than before that it would make more sense 
to 
> have section 3's two alternative versions a and b just be the version B 
as 
> then a "wrongly placed" HOST would always imply a REIN. Nice and simple.
> 

Just to clarify - this is the section that currently reads ...

   Server-FTP processes SHOULD treat a situation where the HOST command
   is issued after the user has been authenticated by using one of the
   following two behaviors:

   a.  Treat the late HOST command as an erroneous sequence of commands
       and return a 503 reply.

   b.  Treat the late HOST command as though a REIN command was sent
       before the HOST command and reset the user-PI to the state that
       existed after the TCP connection was first established and before
       the initial user authentication and then return the appropriate
       reply for the HOST command.


We have to think "why is this being described" and "in which situations is 
it relevant".

So, for "why is this being described" - I think we have 

- For Server processes to code to
- For Client implementations to code to

for "in which situations is it relevant" - We have

 - Servers that want to implement this command
 - Servers that don't want to implement this command but don't want to 
break any clients (this includes servers that don't want to change 
behaviour at all)
 - Clients that want to use the HOST command with servers which support it

For servers implementing HOST, you are correct, servers which implement 
this spec, should behave like (b) - and, if we wish to mandate that 
linkage in the spec (i.e. behaviour (a) is not permitted if the client 
knows the server supports HOST (either by FEAT or a successful HOST during 
the current session)) - feel free to do so.

However, servers which do not implement HOST, will do (a).

Therefore, for client writers, the client needs to be coded to expect the 
behaviour of the server to be (a) or (b) and MUST check the reply to the 
HOST to determine if an implicit REIN has happened.  Therefore (a) and (b) 
should be specified in the doc.

HOWEVER ... We should mandate an explicit REIN
===============================================

Just to mention it one more time in case it got buried in a previous 
comment....

I think that the REIN should be mandated as explicitly required; and a 
second or subsequent HOST should not be valid until the Client and Server 
have successfully completed a REIN/220 exchange.  This is because (for 
example in RFC4217) the REIN command itself may be governed by 'special' 
processing.  It is not specified in this document how such processing 
should, in general terms, be used for the HOST command.

I have been persuaded not to like "Command XXXX" implicitly does "Command 
YYYY".  In fact, I got told off for it during the draft stages of what 
became RFC4217, which is why "AUTH SSL" (bad) and "AUTH TLS" (good) are 
not functionally equivalent.


Paul
-- 

Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU

Tel [phone]  (internal: 37269105)