5. Bind 操作
Bind 操作 ([RFC4511] の 4.2 節) は, 新たな認可状態を確立するために, 認証情報をクライアントとサーバーの間で交換することを可能にする.
Bind 要求は通常, 所望の認証アイデンティティを指定する. 一部の Bind メカニズムでは, クライアントが認可アイデンティティも指定できる. 認可アイデンティティが指定されない場合, サーバーは実装固有の方法で認証アイデンティティからそれを導出する.
認可アイデンティティが指定された場合, サーバーは, クライアントの認証アイデンティティが主張された認可アイデンティティを引き受ける (例えば代理する) ことを許されているか検証しなければならない (MUST). クライアントにその権限がない場合, サーバーは Bind 応答において resultCode の invalidCredentials を伴って Bind 操作を拒否しなければならない (MUST).
5.1. simple 認証方式
Bind 操作の simple 認証方式は, 3 つの認証メカニズムを提供する:
- 匿名認証メカニズム (5.1.1 項).
- 未認証認証メカニズム (5.1.2 項).
- (LDAP の識別名 [RFC4514] 形式の) name とパスワードからなる資格情報を用いる名前/パスワード認証メカニズム (5.1.3 項).
5.1.1. simple Bind の匿名認証メカニズム
LDAP クライアントは, simple Bind 方式の匿名認証メカニズムを用いて, 長さ 0 の name 値と, 長さ 0 の password 値を含む simple 認証の選択肢を指定した Bind 要求を送信することにより, 匿名認可状態を明示的に確立してよい.
5.1.2. simple Bind の未認証認証メカニズム
LDAP クライアントは, simple Bind 方式の未認証認証メカニズムを用いて, (LDAP 文字列形式 [RFC4514] の長さが 0 でない識別名である) name 値と, 長さ 0 の password 値を含む simple 認証の選択肢を指定した Bind 要求を送信することにより, 匿名認可状態を確立してよい.
クライアントが提供する識別名の値は, 追跡 (例えばログ記録) の目的にのみ用いられることが意図されている. この値は, 認証その他の検証 (その DN が既存のディレクトリオブジェクトを指していることの検証を含む) を行ってはならない. この値は, 認可の目的に (直接的にも間接的にも) 用いてはならない.
未認証 Bind 操作は重大なセキュリティ上の問題を抱えうる (6.3.1 節参照). 特に, 名前/パスワード認証を行おうとしたユーザーが誤って空のパスワードを提供し, その結果, 実装の不出来なクライアントが未認証アクセスを要求してしまうことがある. クライアントは, 空のパスワードの入力という手段以外によって, 未認証認証メカニズムをユーザーが選択することを要求するよう実装することが望ましい (SHOULD). クライアントは, 名前/パスワード認証のユーザーインターフェースへの空のパスワード入力を許可しないことが望ましい (SHOULD). さらに, サーバーは, 既定で, 未認証 Bind 要求を resultCode の unwillingToPerform で失敗させることが望ましい (SHOULD).
5.1.3. simple Bind の名前/パスワード認証メカニズム
LDAP クライアントは, simple Bind 方式の名前/パスワード認証メカニズムを用いて, (LDAP 文字列形式 [RFC4514] の長さが 0 でない識別名である) name 値と, 長さが 0 でない OCTET STRING の password 値を含む simple 認証の選択肢を指定した Bind 要求を送信することにより, 認証済みの認可状態を確立してよい.
Bind 要求で送信された DN を, このメカニズムで用いられる 1 つ以上のパスワードの集合を伴うディレクトリエントリにマッピングするサーバーは, 提示されたパスワードをそのパスワード集合と比較する. 提示されたパスワードは, この集合のいずれかの要素と一致すれば有効と見なされる.
resultCode の invalidDNSyntax は, name 値で送信された DN が構文的に無効であることを示す. resultCode の invalidCredentials は, DN が構文的には正しいが認証の目的には有効でないこと, その DN に対してパスワードが有効でないこと, またはサーバーがその資格情報を無効と見なしていることを示す. resultCode の success は, 資格情報が有効であり, サーバーがこれらの資格情報が識別する実体にサービスを提供する用意があることを示す.
名前/パスワード認証メカニズムを指定しつつ, 長さ 0 の name 値と長さが 0 でない password 値を伴う Bind 要求に対するサーバーの挙動は定義されていない.
simple Bind 方式の名前/パスワード認証メカニズムは, 機密性保護のない環境での認証には適さない.
5.2. SASL 認証方式
Bind 操作の sasl 認証方式は, 認証メカニズムやその他のサービス (例えばデータセキュリティサービス) を含む任意の SASL メカニズムを用いるための機能を提供する.
5.2.1. SASL プロトコルプロファイル
LDAP は任意の SASL メカニズム [RFC4422] による認証を可能にする. LDAP にはネイティブの匿名認証方式と名前/パスワード (平文) 認証方式が含まれるため, ANONYMOUS [RFC4505] および PLAIN [PLAIN] SASL メカニズムは通常 LDAP では用いられない.
SASL サービスを利用する各プロトコルは, それらがプロトコルを通じてどのように公開されるかを記述する特定の情報を提供することが要求される ([RFC4422] の 4 節). 本節では, これらのプロファイル要件の各々が LDAP によってどのように満たされるかを説明する.
5.2.1.1. LDAP の SASL サービス名
LDAP の SASL サービス名は "ldap" であり, IANA に SASL サービス名として登録されている.
5.2.1.2. SASL 認証の開始とプロトコル交換
SASL 認証は, 次のパラメータを伴う BindRequest メッセージ ([RFC4511] の 4.2 節) によって開始される:
- version は 3 である.
- AuthenticationChoice は sasl である.
- SaslCredentials シーケンスの mechanism 要素に, 所望の SASL メカニズムの値が入る.
- SaslCredentials シーケンスの任意の credentials フィールドは, クライアントが最初にデータを送るよう定義されたメカニズムのために, クライアントの初期応答を提供するのに用いてもよい (MAY) ([RFC4422] の 3 節と 5 節参照).
一般に, SASL 認証プロトコル交換は一連のサーバーチャレンジとクライアント応答から成り, その内容は SASL メカニズムに固有であり, そのメカニズムによって定義される. したがって, 一部の SASL 認証メカニズムでは, クライアントが 1 つ以上のサーバーチャレンジに対して BindRequest メッセージを繰り返し送信して応答する必要があるかもしれない. チャレンジは, サーバーが resultCode を
saslBindInProgress に設定した BindResponse メッセージを送信することによって示される. これは, 認証過程を継続するために, 同じ SASL メカニズムで新たな BindRequest メッセージを送信することをサーバーがクライアントに要求していることを示す.
LDAP メッセージ層にとって, これらのチャレンジと応答は任意長の不透明なバイナリトークンである. LDAP サーバーは, 各チャレンジを送信するために BindResponse メッセージの serverSaslCreds フィールド (OCTET STRING) を用いる. LDAP クライアントは, 各応答を送信するために BindRequest メッセージの SaslCredentials シーケンスの credentials フィールド (OCTET STRING) を用いる. SASL が用いられる一部のインターネットプロトコルとは異なり, LDAP はテキストベースではなく, これらのチャレンジと応答の値を Base64 変換しないことに留意されたい.
sasl を選択した BindRequest メッセージを送信するクライアントは, name フィールドに長さ 0 の値を送信することが望ましい (SHOULD). sasl を選択した BindRequest メッセージを受信するサーバーは, name フィールドの値を無視するものとする (SHALL).
クライアントは, SaslCredentials の mechanism フィールドに異なる値を入れた BindRequest メッセージ, または sasl 以外の AuthenticationChoice を伴う BindRequest メッセージを送信することにより, SASL Bind のネゴシエーションを中断してよい.
クライアントが sasl mechanism フィールドを空文字列とした BindRequest を送信した場合, サーバーは resultCode の authMethodNotSupported を伴う BindResponse を返さなければならない (MUST). これにより, クライアントは, 同じ SASL メカニズムで再試行したい場合にネゴシエーションを中断できる.
サーバーは, resultCode の値が saslBindInProgress でない BindResponse で応答することにより, SASL チャレンジ-レスポンス交換の完了を示す.
BindResponse の serverSaslCreds フィールドは, サーバーが完了通知とともに追加データを送るよう定義されたメカニズムのために, 成功通知を伴う任意のチャレンジを含めるのに用いることができる.
5.2.1.3. 任意フィールド
上述のとおり, LDAP は, SASL 交換を開始するメッセージで初期応答を運ぶための任意フィールドと, 認証交換の結果を示すメッセージで追加データを運ぶための任意フィールドを提供する. これらのフィールド内のメカニズム固有の内容は長さ 0 でありうるため, SASL は, 空のフィールドと存在しないフィールドとがどのように区別されるかをプロトコル仕様が詳述することを要求する.
長さ 0 の初期応答データは, 開始メッセージである BindRequest PDU において, SaslCredentials.credentials OCTET STRING (長さ 0) がその PDU に存在することによって, 初期応答データなしと区別される. クライアントが SASL 交換を開始する BindRequest で初期応答を送る意図がない場合, (長さ 0 の OCTET STRING を含めるのではなく) SaslCredentials.credentials OCTET STRING を省略しなければならない (MUST).
長さ 0 の追加データは, 結果メッセージである BindResponse PDU において, serverSaslCreds OCTET STRING (長さ 0) がその PDU に存在することによって, 追加応答データなしと区別される. サーバーが, 交換の結果を示す BindResponse メッセージで追加データを送る意図がない場合, (長さ 0 の OCTET STRING を含めるのではなく) serverSaslCreds OCTET STRING を省略するものとする (SHALL).
5.2.1.4. ネゴシエートされたセキュリティ層が有効になるオクテット
SASL 層は, SASL 交換における最後の BindResponse を resultCode の success を伴ってサーバーが送信しクライアントが受信した後に有効になる.
データ完全性または機密性のサービスを提供する SASL 層は, いったん有効になると, 新たな層が導入されるまで有効であり続ける (すなわち, 新たな層を有効にした Bind 操作の最後の BindResponse の直後のオクテットまで). したがって, 確立された SASL 層は, 失敗した Bind や SASL 以外の Bind の影響を受けない.
5.2.1.5. サポートされる SASL メカニズムの判定
クライアントは, ルート DSE (DSA-Specific Entry) から 'supportedSASLMechanisms' 属性を読むことにより, サーバーがサポートする SASL メカニズムを判定してよい ([RFC4512] の 5.1 節). この属性の値は, 存在する場合, 現在の LDAP セッション状態でサーバーがサポートするメカニズムを列挙する. LDAP サーバーは, すべてのクライアントに (匿名認可を持つものも含めて), SASL 認証交換の前と後の両方でルート DSE の 'supportedSASLMechanisms' 属性を取得できるようにすることが望ましい (SHOULD). 後者の目的は, クライアントがダウングレード攻撃の可能性を検出できるようにすることである (6.4 節と [RFC4422] の 6.1.2 節参照).
SASL メカニズムは重要なセキュリティ機能を提供するため, クライアントとサーバーは, どのメカニズムが許容されるかを指定し, それらのメカニズムのみの使用を許すよう構成可能であるべきである. クライアントとサーバーの双方は, セッションの使用に進む前に, ネゴシエートされたセキュリティレベルが自らの要件を満たすことを確認しなければならない.
5.2.1.6. SASL 層を用いるための規則
SASL 層を導入した際, クライアントは, SASL ネゴシエーションの開始前に取得したサーバーに関する情報のうち, 安全なメカニズムを通じて取得しなかったものをすべて破棄または更新することが望ましい (SHOULD).
下位のセキュリティ層 (例えば TLS) が導入されている場合, SASL 層は, そのネゴシエーションの順序にかかわらず, そのようなセキュリティ層の上に重ねられるものとする (SHALL). その他の点では, SASL 層と他のセキュリティ層は独立に動作する. 例えば, TLS 層と SASL 層の両方が有効である場合, TLS 層を除去しても SASL 層の継続的なサービスには影響しない.
5.2.1.7. 複数回の認証のサポート
LDAP は, [RFC4422] の 4 節で定義された複数回の SASL 認証をサポートする.
5.2.1.8. SASL 認可アイデンティティ
一部の SASL メカニズムは, クライアントが LDAP セッションの所望の認可アイデンティティを要求することを可能にする ([RFC4422] の 3.4 節). 現在の認証アイデンティティに要求された認可アイデンティティへのアクセスを許すか否かの決定は, ローカルポリシーの事項である. 認可アイデンティティは, 次の Augmented Backus-Naur Form (ABNF) [RFC4234] 文法に対応する, UTF-8 [RFC3629] で符号化された [Unicode] 文字の文字列である:
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id
dnAuthzId = "dn:" distinguishedName
; unspecified authorization id, UTF-8 encoded
uAuthzId = "u:" userid
userid = *UTF8 ; syntax unspecified
ここで, distinguishedName 規則は [RFC4514] の 3 節で定義され, UTF8 規則は [RFC4512] の 1.4 節で定義される.
dnAuthzId の選択肢は, distinguishedNameMatch 照合規則 ([RFC4517] の 4.2.15 節) に従って照合される識別名の形式で認可アイデンティティを主張するために用いられる. 主張された distinguishedName 値がディレクトリ内のエントリのものであることは要求されない.
uAuthzId の選択肢は, クライアントが識別名形式ではない認可アイデンティティを主張することを可能にする. userid の形式は UTF-8 [RFC3629] で符号化された [Unicode] 文字の並びとしてのみ定義され, それ以上の解釈はローカルな事項である. 例えば, userid は特定のディレクトリサービスのユーザーを識別するものでもよく, ログイン名でもよく, 電子メールアドレスでもよい. uAuthzId がグローバルに一意であると見なすべきではない (SHOULD NOT). uAuthzId 値を比較するには, 各 uAuthzId 値を SASLprep [RFC4013] アルゴリズムを用いて "query" 文字列 ([RFC3454] の 7 節) として準備しなければならず (MUST), その後, 2 つの値をオクテット単位で比較する.
上記の文法は拡張可能である. authzId 生成規則は, 追加の形式のアイデンティティをサポートするよう拡張してよい. 各形式は, その一意な接頭辞によって区別される (登録要件については [RFC4520] の 3.12 節参照).
5.2.2. LDAP 内での SASL の意味論
実装者は, LDAP プロトコルにおいて異なる意味論を持つデータを扱う際, SASL 仕様の意味論を維持するよう注意しなければならない.
例えば, SASL DIGEST-MD5 認証メカニズム [DIGEST-MD5] は, 構文的には単純な文字列であり意味的には単純なユーザー名 [RFC4013] とレルムの値である, 認証アイデンティティとレルムを用いる. これらの値は LDAP の DN ではなく, そのように表現したり扱ったりする要件はない.
5.2.3. SASL EXTERNAL 認証メカニズム
クライアントは, SASL EXTERNAL ([RFC4422] の付録 A) メカニズムを用いて, 下位のセキュリティ層で交換されたセキュリティ資格情報 (例えば TLS 認証によるもの) を用いて LDAP サーバーに認証を行わせ, 結果としての認可アイデンティティを確立するよう要求できる. クライアントの認証資格情報が下位のセキュリティ層で確立されていない場合, SASL EXTERNAL Bind は resultCode の inappropriateAuthentication で失敗しなければならない (MUST). この状況は LDAP セッションを匿名状態に留める効果を持つが (第 4 節), 導入済みのセキュリティ層の状態は影響を受けない.
クライアントは, 下位のセキュリティ層で交換された認証資格情報から自身の認可アイデンティティを自動的に導出するよう要求してもよく, あるいは所望の認可アイデンティティを明示的に提供してもよい. 前者は暗黙の主張, 後者は明示的な主張と呼ばれる.
5.2.3.1. 暗黙の主張
暗黙の認可アイデンティティ主張は, (BindRequest 内の SaslCredentials シーケンスにある) 任意の credentials フィールドを含まない, EXTERNAL メカニズム名を用いた SASL 形式の Bind 要求を発行することによって行われる. サーバーは, ローカルポリシーに従って, セキュリティ層によって提供された認証アイデンティティ (例えば TLS 層の導入中に用いられた公開鍵証明書) からクライアントの認可アイデンティティを導出する. これがどのように達成されるかの下位の仕組みは実装固有である.
5.2.3.2. 明示的な主張
明示的な認可アイデンティティ主張は, (BindRequest 内の SaslCredentials シーケンスにある) credentials フィールドを含む, EXTERNAL メカニズム名を用いた SASL 形式の Bind 要求を発行することによって行われる. credentials フィールドの値 (OCTET STRING) が主張された認可アイデンティティであり, 5.2.1.8 項に記述されたとおりに構築しなければならない (MUST).