3. StartTLS 操作
[RFC4511] の 4.14 節で定義される Start Transport Layer Security (StartTLS) 操作は, LDAP セッションにおいて TLS [RFC4346] を確立する機能を提供する.
LDAP で TLS プロトコルを用いる目的は, データの機密性と完全性を確保し, 任意で認証を提供することである. TLS はこれらの機能を明示的に提供するが, TLS の認証サービスは SASL EXTERNAL 認証方式 (5.2.3 節参照) と組み合わせた場合にのみ LDAP で利用でき, しかも SASL EXTERNAL 実装が TLS の資格情報を利用することを選択した場合に限られる.
3.1. TLS 確立手順
本節は, TLS の確立のためにクライアントとサーバーが従わなければならない全体的な手順を記述する. これらの手順は, 結果として得られるセキュリティレベルの発見やクライアントの認可アイデンティティの主張を含む, TLS 層の種々の側面を考慮に入れている.
3.1.1. StartTLS 要求の順序付け
クライアントは, LDAP セッションを確立した後いつでも StartTLS 拡張要求を送信してよいが, 次の場合を除く:
- そのセッションで現在 TLS が確立されている場合,
- そのセッションで多段階の SASL ネゴシエーションが進行中である場合,
- そのセッションで以前に発行された操作要求に対する未処理の応答がある場合.
[RFC4511] の 4.14.1 節に記述されているとおり, これらの要件のいずれかに (検出可能な形で) 違反すると, operationsError resultCode が返される.
クライアントの実装者は, 相互運用性の問題を防ぐため, これらの操作順序付け要件を厳密に守るよう保証すべきである. 運用経験によれば, これらの要件に違反すると相互運用性の問題が生じる. サーバーのハードウェア速度やネットワーク遅延といった要因のために, サーバーがこれらの要件の一部の違反を検出できない競合状態が存在するからである.
StartTLS 操作要求を送信する前に Bind 操作 (第 5 節) を既に行っているか否かについて一般的な要件はない. ただし, クライアントが Bind 操作と StartTLS 操作の両方を行う意図がある場合は, 先に StartTLS 操作を行うことが望ましい (SHOULD). そうすれば, Bind 要求と応答のメッセージが StartTLS 操作によって確立されたデータセキュリティサービスによって保護されるからである.
3.1.2. クライアント証明書
LDAP サーバーが TLS ネゴシエーション中にクライアントへユーザー証明書の提示を要求または強要し, クライアントが適切なユーザー証明書 (例えば検証可能なもの) を提示しない場合, サーバーはローカルのセキュリティポリシーを用いて TLS ネゴシエーションを正常に完了させるか否かを決定してよい.
適切な証明書を提示したクライアントが, 引き続き SASL EXTERNAL 認証方式 (5.2.3 節) を用いて Bind 操作を行う場合, 証明書内の情報をサーバーがクライアントの識別と認証に用いることがある.
3.1.3. サーバーアイデンティティの検査
中間者攻撃 (man-in-the-middle attack) を防ぐため, クライアントは (サーバーの Certificate メッセージに提示される) サーバーのアイデンティティを検証しなければならない (MUST). 本節では, クライアントが認識しているサーバーのアイデンティティ (通常はトランスポート接続を確立するために用いたアイデンティティ) を "参照アイデンティティ" と呼ぶ.
クライアントは参照アイデンティティの種類 (例えば DNS 名や IP アドレス) を判定し, 一致が得られるまで, 参照アイデンティティと対応する種類の各 subjectAltName 値とを比較する. 一致が得られれば, サーバーのアイデンティティは検証され, サーバーアイデンティティ検査は完了する. subjectAltName の種類ごとに比較方法は異なる. 3.1.3.1 項から 3.1.3.3 項で, 各種類の subjectAltName 値の比較方法を説明する.
クライアントは, 比較を行う前に参照アイデンティティを別の種類にマッピングしてよい. マッピングは, 参照アイデンティティをマッピング可能なすべての subjectAltName の種類に対して行ってよい. ただし, 参照アイデンティティは, そのマッピングが本質的に安全である場合 (例えば URI から DNS 名を取り出して dNSName 型の subjectAltName と比較する場合), または安全な方法で行われる場合 (例えば DNSSEC を用いる, あるいはユーザーや管理者が構成したホスト名とアドレスの相互参照表を用いる場合) の種類にのみマッピングすべきである.
サーバーのアイデンティティは, 参照アイデンティティを, サーバー証明書の subjectName フィールドの葉の Relative Distinguished Name (RDN) にある Common Name (CN) [RFC4519] 値と比較することによっても検証できる. この比較は, ワイルドカード照合を認めないことを除き, 後述の 3.1.3.1 項の DNS 名の比較規則を用いて行う. Common Name 値の使用は既存の慣行であるが非推奨であり, 認証局は代わりに subjectAltName 値を提供することが推奨される. TLS 実装は証明書内の DN を X.500 その他の慣習に従って表現しうる点に留意されたい. 例えば, 一部の X.500 実装は, LDAP の右から左への慣習ではなく, 左から右へ (最上位から最下位へ) の慣習で DN 内の RDN を並べる.
サーバーアイデンティティ検査が失敗した場合, 対話型クライアントは, ユーザーに通知する (この場合, クライアントはユーザーに LDAP セッションを継続する機会を与えてもよい) か, トランスポート接続を閉じてサーバーのアイデンティティに疑義があることを示すことが望ましい (SHOULD). 自動化されたクライアントは, トランスポート接続を閉じたうえで, サーバーのアイデンティティに疑義があることを示すエラーを返すか記録する, あるいはその両方を行うことが望ましい (SHOULD).
本節に記述されたサーバーアイデンティティ検査に加えて, クライアントは, サーバーが提供を要求されたサービスを提供する権限を持つことを確認するためのさらなる検査を行う用意があるべきである. この判断にあたり, クライアントはローカルのポリシー情報を利用する必要があるかもしれない.
3.1.3.1. DNS 名の比較
参照アイデンティティが国際化ドメイン名である場合, 準拠実装は, dNSName 型の subjectAltName 値と比較する前に, RFC 3490 [RFC3490] の 4 節に規定された ASCII Compatible Encoding (ACE) 形式へ変換しなければならない (MUST). 具体的には, 準拠実装は RFC 3490 の 4 節に規定された変換操作を次のように行わなければならない (MUST):
* 手順 1 では, ドメイン名を "stored string" と見なすものとする (SHALL).
* 手順 3 では, "UseSTD3ASCIIRules" というフラグを設定する.
* 手順 4 では, 各ラベルを "ToASCII" 操作で処理する.
* 手順 5 では, すべてのラベル区切り文字を U+002E (ピリオド) に変更する.
"to-ASCII" 変換を行った後, DNS ラベルと名前は, RFC 3490 の 3 節に規定された規則に従って等価性を比較しなければならない (MUST).
'*' (ASCII 42) のワイルドカード文字は, dNSName 型の subjectAltName 値において, その値の最も左 (最下位) の DNS ラベルとしてのみ認められる. このワイルドカードは, サーバー名の最も左の DNS ラベルに一致する. すなわち, subject の *.example.com はサーバー名 a.example.com と b.example.com に一致するが, example.com や a.b.example.com には一致しない.
3.1.3.2. IP アドレスの比較
参照アイデンティティが IP アドレスである場合, アイデンティティは "ネットワークバイトオーダー" のオクテット文字列表現 [RFC791][RFC2460] に変換しなければならない (MUST). IP バージョン 4 では, RFC 791 に規定されているとおり, オクテット文字列はちょうど 4 オクテットを含む. IP バージョン 6 では, RFC 2460 に規定されているとおり, オクテット文字列はちょうど 16 オクテットを含む. このオクテット文字列を, iPAddress 型の subjectAltName 値と比較する. 参照アイデンティティのオクテット文字列と値のオクテット文字列が同一であれば一致となる.
3.1.3.3. その他の subjectName 型の比較
クライアント実装は, 他の文書に記述された他の型の subjectAltName 値との照合をサポートしてもよい (MAY).
3.1.4. 結果として得られるセキュリティレベルの発見
LDAP セッションにおいて TLS 層が確立された後, 両当事者は, ローカルポリシーと達成されたセキュリティレベルに基づき, 継続するか否かをそれぞれ独立に決定するものとする. いずれかの当事者が, 継続するにはセキュリティレベルが不十分であると判断した場合, TLS の (再) ネゴシエーションが完了した直後に TLS 層を除去することが望ましい (SHOULD) ([RFC4511] の 4.14.3 節, および後述の 3.2 節参照). 実装はいつでもセキュリティレベルを再評価してよく, 不十分と判明した場合は TLS 層を除去すべきである.
3.1.5. サーバー機能情報の更新
LDAP セッションにおいて TLS 層が確立された後, クライアントは, TLS ネゴシエーションの開始前に取得したサーバーに関する情報のうち, 安全な手段で取得しなかったものをすべて破棄または更新することが望ましい (SHOULD). これは, TLS 層の導入前に取得されたサーバー機能情報を改変した可能性のある中間者攻撃に対する防御となる.
サーバーは, TLS 層を導入した後に異なる機能を広告することがある. 特に, TLS 層が導入された後は 'supportedSASLMechanisms' の値が異なることがある (具体的には, EXTERNAL および PLAIN [PLAIN] メカニズムは TLS 層が導入された後にのみ列挙される可能性が高い).
3.2. TLS が認可状態に与える影響
TLS の確立, 変更, および/またはクローズによって, 認可状態が新たな状態へ移行することがある. これについては第 4 節でさらに論じる.
3.3. TLS 暗号スイート
与えられた状況で用いるのに適した TLS 暗号スイートを選択する際には, いくつかの問題を考慮すべきである. これらの問題には次が含まれる:
- トランスポート接続を介して送信されるパスワードその他のデータに対して, その暗号スイートが十分な機密性保護を提供できるか. クライアントとサーバーの実装者は, 一部の TLS 暗号スイートは機密性保護をまったく提供しないこと, また機密性保護を提供する他の暗号スイートも, 総当たりによる解読に対して脆弱でありうること, 特に, そのような攻撃の成功に要する時間を短縮する CPU 速度の絶え間ない向上を踏まえると, その点を認識すべきである;
- クライアントとサーバーの実装者は, 保護されるパスワードやデータの価値と, その暗号スイートが提供する機密性保護のレベルとを慎重に比較し, その暗号スイートがもたらす保護のレベルが適切であることを確認すべきである;
- 中間者攻撃に対するその暗号スイートの脆弱性 (またはその欠如). 中間者攻撃に対して脆弱な暗号スイートは, ネットワーク構成上その危険が無視できる場合を除き, パスワードや機密データの保護に用いるべきではない (SHOULD NOT);
- TLS ネゴシエーション (初回または後続) が完了した後, 両プロトコルピアは, ネゴシエートされた暗号スイートが提供するセキュリティサービスが LDAP セッションの意図された用途に対して十分であることを独立に検証すべきである. 十分でない場合, TLS 層を閉じるべきである.