FTP SECURITY..........

File Transfer Protocol - FTP Security

At the very high stage, the File Transfer Protocol, FTP security extensions try to offer an abstract method for authorizing connections, and privacy protecting instructions, replies, and data transfers. In the view of FTP security, validation is the basis of a client’s/server’s identity in a secure system, usually using cryptographic actions. The basic File Transfer Protocol does not have a assumption of validation. Without the security extensions, validation of the client, as this phrase is usually understood, never happens. File Transfer Protocol, FTP authorization is accomplished with a password passed on the network in the clear as the argument to the PASS command. As the user named in the USER command, the owner of this password is believed to be authoritative to transfer files, but the identity of the user is never securely recognized. A FTP security communication begins with a client telling the server what security system it wants to use. The server will either deny this system, accept this system, or in the case of a server which does not put into action the security extensions, reject the command fully. The client may try multiple security systems until it requests one which the server accepts. This allows a simple form of arbitration to take place. The server’s response will specify if the client needs to respond with additional data for the security system to understand. If nothing is needed, that means system is one, where the provided password is to be interpreted in a different way, with a token or one-time password system. If the server requests additional security information, then the client and server will enter into a secured data exchange. An ADAT command containing the first block of security data will be send by the client. The server’s respond will specify if the data exchange is complete, if there was an error, or if more data is needed. The server’s respond can optionally contain security data for the client to understand. If more data is needed, the client will send another ADAT command containing the next block of data, and await the server’s response. This can continue as many times as needed. Once this exchange finishes, the server and client have established a security association. This association may include confirmation and keying information for privacy, depending on the system in use. The phrase “security data” here is carefully selected. The reason of the security data exchange is to create a security association, which may not include any validation, between the server and the client as explained above. If a FTP server has an RSA key pair but the client doesn’t, then the client can authenticate the server, but the server can’t authenticate the client. Once a security association is recognized, validation may be used instead of the standard exchange for authorizing a user to connect to the server. A username is always needed to identify the identity to be used on the server. In order to stop an attacker from using commands on the control stream, then the client and server must exercise integrity protection on the control stream, unless it first transmits a CCC command to turn off this necessity. The CCC command and its response must be passed on with integrity protection. Commands and responses may be passed on without integrity only if no security association is recognized, the negotiated security association does not support integrity, or the CCC command has succeeded. Once the server and client have negotiated with the PBSZ command an acceptable buffer size for encapsulating protected data over the data channel, the security system may also be applied to protect data channel transfers. Policy is not specified by this document. In particular, server and client implementations may choose to apply restrictions on what operations can be carried out depending on the existed security association. For example, a server may require that a user authorize via a security system rather than using a password, want that the user provide a single-time password from a token, need at least integrity protection on the command channel, or require that definite files only be transmitted encrypted. An anonymous ftp user might refuse to do file transfers without integrity protection in order to assure the legitimacy of files downloaded. No exact set of functionality is needed, except as dependencies explained in the next section. This indicates that none of validation or confidentiality is needed of an execution, although a system is not of any use which doesn’t do any of these things. For example, it is admirable for a system to apply only integrity protection, one-way validation/encryption, encryption without any integrity protection, or any other subset of functionality if guidelines or technical considerations make this desirable.