5. Writing Security Considerations Sections (撰写安全考量章节)
5. Writing Security Considerations Sections (撰写安全考量章节)
并不要求任何给定协议或系统对所有形式的攻击都免疫, 但作者仍有必要尽可能考虑多种形式. Security Considerations 章节的部分目的在于说明哪些攻击超出范围以及可以应用哪些对策来防御它们. 此外, 应对所描述协议或技术面临的威胁种类有清晰描述. 这应作为 "尽职调查 (due diligence)" 的努力, 向潜在实现者与用户描述所有已知或可预见的风险与威胁.
作者必须描述:
- 哪些攻击超出范围 (以及原因!)
- 哪些攻击在范围之内
- 2.1 且协议易受该攻击影响
- 2.2 且协议可防护该攻击
至少必须考虑以下攻击形式: 窃听, 重放, 消息插入, 删除, 篡改以及中间人. 还必须识别潜在的拒绝服务攻击. 若协议包含密码保护机制, 应清楚标明数据的哪些部分受到保护以及保护是什么 (即, 仅完整性, 机密性, 和/或端点认证等). 还应说明密码保护易受哪些攻击. 应当保密的数据 (密钥材料, 随机种子等) 应清楚标注.
若技术涉及认证, 尤其是用户-主机认证, 认证方法的安全性必须清楚说明. 也就是说, 作者必须记录该认证方法的安全性所依赖的假设. 例如, 对于 UNIX 用户名/口令登录方法, 应作如下陈述:
系统中的认证仅在其难以猜测或获得最长 8 个字符的 ASCII 口令的范围内是安全的. 这些口令可以通过嗅探 telnet 会话或使用 /etc/passwd 文件内容运行 crack 程序获得. 试图通过 (1) 在若干次不成功登录尝试后断开连接以及 (2) 在连续口令提示之间等待来防护在线口令猜测, 仅在攻击者缺乏耐心时有效.
由于 /etc/passwd 文件将用户名映射到用户 id, 组等, 它必须全局可读. 为允许此用法同时使运行 crack 更困难, 文件常常拆分为 /etc/passwd 与 shadow 口令文件. shadow 文件非全局可读并包含加密口令. 常规 /etc/passwd 文件在其位置包含哑口令.
仅仅声明协议应在某较低层安全协议之上运行是不够的. 若系统依赖较低层安全服务来实现安全, 必须清楚说明预期这些服务提供的保护. 此外, 必须说明组合系统的结果属性.
注意: 一般而言, IESG 不会批准不提供强认证的 standards track (标准轨道) 协议, 无论强认证是协议内置还是通过与较低层安全协议的紧密绑定实现.
Security Considerations 章节所针对的威胁环境至少必须包括在跨越多个管理边界的全球互联网上的部署, 且不得假定防火墙已就位, 即使只是为了论证为何此类考虑对协议而言超出范围. 仅讨论适用于 LAN 的威胁而忽略更广威胁环境是不可接受的. 所有 IETF standards-track 协议都被认为可能在全球互联网上部署. 在某些情况下, 可能有 Applicability Statement (适用性声明) 劝阻在某环境中使用某技术或协议. 尽管如此, 仍应在文档中讨论更广部署的安全问题.
应对在威胁缓解部署之后用户或操作员面临的残余风险有清晰描述. 此类风险可能来自相关协议的泄露 (例如, 若密钥管理已泄露则 IPsec 无用), 来自错误实现, 来自用于风险降低的安全技术被攻破 (例如 40 位密钥的密码), 或者可能存在协议规范未处理的风险 (例如对底层链路协议的拒绝服务攻击). 在单个系统被攻破会危及整个协议的情况下应特别小心. 例如, 一般而言协议设计者假定端系统不可侵犯且不担心物理攻击. 然而, 在单个系统 (如证书颁发机构) 被攻破可能导致广泛泄露的情况下, 考虑系统与物理安全是适当的.
还应讨论因对所描述 RFC 中的协议或技术可能误用而产生的潜在安全风险. 这可与该 RFC 的 Applicability Statement 结合.