[要約] RFC 3112は、LDAP認証パスワードスキーマに関する規格であり、パスワードの保存と検証方法を定義しています。目的は、LDAPサーバーでのセキュアなパスワード管理を実現することです。

Network Working Group                                        K. Zeilenga
Request for Comments: 3112                           OpenLDAP Foundation
Category: Informational                                         May 2001
        

LDAP Authentication Password Schema

LDAP認証パスワードスキーマ

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2001). All Rights Reserved.

Copyright(c)The Internet Society(2001)。無断転載を禁じます。

Abstract

概要

This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This attribute type holds values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to used instead of userPassword.

このドキュメントでは、AuthPassWord属性タイプを含むLDAP(LightWeight Directory Access Protocol)ディレクトリでのユーザー/パスワード認証をサポートするスキーマについて説明します。この属性タイプは、ユーザーのパスワードから派生した値を保持します(一般的に暗号化強度の一方向ハッシュを使用)。authPasswordは、userpasswordの代わりに使用することを目的としています。

1. Background and Intended Use
1. 背景と目的の使用

The userPassword attribute type [RFC2256] is intended to be used to support the LDAP [RFC2251] "simple" bind operation. However, values of userPassword must be clear text passwords. It is often desirable to store values derived from the user's password(s) instead of actual passwords.

userpassword属性タイプ[RFC2256]は、LDAP [RFC2251]「単純な」バインド操作をサポートするために使用することを目的としています。ただし、userpasswordの値は、テキストのパスワードを明確にする必要があります。多くの場合、実際のパスワードの代わりにユーザーのパスワードから派生した値を保存することが望ましいです。

The authPassword attribute type is intended to be used to store information used to implement simple password based authentication. The attribute type may be used by LDAP servers to implement the LDAP Bind operation's "simple" authentication method.

AuthPassWord属性タイプは、単純なパスワードベースの認証を実装するために使用される情報を保存するために使用することを目的としています。属性タイプは、LDAPサーバーによって使用されて、LDAP Bind操作の「単純な」認証方法を実装できます。

The attribute type supports multiple storage schemes. A matching rule is provided for use with extensible search filters to allow clients to assert that a clear text password "matches" one of the attribute's values.

属性タイプは複数のストレージスキームをサポートします。拡張可能な検索フィルターで使用するために一致するルールが提供され、クライアントが属性の値の1つを「一致させる」ことをクライアントが主張できるようにします。

Storage schemes often use cryptographic strength one-way hashing. Though the use of one-way hashing reduces the potential that exposed values will allow unauthorized access to the Directory (unless the hash algorithm/implementation is flawed), the hashing of passwords is intended to be as an additional layer of protection. It is RECOMMENDED that hashed values be protected as if they were clear text passwords.

ストレージスキームは、多くの場合、暗号化強度の一方向ハッシュを使用します。一方向ハッシュを使用すると、値が公開されるとディレクトリへの不正アクセスが可能になる可能性が減少しますが(ハッシュアルゴリズム/実装に欠陥がない場合を除く)、パスワードのハッシュは追加の保護層として意図されています。ハッシュされた値は、まるでテキストのパスワードを明確にしているかのように保護することをお勧めします。

This attribute may be used in conjunction with server side password generation mechanisms (such as the LDAP Password Modify [RFC3062] extended operation).

この属性は、サーバー側のパスワード生成メカニズム(LDAPパスワードの変更[RFC3062]拡張操作など)と組み合わせて使用できます。

Access to this attribute may governed by administrative controls such as those which implement password change policies.

この属性へのアクセスは、パスワード変更ポリシーを実装する管理者などの管理管理によって管理される場合があります。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119].

「必須」、「そうしない」、「必須」、「「shall」、「shall」、「 "low" of "、" buld "、" becommended "、および" may ")は、このドキュメントの「推奨」、およびRFC 2119 [RFC2119]に記載されています。

2. Schema Definitions
2. スキーマ定義

The following schema definitions are described in terms of LDAPv3 Attribute Syntax Definitions [RFC2252] with specific syntax detailed using Augmented BNF [RFC2234].

以下のスキーマ定義は、拡張BNF [RFC2234]を使用して詳細な特定の構文を使用して、LDAPV3属性構文定義[RFC2252]の観点から説明されています。

2.1. authPasswordSyntax
2.1. authpasswordsyntax

( 1.3.6.1.4.1.4203.1.1.2 DESC 'authentication password syntax' )

(1.3.6.1.4.1.4203.1.1.2 desc '認証パスワード構文')

Values of this syntax are encoded according to:

この構文の値は、次のことに従ってエンコードされます。

      authPasswordValue = w scheme s authInfo s authValue w
      scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F
            ; 0-9, A-Z, "-", ".", "/", or "_"
      authInfo = schemeSpecificValue
      authValue = schemeSpecificValue
              schemeSpecificValue = *( %x21-23 / %x25-7E )
            ; printable ASCII less "$" and " "
      s = w SEP w
      w = *SP
      SEP = %x24 ; "$"
      SP = %x20 ; " " (space)
        

where scheme describes the mechanism and authInfo and authValue are a scheme specific. The authInfo field is often a base64 encoded salt. The authValue field is often a base64 encoded value derived from a user's password(s). Values of this attribute are case sensitive.

スキームがメカニズムとauthinfoとauthvalueを説明する場合、スキーム固有のものです。authinfoフィールドは、多くの場合、base64エンコードされた塩です。AuthValueフィールドは、多くの場合、ユーザーのパスワードから派生したbase64エンコード値です。この属性の値は、ケースに敏感です。

Transfer of values of this syntax is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the values to unauthorized parties.

この構文の値の転送は、基礎となる輸送サービスが機密性を保証できず、不正な当事者への値の開示をもたらす可能性がある場合に強く落胆しています。

This document describes a number of schemes, as well as requirements for the scheme naming, in section 3.

このドキュメントでは、セクション3で、多くのスキームとスキームの命名の要件について説明します。

2.2. authPasswordExactMatch
2.2. authpasswordexactmatch

( 1.3.6.1.4.1.4203.1.2.2 NAME 'authPasswordExactMatch' DESC 'authentication password exact matching rule' SYNTAX 1.3.6.1.4.1.4203.1.1.2 )

(1.3.6.1.4.1.4203.1.2.2名 'authpasswordexactmatch' desc '認証パスワード正確な一致ルール'構文1.3.6.1.4.1.4203.1.1.2)

This matching rule allows a client to assert that an asserted authPasswordSyntax value matches authPasswordSyntax values. It is meant to be used as the EQUALITY matching rule of attributes whose SYNTAX is authPasswordSyntax.

このマッチングルールにより、クライアントはAuthPassWordSyNTAX値がauthPassWordSyNTAX値と一致することをクライアントが主張することができます。これは、構文がauthpasswordsyntaxである属性の平等マッチングルールとして使用されることを意図しています。

The assertion is "TRUE" if there is an attribute value which has the same scheme, authInfo, and authValue components as the asserted value; "FALSE" if no attribute value has the same components as the asserted value; and "Undefined" otherwise.

アサートされた値と同じスキーム、authINFO、およびauthValueコンポーネントを持つ属性値がある場合、アサーションは「真」です。属性値がアサートされた値と同じコンポーネントがない場合、「false」。それ以外の場合は「未定義」。

2.3. authPasswordMatch
2.3. authpasswordmatch

( 1.3.6.1.4.1.4203.1.2.3 NAME 'authPasswordMatch' DESC 'authentication password matching rule' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

(1.3.6.1.4.1.4203.1.2.3名 'authpasswordmatch' desc '認証パスワードマッチングルール'構文 '構文1.3.6.1.4.1.1466.115.121.1.40 {128})

This matching rule allows a client to assert that a password matches values of authPasswordSyntax using an extensibleMatch filter component. Each value is matched per its scheme. The assertion is "TRUE" if one or more attribute values matches the asserted value, "FALSE" if all values do not matches, and "Undefined" otherwise.

この一致するルールにより、クライアントは、extensiblematchフィルターコンポーネントを使用してパスワードがauthPasswordsyNTAXの値と一致すると主張することができます。各値は、スキームごとに一致します。1つ以上の属性値が主張された値と一致する場合、すべての値が一致しない場合は「false」、それ以外の場合は「虚偽」、それ以外の場合、アサーションは「真」です。

Servers which support use of this matching rule SHOULD publish appropriate matchingRuleUse values per [RFC2252], 4.4.

このマッチングルールの使用をサポートするサーバーは、[RFC2252]、4.4ごとに適切な一致するルール値を公開する必要があります。

Transfer of authPasswordMatch assertion values is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the values to unauthorized parties.

AuthPassWordMatchアサーション値の譲渡は、基礎となる輸送サービスが機密性を保証できず、不正な当事者への価値の開示をもたらす可能性がある場合、強く落胆しています。

2.4. supportedAuthPasswordSchemes
2.4. supportedauthpasswordschemes

( 1.3.6.1.4.1.4203.1.3.3 NAME 'supportedAuthPasswordSchemes' DESC 'supported password storage schemes' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} USAGE dSAOperation )

(1.3.6.1.4.1.4203.1.3.3名「SupportedAuthPassWordSchemes」サポートパスワードストレージスキーム「Caseexactia5Match Syntax 1.3.6.1.4.1.1466.115.121.1.1.26 {32}国民化

The values of this attribute are names of supported authentication password schemes which the server supports. The syntax of a scheme name is described in section 2.1. This attribute may only be present in the root DSE. If the server does not support any password schemes, this attribute will not be present.

この属性の値は、サーバーがサポートするサポートされている認証パスワードスキームの名前です。スキーム名の構文は、セクション2.1で説明されています。この属性は、ルートDSEにのみ存在する場合があります。サーバーがパスワードスキームをサポートしていない場合、この属性は存在しません。

2.5. authPassword
2.5. authpassword

( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword' DESC 'password authentication information' EQUALITY 1.3.6.1.4.1.4203.1.2.2 SYNTAX 1.3.6.1.4.1.4203.1.1.2 )

(1.3.6.1.4.1.4203.1.3.4名 'AuthPassword' DESC 'パスワード認証情報'平等1.3.6.1.4.1.4203.1.2.22.2構文1.3.6.1.4.1.4203.1.1.1.2)

The values of this attribute are representative of the user's password(s) and conform to the authPasswordSyntax described in 2.1. The values of this attribute may be used for authentication purposes.

この属性の値は、ユーザーのパスワードを表しており、2.1で説明されているauthpasswordsyntaxに準拠しています。この属性の値は、認証目的で使用できます。

Transfer of authPassword values is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the values to unauthorized parties.

AuthPassword値の転送は、基礎となる輸送サービスが機密性を保証できず、不正な当事者への価値の開示をもたらす可能性がある場合に強く落胆しています。

2.6. authPasswordObject
2.6. authpasswordobject

( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject' DESC 'authentication password mix in class' MAY 'authPassword' AUXILIARY )

(1.3.6.1.4.1.4203.1.4.7名「authpasswordobject」desc '認証パスワードミックスクラス「authpassword」auxiliary)

Entries of this object class may contain authPassword attribute types.

このオブジェクトクラスのエントリには、authpassword属性タイプが含まれる場合があります。

3. Schemes
3. スキーム

This section describes the "MD5" and "SHA1" schemes. Other schemes may be defined by other documents. Schemes which are not described in an RFC SHOULD be named with a leading "X-" to indicate they are a private or implementation specific scheme, or may be named using the dotted-decimal representation [RFC2252] of an OID assigned to the scheme.

このセクションでは、「MD5」および「SHA1」スキームについて説明します。他のスキームは、他のドキュメントで定義される場合があります。RFCで説明されていないスキームは、プライベートまたは実装固有のスキームであることを示すために、主要な「X-」と命名されるか、スキームに割り当てられたOIDの点線型表現[RFC2252]を使用して命名される場合があります。

3.1. MD5 scheme
3.1. MD5スキーム

The MD5 [RFC1321] scheme name is "MD5".

MD5 [RFC1321]スキーム名は「MD5」です。

The authValue is the base64 encoding of an MD5 digest of the concatenation the user password and salt. The base64 encoding of the salt is provided in the authInfo field. The salt MUST be at least 64 bits long. Implementations of this scheme MUST support salts up to 128 bits in length.

AuthValueは、ユーザーパスワードと塩の連結のMD5ダイジェストのbase64エンコードです。塩のbase64エンコーディングは、authinfoフィールドに提供されます。塩は少なくとも64ビットの長さでなければなりません。このスキームの実装は、長さ128ビットまでの塩をサポートする必要があります。

Example: Given a user "joe" who's password is "mary" and a salt of "salt", the authInfo field would be the base64 encoding of "salt" and the authValue field would be the base64 encoding of the MD5 digest of "marysalt".

例:パスワードが「メアリー」で「塩」の塩であるユーザー「ジョー」が与えられた場合、authinfoフィールドは「塩」のbase64エンコードであり、authvalueフィールドは "marysaltのmd5ダイジェストのbase64エンコーディングになります。「。

A match against an asserted password and an attribute value of this scheme SHALL be true if and only if the MD5 digest of concatenation of the asserted value and the salt is equal to the MD5 digest contained in AuthValue. The match SHALL be undefined if the server is unable to complete the equality test for any reason. Otherwise the match SHALL be false.

主張されたパスワードとこのスキームの属性値との一致は、主張された値の連結と塩がauthvalueに含まれるmd5ダイジェストに等しい場合にのみ、真実でなければなりません。何らかの理由でサーバーが平等テストを完了できない場合、試合は未定義になります。それ以外の場合は、一致が誤っているものとします。

Values of this scheme SHOULD only be used to implement simple user/password authentication.

このスキームの値は、単純なユーザー/パスワード認証を実装するためにのみ使用する必要があります。

3.2. SHA1 scheme
3.2. SHA1スキーム

The SHA1 [SHA1] scheme name is "SHA1".

SHA1 [SHA1]スキーム名は「SHA1」です。

The authValue is the base64 encoding of a SHA1 digest of the concatenation the user password and the salt. The base64 encoding of the salt is provided in the authInfo field. The salt MUST be at least 64 bits long. Implementations of this scheme MUST support salts up to 128 bits in length.

AuthValueは、ユーザーパスワードと塩の連結のSHA1ダイジェストのbase64エンコードです。塩のbase64エンコーディングは、authinfoフィールドに提供されます。塩は少なくとも64ビットの長さでなければなりません。このスキームの実装は、長さ128ビットまでの塩をサポートする必要があります。

Example: Given a user "joe" who's password is "mary" and a salt of "salt", the authInfo field would be the base64 encoding of "salt" and the authValue field would be the base64 encoding of the SHA1 digest of "marysalt".

例:パスワードが「メアリー」と「塩」の塩であるユーザー「ジョー」が与えられた場合、authinfoフィールドは「塩」のbase64エンコードであり、authvalueフィールドは "marysaltのsha1ダイジェストのbase64エンコーディングになります。「。

A match against an asserted password and an attribute value of this scheme SHALL be true if and only if the SHA1 digest of concatenation of the asserted value and the salt is equal to the SHA1 digest contained in AuthValue. The match SHALL be undefined if the server is unable to complete the equality test for any reason. Otherwise the match SHALL be false.

主張されたパスワードとこのスキームの属性値との一致は、ASTERTED値の連結のSHA1消化と塩がAuthValueに含まれるSHA1ダイジェストに等しい場合にのみ真実でなければなりません。何らかの理由でサーバーが平等テストを完了できない場合、試合は未定義になります。それ以外の場合は、一致が誤っているものとします。

Values of this scheme SHOULD only be used to implement simple user/password authentication.

このスキームの値は、単純なユーザー/パスワード認証を実装するためにのみ使用する必要があります。

4. Implementation Issues
4. 実装の問題

For all implementations of this specification:

この仕様のすべての実装について:

Servers MAY restrict which schemes are used in conjunction with a particular authentication process but SHOULD use all values of selected schemes. If the asserted password matches any of the stored values, the asserted password SHOULD be considered valid. Servers MAY use other authentication storage mechanisms, such as userPassword or an external password store, in conjunction with authPassword to support the authentication process.

サーバーは、どのスキームを特定の認証プロセスと組み合わせて使用するかを制限する場合がありますが、選択したスキームのすべての値を使用する必要があります。 アサートされたパスワードが保存された値のいずれかと一致する場合、アサートされたパスワードは有効と見なされる必要があります。 サーバーは、認証プロセスをサポートするためにAuthPassWordと組み合わせて、userPasswordや外部パスワードストアなどの他の認証ストレージメカニズムを使用する場合があります。

Servers that support simple bind MUST support the SHA1 scheme and SHOULD support the MD5 scheme.

Simple Bindをサポートするサーバーは、SHA1スキームをサポートし、MD5スキームをサポートする必要があります。

Servers SHOULD NOT publish values of authPassword nor allow operations which expose authPassword values or AuthPasswordMatch assertions to unless confidentiality protection is in place.

サーバーは、authpasswordの値を公開したり、機密保護が整っていない限り、authpassword値またはauthpasswordmatchアサーションを公開する操作を許可したりするべきではありません。

Clients SHOULD NOT initiate operations which provide or request values of authPassword or make authPasswordMatch assertions unless confidentiality protection is in place.

クライアントは、機密保護が整っていない限り、AuthPassWordの値を提供または要求する操作を開始したり、AuthPassWordMatchアサーションを作成したりするべきではありません。

Clients SHOULD NOT assume that a successful AuthPasswordMatch, whether by compare or search, is sufficient to gain directory access. The bind operation MUST be used to authenticate to the directory.

クライアントは、比較または検索のいずれであっても、成功したauthPasswordmatchがディレクトリアクセスを取得するのに十分であると想定すべきではありません。バインド操作は、ディレクトリに認証するために使用する必要があります。

5. Security Considerations
5. セキュリティに関する考慮事項

This document describes how authentication information may be stored in a directory. Authentication information MUST be adequately protected as unintended disclosure will allow attackers to gain immediate access to the directory as described by [RFC2829].

このドキュメントでは、認証情報をディレクトリに保存する方法について説明します。意図しない開示により、攻撃者が[RFC2829]で説明されているように、攻撃者がディレクトリに即座にアクセスできるようになるため、認証情報は適切に保護する必要があります。

As flaws may be discovered in the hashing algorithm or with a particular implementation of the algorithm or values could be subject to various attacks if exposed, values of AuthPassword SHOULD be protected as if they were clear text passwords. When values are transferred, privacy protections, such as IPSEC or TLS, SHOULD be in place.

ハッシュアルゴリズムまたはアルゴリズムまたは値の特定の実装で欠陥が発見される可能性があるため、露出した場合、AuthPassWordの値は明らかなテキストパスワードであるかのように保護する必要があります。値が転送されると、IPSECやTLSなどのプライバシー保護が整っている必要があります。

Clients SHOULD use strong authentication mechanisms [RFC2829].

クライアントは強力な認証メカニズムを使用する必要があります[RFC2829]。

AuthPasswordMatch matching rule allows applications to test the validity of a user password and, hence, may be used to mount an attack. Servers SHOULD take appropriate measures to protect the directory from such attacks.

authPassWordMatchマッチングルールを使用すると、アプリケーションがユーザーパスワードの有効性をテストするため、攻撃の取り付けに使用できます。サーバーは、そのような攻撃からディレクトリを保護するために適切な措置を講じる必要があります。

Some password schemes may require CPU intensive operations. Servers SHOULD take appropriate measures to protect against Denial of Service attacks.

一部のパスワードスキームには、CPU集中操作が必要になる場合があります。サーバーは、サービス拒否攻撃から保護するために適切な対策を講じる必要があります。

AuthPassword does not restrict an authentication identity to a single password. An attacker who gains write access to this attribute may store additional values without disabling the user's true password(s). Use of policy aware clients and servers is RECOMMENDED.

AuthPassWordは、認証IDを単一のパスワードに制限しません。この属性への書き込みアクセスを獲得する攻撃者は、ユーザーの真のパスワードを無効にすることなく追加の値を保存できます。ポリシーの認識クライアントとサーバーの使用が推奨されます。

The level of protection offered against various attacks differ from scheme to scheme. It is RECOMMENDED that servers support scheme selection as a configuration item. This allows for a scheme to be easily disabled if a significant security flaw is discovered.

さまざまな攻撃に対して提供される保護レベルは、スキームごとに異なります。サーバーは、構成アイテムとしてスキームの選択をサポートすることをお勧めします。これにより、重要なセキュリティ欠陥が発見された場合、スキームを簡単に無効にすることができます。

6. Acknowledgment
6. 了承

This document borrows from a number of IETF documents and is based upon input from the IETF LDAPext working group.

このドキュメントは、多くのIETFドキュメントから借用し、IETF LDAPEXTワーキンググループからの入力に基づいています。

7. Bibliography
7. 書誌

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992

[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月

[RFC2219] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2219] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2234] Crocker, D., Editor, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[RFC2234] Crocker、D.、Editor、P。Overell、「構文仕様のためのBNFの増強:ABNF」、RFC 2234、1997年11月。

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

[RFC2251] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol(V3)」、RFC 2251、1997年12月。

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

[RFC2252] Wahl、M.、Coulbeck、A.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol(V3):属性構文定義」、RFC 2252、1997年12月。

[RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.

[RFC2256] Wahl、A。、「LDAPV3で使用するためのX.500(96)ユーザースキーマの要約」、RFC 2256、1997年12月。

[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.

[RFC2307] Howard、L。、「LDAPをネットワーク情報サービスとして使用するためのアプローチ」、RFC 2307、1998年3月。

[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, June 2000.

[RFC2829] Wahl、M.、Alvestrand、H.、Hodges、J。およびR. Morgan、「LDAPの認証方法」、RFC 2829、2000年6月。

[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", RFC 3062, February 2001.

[RFC3062] Zeilenga、K。、「LDAPパスワードの変更拡張操作」、RFC 3062、2001年2月。

[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

[Sha1] Nist、Fips Pub 180-1:Secure Hash Standard、1995年4月。

8. Author's Address
8. 著者の連絡先

Kurt D. Zeilenga OpenLDAP Foundation

Kurt D. Zeilenga OpenLdap Foundation

   EMail: Kurt@OpenLDAP.org
        
9. 完全な著作権声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

Copyright(c)The Internet Society(2001)。無断転載を禁じます。

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.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。