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.