📄 rfc2228.txt
字号:
631 base64(protect("123-First line\r\nSecond line\r\n 234 A line
631-base64(protect("123-First line\r\n"))
631-base64(protect("Second line\r\n"))
631-base64(protect(" 234 A line beginning with numbers\r\n"))
631 base64(protect("123 The last line"))
631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
6. Data Channel Encapsulation
When data transfers are protected between the client and server (in
either direction), certain transformations and encapsulations must be
performed so that the recipient can properly decode the transmitted
file.
The sender must apply all protection services after transformations
associated with the representation type, file structure, and transfer
mode have been performed. The data sent over the data channel is,
for the purposes of protection, to be treated as a byte stream.
When performing a data transfer in an authenticated manner, the
authentication checks are performed on individual blocks of the file,
rather than on the file as a whole. Consequently, it is possible for
Horowitz & Lunt Standards Track [Page 14]
RFC 2228 FTP Security Extensions October 1997
insertion attacks to insert blocks into the data stream (i.e.,
replays) that authenticate correctly, but result in a corrupted file
being undetected by the receiver. To guard against such attacks, the
specific security mechanism employed should include mechanisms to
protect against such attacks. Many GSS-API mechanisms usable with
the specification in Appendix I, and the Kerberos mechanism in
Appendix II do so.
The sender must take the input byte stream, and break it up into
blocks such that each block, when encoded using a security mechanism
specific procedure, will be no larger than the buffer size negotiated
by the client with the PBSZ command. Each block must be encoded,
then transmitted with the length of the encoded block prepended as a
four byte unsigned integer, most significant byte first.
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.
The recipient will read the four byte length, read a block of data
that many bytes long, then decode and verify this block with a
security mechanism specific procedure. This must be repeated until a
block encoding a buffer of zero bytes is received. This indicates
the end of the encoded byte stream.
Any transformations associated with the representation type, file
structure, and transfer mode are to be performed by the recipient on
the byte stream resulting from the above process.
When using block transfer mode, the sender's (cleartext) buffer size
is independent of the block size.
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE
command if the current protection level is not at the level dictated
by the server's security requirements for the particular file
transfer.
If any data protection services fail at any time during data transfer
at the server end (including an attempt to send a buffer size greater
than the negotiated maximum), the server will send a 535 reply to the
data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
Horowitz & Lunt Standards Track [Page 15]
RFC 2228 FTP Security Extensions October 1997
7. Potential policy considerations
While there are no restrictions on client and server policy, there
are a few recommendations which an implementation should implement.
- Once a security data exchange takes place, a server should require
all commands be protected (with integrity and/or confidentiality),
and it should protect all replies. Replies should use the same
level of protection as the command which produced them. This
includes replies which indicate failure of the MIC, CONF, and ENC
commands. In particular, it is not meaningful to require that
AUTH and ADAT be protected; it is meaningful and useful to require
that PROT and PBSZ be protected. In particular, the use of CCC is
not recommended, but is defined in the interest of
interoperability between implementations which might desire such
functionality.
- A client should encrypt the PASS command whenever possible. It is
reasonable for the server to refuse to accept a non-encrypted PASS
command if the server knows encryption is available.
- Although no security commands are required to be implemented, it
is recommended that an implementation provide all commands which
can be implemented, given the mechanisms supported and the policy
considerations of the site (export controls, for instance).
8. Declarative specifications
These sections are modelled after sections 5.3 and 5.4 of RFC 959,
which describe the same information, except for the standard FTP
commands and replies.
8.1. FTP Security commands and arguments
AUTH <SP> <mechanism-name> <CRLF>
ADAT <SP> <base64data> <CRLF>
PROT <SP> <prot-code> <CRLF>
PBSZ <SP> <decimal-integer> <CRLF>
MIC <SP> <base64data> <CRLF>
CONF <SP> <base64data> <CRLF>
ENC <SP> <base64data> <CRLF>
<mechanism-name> ::= <string>
<base64data> ::= <string>
; must be formatted as described in section 9
<prot-code> ::= C | S | E | P
<decimal-integer> ::= any decimal integer from 1 to (2^32)-1
Horowitz & Lunt Standards Track [Page 16]
RFC 2228 FTP Security Extensions October 1997
8.2. Command-Reply sequences
Security Association Setup
AUTH
234
334
502, 504, 534, 431
500, 501, 421
ADAT
235
335
503, 501, 535
500, 501, 421
Data protection negotiation commands
PBSZ
200
503
500, 501, 421, 530
PROT
200
504, 536, 503, 534, 431
500, 501, 421, 530
Command channel protection commands
MIC
535, 533
500, 501, 421
CONF
535, 533
500, 501, 421
ENC
535, 533
500, 501, 421
Security-Enhanced login commands (only new replies listed)
USER
232
336
Data channel commands (only new replies listed)
STOR
534, 535
STOU
534, 535
RETR
534, 535
Horowitz & Lunt Standards Track [Page 17]
RFC 2228 FTP Security Extensions October 1997
LIST
534, 535
NLST
534, 535
APPE
534, 535
In addition to these reply codes, any security command can return
500, 501, 502, 533, or 421. Any ftp command can return a reply
code encapsulated in a 631, 632, or 633 reply once a security data
exchange has completed successfully.
Horowitz & Lunt Standards Track [Page 18]
RFC 2228 FTP Security Extensions October 1997
9. State Diagrams
This section includes a state diagram which demonstrates the flow of
authentication and authorization in a security enhanced FTP
implementation. The rectangular blocks show states where the client
must issue a command, and the diamond blocks show states where the
server must issue a response.
,------------------, USER
__\| Unauthenticated |_________\
| /| (new connection) | /|
| `------------------' |
| | |
| | AUTH |
| V |
| / \ |
| 4yz,5yz / \ 234 |
|<--------< >------------->. |
| \ / | |
| \_/ | |
| | | |
| | 334 | |
| V | |
| ,--------------------, | |
| | Need Security Data |<--. | |
| `--------------------' | | |
| | | | |
| | ADAT | | |
| V | | |
| / \ | | |
| 4yz,5yz / \ 335 | | |
`<--------< >-----------' | |
\ / | |
\_/ | |
| | |
| 235 | |
V | |
,---------------. | |
,--->| Authenticated |<--------' | After the client and server
| `---------------' | have completed authenti-
| | | cation, command must be
| | USER | integrity-protected if
| | | integrity is available. The
| |<-------------------' CCC command may be issued to
| V relax this restriction.
Horowitz & Lunt Standards Track [Page 19]
RFC 2228 FTP Security Extensions October 1997
| / \
| 4yz,5yz / \ 2yz
|<--------< >------------->.
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,---------------. |
| | Need Password | |
| `---------------' |
| | |
| | PASS |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
|<--------< >------------->|
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,--------------. |
| | Need Account | |
| `--------------' |
| | |
| | ACCT |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
`<--------< >------------->|
\ / |
\_/ |
| |
| 3yz |
V |
,-------------. |
| Authorized |/________|
| (Logged in) |\
`-------------'
Horowitz & Lunt Standards Track [Page 20]
RFC 2228 FTP Security Extensions October 1997
10. Base 64 Encoding
Base 64 encoding is the same as the Printable Encoding described in
Section 4.3.2.4 of [RFC-1421], except that line breaks must not be
included. This encoding is defined as follows.
Proceeding from left to right, the bit string resulting from the
mechanism specific protection routine is encoded into characters
which are universally representable at all sites, though not
necessarily with the same bit patterns (e.g., although the character
"E" is represented in an ASCII-based system as hexadecimal 45 and as
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -