RFC2255JP

Network Working Group	T. Howes
Request for Comments: 2255	M.Smith
Category: Standards Track	Netscape Communications Corp.
December 1997

The LDAP URL Format

本文書は、インターネットコミュニティのための標準化プロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。本プロトコルの標準化状態、および、ステータスについては「Internet Official Protocol Standards」(STD 1)の最新版を参照してほしい。このメモの配布に制限は無い。

著作権について

IESGノート

本文書では、読み出しおよび更新アクセスを提供するディレクトリアクセスプロトコルについて述べる。更新アクセスには安全な認証が必要であるが、本文書は十分な認証機構の実装についてはなにも指示しない。

このような制限は存在するが、本仕様書は、RFC 2026のセクション4.4.1に従って、Proposed StandardとしてIESGに認可されている。その理由は次の通りである：

配備される前に、(更新アクセスの有無に関わらず)本プロトコルの実装と相互運用性の試験を奨励するため。
読み出し専用のアプリケーション中でのこれらのプロトコルの配備と利用を奨励するため。(例えば、LDAP以外の安全な方法で更新されるディレクトリに対して、LDAPv3が問い合わせ言語として使用されているアプリケーション）
LDAPv3ディレクトリサーバへの問い合わせ機能が必要であるが、更新を必要としない他の標準化過程にあるプロトコルの配備あるいは、進歩を遅らせないため。

必須の認証機構が標準化されるまで、本仕様に従って書かれた更新機能を利用するクライアントとサーバは相互運用できない、あるいは、認証レベルが受け入れ難いレベルにまで下げられる場合に限り相互運用できる、という可能性があることを読者にあらかじめ警告する。

実装者は、LDAPv3で必須となる認証のためのProposed Standardが認められ、RFCとして発行されるまで、更新機能を実装するLDAPv3クライアント、およびサーバの配備を行わないことが望ましい。

LDAPは、Lightweight Directory Access Protocolの略であり、[1]、[2]、[3]で定義されている。本文書は、LDAP Uniform Resource Locatorのフォーマットについて説明している。このフォーマットはLDAPディレクトリから情報を検索するためのLDAP検索オペレーションについての記述である。本文書はRFC 1959を置き換え、LDAPバージョン3の LDAP URLフォーマットを更新し、LDAP URLがどのように解決されるのかを明確にする。本文書は、今後の文書がそれらの機能を拡張できるように、例えば、新しいLDAPv3拡張が定義されると同時にそれらにアクセスを提供できるように、LDAP URLsの拡張機構についても定義する。

本文書中のキーワード"MUST"、 "MAY"、 "SHOULD"は[6]に記述されたように解釈されるべき用語である。

LDAP URLは「ldap」というプロトコル接頭語で始まり、以下のような文法で定義される。

       ldapurl    = scheme "://" [hostport] ["/"
                    [dn ["?" [attributes] ["?" [scope]
                    ["?" [filter] ["?" extensions]]]]]]
       scheme     = "ldap"
       attributes = attrdesc *("," attrdesc)
       scope      = "base" / "one" / "sub"
       dn         = distinguishedName from Section 3 of [1]
       hostport   = hostport from Section 5 of RFC 1738 [5]
       attrdesc   = AttributeDescription from Section 4.1.5 of [2]
       filter     = filter from Section 4 of [4]
       extensions = extension *("," extension)
       extension = ["!"] extype ["=" exvalue]
       extype     = token / xtoken
       exvalue    = LDAPString from section 4.1.2 of [2]
       token      = oid from section 4.1 of [3]
       xtoken     = ("X-" / "x-") token

ldap接頭語は、与えられた<hostname>の与えられた<portnumber>で動作しているLDAPサーバに存在する、1つ以上のエントリを指す。デフォルトのポート番号は、TCPポートの389番である。ホスト/ポートが指定されていないなら、クライアントはアクセスできる適切なLDAPサーバについての予備知識を持っていなければならない。

dnは、[1]で説明される文字列フォーマットを使用したLDAPの識別名(Distinguished Name)である。これはLDAP検索のベースオブジェクトを識別する。

attributes構造子は、１つまたは複数のエントリからの返されるべき属性を示すために使用される。個々のattrdesc名は[2]のAttributeDescriptionに定義されている通りである。attributes部分が省略されると、１つまたは複数のエントリのすべてのユーザ属性が要求される。(例えば、LDAP検索要求で属性フィールドattributeDescriptionListをNULLリストに設定したり、LDAPv3で特殊な属性名「*」を要求するなど)

scope構造子は、与えられたLDAPサーバで実行される検索の範囲を指定するために使用される。使用できる範囲は、ベースオブジェクト検索を指す"base"、１レベル検索を指す"one"、そしてサブツリー検索を指す"sub"である。scopeが省略されると、"base"スコープが使用される。

filterは、検索時に指定された範囲内のエントリに適用する検索フィルタの指定のために使用される。これは[4]で指定されるフォーマットを持つ。filterが省略されると、"(object class)"というフィルタが使用される。

extensions構造子は、URLの能力を将来的に拡張できるようにLDAP URLに拡張機構を提供する。拡張は、type=valueのペアをコンマに区切った単純なリストである。不必要なオプションの場合、=value部分は、省略してもよい(MAY)。それぞれのtype=valueのペアは個々に拡張される。これらのLDAP URL拡張は必ずしもLDAPv3拡張機構のいずれかに関連づけることはない。拡張は、URLを解析するクライアントによってサポートされてもされなくてもかまわない。'!'文字(ASCII 33)を前につけられる拡張はクリティカルである。'!'文字(ASCII 33)をつけられない拡張はノンクリティカルである。

クライアントによってサポートされる拡張がクリティカルであるなら、クライアントはその拡張に従わなければならない(MUST)。サポートされた拡張がノンクリティカルであるならクライアントはその拡張に従うべきである(SHOULD)。

クライアントによってサポートされない拡張がクリティカルであるなら、クライアントはその拡張を処理してはならない(MUST NOT)。サポートされない拡張がノンクリティカルであるなら、クライアントはその拡張を無視しなければならない(MUST)。

クライアントがクリティカルな拡張をうまく処理できないなら、クライアントはそのURLを処理してはならない(MUST NOT)。クライアントがノンクリティカルな拡張をうまく処理できないなら、クライアントはその拡張を無視するべきである (SHOULD)。

「X-」あるいは「x-」が前につく拡張型は、通信者間で双方の合意のもとに使用するために予約されている。他の拡張型は、本書やまたは他の標準トラック文書で定義されなければならない(MUST)。

１つのLDAP URL拡張が本文書の次のセクションで定義される。他の文書や本文書の今後のバージョンは他の拡張を定義してもよい(MAY)。

URLで不正となる文字、(例えば、空白)、URLに特殊な文字(RFC 1738のセクション2.2で定義される)、予約された文字「？」(ASCII 63)が、dnやフィルタ、あるいはLDAP URLの他の要素に含まれている場合には、RFC 1738 [5]で記述されている%方式を使ってエスケープされなければならない(MUST)。コンマ文字「,」が拡張値に含まれているなら、同じく%方式を使ってエスケープされなければならない(MUST)。

本セクションでは、LDAP URLの探索時にLDAP directoryが認証を行う際、クライアントが使う識別名を表記するためのLDAP URL拡張を定義する。クライアントはこの拡張を実装してもよい(MAY)。

拡張型は「bindname」である。拡張値は、dnのために上記の文法で記述された形式と同じ形式で、認証に使用されるディレクトリエントリの識別名である。dnは認証されていないアクセスを指定するためにNULL文字列であるかも知れない。拡張はクリティカル(「!」文字が前に付く)かノンクリティカル(「!」文字が前に付かない)のいずれかである。

bindname拡張がクリティカルであるなら、URLを探索しているクライアントは特定の識別名と適切な認証方式を使用してディレクトリに認証されなければならない(MUST)。NULL識別名において、ディレクトリに匿名のアクセスをするためにバインドがなくてもよい(MAY)ことに注意。拡張がノンクリティカルであるなら、クライアントは与えられた識別名を使ってディレクトリにバインドしてもよい(MAY)。

本セクションでは、LDAP URLがクライアントによってどのように探索されるべき(SHOULD)かを記述する。

最初に、クライアントは、URLで参照されたLDAPサーバ、あるいはLDAPサーバが明示的に参照されていないときには、クライアントの好みのサーバとコネクションを確立する。クライアントはURLを探索するためにこのコネクションを特別に開いてもよい(MAY)し、既に開かれているコネクションを再利用してもよい(MAY)。コネクションは機密性、完全性や他のサービスを提供してもよい(MAY)。例えば、TLSの使用。URLで指定されていないなら、セキュリティサービスの使用はクライアントの自由裁量に任されている。

次に、クライアントはLDAPサーバに自己認証をする。このステップは、URLがnon-NULL値によるクリティカルなbindname拡張を含まない限り、任意である。Bindname拡張が指定されているなら、クライアントは上記のセクションに従って進む。

bindname拡張が指定されていないなら、クライアントは適切なdnと自分で選択する認証方式(NULL認証も含む)を使ってディレクトリにバインドしてもよい(MAY)。

次に、クライアントはURLで指定されたLDAP検索オペレーションを行う。<sizelimit>、<timelimit>、<deref>、および他のURL仕様で定められていない、または使用されていないようなLDAPプロトコル検索要求中の追加のフィールドは、クライアントの自由裁量によって指定してよい(MAY)。

検索が終了したら、クライアントは LDAPサーバとのコネクションを閉じてもよい(MAY)し、今後の使用のためにコネクションを開いておいてもよい(MAY)。

次に示すのは、前項で定義したフォーマットを使用したいくつかのLDAP URLの例である。最初の例は、クライアントが選んだLDAPサーバから利用可能なミシガン大学のエントリへの参照を行うLDAP URLである。

ldap:///o=University%20of%20Michigan,c=US

次の例は、ある特定のLDAPサーバにあるミシガン大学のエントリに問い合わせを行っているLDAP URLである。

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

これら2つのURLは、すべての属性を要求する「(object class=*)」のフィルタを使用する「o=University of Michigan, c=US」のエントリのベースオブジェクト検索に対応したものである。

次の例はミシガン大学のエントリのpostalAddress属性だけを問い合わせるLDAP URLである：

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,
c=US?postalAddress

これに対応するLDAP検索オペレーションは、postalAddress属性だけが要求されていることを除けば、前出の例と同じである。

次の例は、特定のサーバの6666番ポートに対して問い合わせを行い、すべての属性を検索し、cnが「Babs Jensen」であるすべてのエントリを求めてミシガン大学のサブツリー検索を行い、検出されたエントリを参照するLDAP URLである。

ldap://host.com:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)

次の例はc=GBというエントリの全ての子エントリを参照するLDAP URLである。

ldap://ldap.itd.umich.edu/c=GB?objectClass?one

ここでは、エントリとともに、objectClass属性を返すことが要求され、「objectclass=*」というデフォルトフィルタが使用されている。

次の例は「?」という予約文字に対して使われるエスケープメカニズムを使用し、「o=Question?,c=US」というLDAPエントリのmail属性を検索するLDAP URLである。

ldap://ldap.question.com/o=Question%3f,c=US?mail

次の例はLDAPとURL中の引用メカニズムの相互関係を説明する。

ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)

この例では、フィルタは＼のエスケープ機構を使って値の中の3つのゼロ、およびNULLバイトを符号化する。LDAPでは、フィルタは(int=＼00＼00＼00＼04)として書かれる。URLでは、＼という文字がエスケープされるべきであるから、URL符号化のように＼は%5cとしてエスケープされる。

最後に、URLを探索する際クライアントが認証するために利用すべきであるdnを指定するbindname extensionの使用例を示す。

ldap:///??sub??bindname=cn=Manager%2co=Foo
ldap:///??sub??!bindname=cn=Manager%2co=Foo

2番目のURLがbindname extensionをクリティカルとして指し示していることを除けば、２つのURLは同じである。bind extension nameでは、識別名値でのコンマを符号化するため％符号化方式を使用することに注意。

[5]で論じられた一般的なURLセキュリティに関する考察はLDAP URLにおいて信頼できるものである。

URLは、ユーザ介入なしに自動的に処理されがちであり、クライアントはURLを介して、多くの異なるサーバに遭遇するかもしれない。そのため、LDAP URLを処理する際のセキュリティメカニズムの利用には、特別な注意が必要である。クライアントがどのサーバとコネクションを確立するか、または、どのセキュリティ機構を使うかということまで、ユーザによってカスタマイズできるポリシーを持つべきである(SHOULD)。そして、このポリシーと一致しないコネクションを確立すべきではない(SHOULD NOT)。

認証情報を送ることは、メカニズムに関係なく、ユーザのプライバシーを侵害する可能性がある。サーバに認証情報の送信を許すための特定のポリシーがない場合、クライアントは匿名のコネクションを使うべきである。(すべてのコネクションが匿名であり、保護されていない環境では、先のLDAP URL仕様書に従っているクライアントがこの仕様に一致することに注意。；これらはデフォルトのセキュリティポリシーだけを持つ。)

いくつかの認証方式は、特にサーバに送信した再利用可能なパスワードは、送信中にリモートサーバ、あるいは盗聴者に対して、容易に乱用できる情報が漏洩する可能性があるので、ポリシーによって明確に認められない限りURL処理で使用しないほうがよい。多くの状況において、使用者による認証情報の使用の確認が適切である。機密扱いの情報を明らかにしない、厳密認証方式を使用することがより好ましい。

LDAP URL形式はLDAP URLを評価する時、任意のLDAP検索オペレーションの指定を行うことができる。LDAP URLに従うことは意外な結果を起こすかも知れない。例えば、大量のデータを取り出し、長時間かかる検索など。LDAP URLの探索に関するセキュリティ的な意味合いは、LDAP検索を解決するときと同じである。

LDAP URLフォーマットは、元々ミシガン大学で定義された。この資料はNational Science FoundationのGrant No. NCR-9416667に基づくものである。ミシガン大学とNational Science Foundationの尽力に対し、こころより謝意を贈る。

何人かの人々からこの文章に対する価値のあるコメントをいただいた。特に、RL "Bob" MorganとMark Wahlには、彼らの貢献に対して深く感謝する。

   [1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
   Protocol (v3): UTF-8 String Representation of Distinguished Names",
   RFC 2253, December 1997.

[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.

   [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
   Directory Access Protocol (v3): Attribute Syntax Definitions",
   RFC 2252, December 1997.

[4] Howes, T., "A String Representation of LDAP Search Filters",
RFC 2254, December 1997.

[5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)," RFC 1738, December 1994.

[6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997.

Authors' Addresses

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA

   Phone: +1 415 937-3419
   EMail: howes@netscape.com

   Mark Smith
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA

   Phone: +1 415 937-3477
   EMail: mcs@netscape.com

Full Copyright Statement

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.