5. Writing Security Considerations Sections (Security Considerations セクションの執筆)
5. Writing Security Considerations Sections (Security Considerations セクションの執筆)
所与のプロトコルやシステムがあらゆる形態の攻撃に免疫であることが要件というわけではないが, 著者が可能な限り多くの形態を考慮することは依然として必要である. Security Considerations セクションの目的の一部は, どの攻撃が範囲外か, それらに対してどの対抗策を適用できるかを説明することである. さらに, 記述されたプロトコルや技術に対する脅威の種類について明確な記述がなければならない. これは, 実装者や利用者に対して既知または予見可能なすべてのリスクと脅威を記述するという意味での「デュー・デリジェンス」を行う取り組みとしてアプローチされるべきである.
著者は次を記述しなければならない (MUST):
- どの攻撃が範囲外か (そしてなぜか!)
- どの攻撃が範囲内か
- 2.1 プロトコルが脆弱であるもの
- 2.2 プロトコルが防御するもの
少なくとも次の形態の攻撃を考慮しなければならない (MUST): 盗聴, 再生, メッセージ挿入, 削除, 改変, および中間者. 潜在的なサービス拒否攻撃も特定しなければならない (MUST). プロトコルが暗号保護機構を組み込む場合, データのどの部分が保護され, 保護が何であるか (すなわち完全性のみ, 機密性, および/またはエンドポイント認証など) を明確に示すべきである. 暗号保護がどのような攻撃に脆弱かについての示唆も与えるべきである. 秘匿すべきデータ (鍵素材, 乱数シードなど) は明確にラベル付けすべきである.
技術が認証, 特にユーザー・ホスト認証を含む場合, 認証方式のセキュリティを明確に指定しなければならない (MUST). すなわち, 著者はこの認証方式のセキュリティが前提とする仮定を文書化しなければならない (MUST). たとえば UNIX のユーザー名/パスワードログイン方式の場合, 次の趣旨の記述である:
本システムにおける認証のセキュリティは, 最大 8 文字の ASCII パスワードを推測または取得することが困難である範囲でのみ保証される. これらのパスワードは telnet セッションの盗聴または /etc/passwd ファイルの内容を用いて crack プログラムを実行することで取得され得る. 連続する失敗ログイン試行後の切断および連続するパスワードプロンプト間の待機によるオンライン・パスワード推測からの保護は, 攻撃者が我慢できない範囲でのみ有効である.
/etc/passwd ファイルはユーザー名をユーザー ID やグループなどにマッピングするため, ワールドリーダブルでなければならない. この利用を許しつつ crack を困難にするために, ファイルはしばしば /etc/passwd と「シャドウ」パスワードファイルに分割される. シャドウファイルはワールドリーダブルではなく暗号化パスワードを含む. 通常の /etc/passwd ファイルはその位置にダミーパスワードを含む.
単にプロトコルを下位層のセキュリティプロトコル上で実行すべきと述べるだけでは不十分である. システムがセキュリティのために下位層のセキュリティサービスに依存する場合, それらのサービスが提供することが期待される保護を明確に指定しなければならない (MUST). さらに, 結合システムの結果としての性質を指定する必要がある.
注: 一般に IESG は, プロトコル内部または下位層セキュリティプロトコルへの厳密な結合を通じて, 強力な認証を備えない標準化過程のプロトコルを承認しない.
Security Considerations セクションが扱う脅威環境は, 少なくともファイアウォールが配置されていると仮定せずに, 複数の管理境界を越えたグローバルインターネットへの展開を含めなければならない (MUST). そのような考慮がプロトコルにとって範囲外である理由の正当化であってもよい. LAN に適用される脅威だけを議論し, より広い脅威環境を無視することは許容されない. すべての IETF standards-track プロトコルはグローバルインターネットへの展開の可能性があると見なされる. ある環境での技術やプロトコルの利用を抑制する Applicability Statement がある場合もある. それにもかかわらず, より広い展開のセキュリティ上の問題は文書で議論されるべきである.
脅威緩和が展開された後に, そのプロトコルのユーザーまたは運用者に残る残余リスクについて明確な記述がなければならない. そのようなリスクは関連プロトコルの侵害から生じ得る (たとえば鍵管理が侵害されていれば IPsec は無用), 誤実装から, リスク低減に用いるセキュリティ技術の侵害から (たとえば 40 ビット鍵の暗号), またはプロトコル仕様で扱われないリスクから (たとえば下位リンクプロトコルへのサービス拒否攻撃) 生じ得る. 単一システムの侵害がプロトコル全体を侵害する状況では特に注意を要する. たとえば一般にプロトコル設計者はエンドシステムは侵害されないと仮定し物理的攻撃を心配しない. しかし, 単一システムの侵害が広範な侵害につながり得る場合 (認証局など), システムと物理的セキュリティを考慮することが適切である.
RFC に記述されたプロトコルや技術の潜在的な誤用から生じ得るセキュリティ上のリスクについても, ある程度議論がなければならない. それは当該 RFC の Applicability Statementと組み合わせられ得る.