draft-ietf-cat-ftpsec-09.txt

[der Mouse <[e-mail]>]

I have a few minor comments on draft-ietf-cat-ftpsec-09.txt.

>    CLEAR COMMAND CHANNEL (CCC)
[...]
>       protected control channel messages.  The CCC command itself must
>       be integrity protected.
[...]
>    INTEGRITY PROTECTED COMMAND (MIC) and
>    CONFIDENTIALITY PROTECTED COMMAND (CONF) and
>    PRIVACY PROTECTED COMMAND (ENC)
[...]
>       A server may require that the first command after a successful
>       security data exchange be CCC, and not implement the protection
>       commands at all.  In this case, the server should respond with a
[...]
>       If the server has completed a security data exchange with the
>       client using a mechanism which supports integrity, and requires a
>       CCC command due to policy or implementation limitations, it should

How can the CCC command be integrity protected if the server doesn't
implement at least MIC?

>    If the server is willing to allow the user named by the USER command
>    to log in based on the identity established by the security data
>    exchange, it should respond with reply code 232.

Presumably this refers to the response to the USER command; I think
this should be clarified.

> 6.  Data Channel Encapsulation
[...]
>    When the end of the file is reached, the sender must encode a block
>    of zero bytes, and send this final block to the recipient before
>    closing the data connection.

This appears to be considering only STRU F, MODE S - ie, the case where
EOF is indicated by closing the data channel.  I think it is important
to clarify how the mechanisms of this draft interact with STRU/MODE
combinations that do not involve creating and closing a new data
channel for each file transferred.

Also, this encoding allows data-stream detection of EOF for STRU F,
MODE S transfers, transfers that normally would require closure of the
data connection to indicate EOF.  Does this make it possible to
transfer multiple files over a single data connection when this would
not normally be possible?  Whether or not, I think this should be
explicitly stated.

> 10.  Base 64 Encoding
[...]
>    Case must not be ignored when reading commands and replies containing
>    base 64 encodings.

This could be misread to imply that (for example) "mic" is not a valid
form of the command keyword for the MIC command.

I also note that no registry is defined for authentication mechanism
name strings - presumably this will be handled by the IANA, but I'd
like to see it explicitly stated; in particular, people developing
mechanisms should be able to determine whom to get a registered name
for their mechanisms from.

					der Mouse

			       [e-mail]
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B