📄 rfc2228.txt
字号:
专门进行保密性保护和信息完整性保护的过程所产生。回应633的正文部分是一些
Telnet协议中规定的字符串,此字符串是由经过base64编码的‘保密‘信息构成,
而此安全信息则由安全机制中专门进行保密性保护的过程所产生。
客户端将解码及校验这些经过编码的回应。而如何处理解码失败或回应的校验
是实现细节问题。回应不必包括行结束码,但某命令行包含了行结束码,则它必须
是Telnet协议中规定的行结束码,而非本地(local)的行结束码。
保护回应只可以在安全数据交换成功之后发出。
回应632也许是包含多行的回应。鉴于此,回应的纯文本部分必须被分成一定
数量的段,每段都要受到保护,然后还要采用 base 64方式编码,目的是为了能放
入包含多行的回应的分开的行中。在纯文本的回应和经过编码的和经过编码的回应
中的行间不需要任何联系。Telnet 协议中规定的行结束码必须出现在经过编码的回
应的纯文本部分,在文本最后对如上的行结束码的使用是可选的。
多行回应的格式必须比[RFC959]的续文中所描述的还要严格。在最后一行之前
的每一行必须由一个回应码紧跟一个连字符“-”,然后接一个回应的base 64 编码
段。
例如,如果纯文本回应是
123-First line
Second line
234 A line beginning with numbers
123 The last line
那么最终的受保护回应可以是下列的任一形式, (由于单行字数限制,某些
例子可能要占去两行。)
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. 数据信道封装
当客户端和服务器端的数据传输(任一方向的传输)受到保护时,必须对数
据实施某些改变和封装,以便接收者能顺利的将传送的文件解码。
当有关被传送文件的代表类型(representation type),文件结构,传输模
式被转变后,发送者必须对其运用所有的保护措施。通过数据通道传送的数据,基
于保护的目的,将被作为字节流对待。
当以认证方式传送文件时,只有此文件的个别数据块被进行认证处理,而不
是整个文件。因而可能会发生如下情况,即使用将非法数据块混入数据流的攻击方
式时,认证却认为数据合法,从而导致接收者无法检测出受到的文件是不可靠的。
为防范此类攻击,使用的安全机制在某些实现细节上应包含防止此类攻击的
机制。附录I的一些GSS-API机制和附录II的Kerberos机制可以用来做这件事。
发送者必须取得输入的字节流,并将其拆分成许多的数据块,而这样的数据
块经过安全机制的某一具体过程编码后,其尺寸不能大于客户端和服务器端当初用
PBSZ商定的缓冲区尺寸。每一个数据块必须经过编码,并且将编码后的数据块与
其长度值一同传送,此长度值由一四字节的无符号整数表示,此四字节以高位优先
的顺序传送。
当到达被传文件的尾部时,发送者必须将一字节值均为零的数据块编码,然
后在此数据传输结束之前将此编码数据块发送给接收者。
接收者将读出如上的四字节长度值,再读取字节数由此长度值指定的一块数
据,然后解码并使用安全机制的某一具体过程对其进行校验,重复如上过程直到它
收到了那个编码之前字节值全为零的数据块。这表明已到了编码字节流的尾部。
任何有关代表类型、文件结构和传输模式的转变将由接收者在如上操作过程
所生成的字节流上进行。
当使用块传输模式时,发送者的缓冲区(用于存储透明文本)尺寸与块的尺寸
无关。
如果当前保护等级与服务器为特殊的文件传输的安全需要而指定的保护等级
不一致,服务器将对 STOR,STOU,RETR, LIST, NLST, 或 APPE 命令返回回应码534。
如果在数据传输阶段,在服务器端的任一数据保护服务功能不能有效发挥作用
的话,服务器将对发自客户端的数据传输命令(无论是STOR, STOU, RETR, LIST,
NLST, 还是 APPE)返回回应码535。
7.可能的策略方面的考虑
由于没有关于客户端和服务器端安全策略制订方面的限制,一下只是一些关于
安全机制应实现的某些功能的荐议。
-- 一旦进行了安全数据交换,服务器应该要求所有的命令都被保护(数据
完整性及保密保护),并且对回应实施保护,其保护等级应与相关命令
相同。这些回应包括指明MIC, CONF, 和ENC执行失败的回应。特别,
要求 AUTH 和 ADAT 命令被保护是没意义的;要求 PROT 和PBSZ 命令
被保护是有意义且有用处的。还有在期望某功能的安全机制实现过程
中,基于互操作性的考虑 CCC命令被定义,但不推荐使用它。
-- 任何条件允许的情况下,客户端都应对 PASS 命令加密。如果服务器知
道加密 功能可用,于是它拒绝接受没有加密的 PASS 命令,这种情
况是合理的。
-- 尽管没有一个有关安全的命令被要求在安全机制中实现,荐议在考虑网
络 站点的策略因素(例如输出控制)及其所能支持的机制的前提下,
尽量提供所有能被实现的命令。
8. 声明的规范
此节在[RFC959]的第5.3 和5.4 节后已有示范,描述的是相同的信息,除了
标准的
FTP命令和回应外。
8.1 FTP协议安全命令及其参数
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
8.2 命令—回应 顺序
安全关联设置
AUTH
234
334
502, 504, 534, 431
500, 501, 421
ADAT
235
335
503, 501, 535
500, 501, 421
数据保护协商命令
PBSZ
200
503
500, 501, 421, 530
PROT
200
504, 536, 503, 534, 431
500, 501, 421, 530
命令通道保护命令
MIC
535, 533
500, 501, 421
CONF
535, 533
500, 501, 421
ENC
535, 533
500, 501, 421
安全性增强的登录命令 (只有新的回应码被列出) USER
232
336
数据信道命令 (只有新的回应码被列出)
STOR
534, 535
STOU
534, 535
RETR
534, 535
LIST
534, 535
NLST
534, 535
APPE
534, 535
除了这些回应码外,任何安全命令可以返回回应码 500,501,502,533,或
421。一旦安全数据交换成功完成,任何 ftp命令都可以返回一个封装在 回应631,
632,或633中的回应码。
9 状态图
本节演示了在一个增强了安全机制的FTP服务器上进行认证和核准的流程。
长方形块的地方显示了客户端必须发出命令那一时刻的状态,菱形块的地方显示了
服务器必须
给出命令回应那一时刻的状态。
,------------------, USER
__\| 未经认证 |_________\
| /| (新的连接) | /|
| `------------------' |
| | |
| | AUTH |
| V |
| / \ |
| 4yz,5yz / \ 234 |
|<--------< >------------->. |
| \ / | |
| \_/ | |
| | | |
| | 334 | |
| V | |
| ,--------------------, | |
| | 需要安全数据 |<--. | |
| `--------------------' | | |
| | | | |
| | ADAT | | |
| V | | |
| / \ | | |
| 4yz,5yz / \ 335 | | |
`<--------< >-----------' | |
\ / | |
\_/ | |
| | |
| 235 | |
V | |
,---------------. | |
,--->| 已被认证 |<--------' | 当客户端和服务器端之间完成
| `---------------' | 认证后,如果完整性保护机制
| | | 可用,则命令必须受到此机制
| | USER | 的保护,当然也可以使用CCC
| | | 命令来取消这种限制。
| |<-------------------'
| V
| / \
| 4yz,5yz / \ 2yz
|<--------< >------------->.
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,---------------. |
| | 需要口令 | |
| `---------------' |
| | |
| | PASS |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
|<--------< >------------->|
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,--------------. |
| |需要账户信息 | |
| `--------------' |
| | |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -