A.3 Oracle Unified Directoryがサポートしている規格および仕様
A.3.1 Oracle Unified DirectoryがサポートしているRFC
Oracle Unified Directoryは、新しいプロトコルに準拠するよう絶えず更新されています。
表A-7は、Oracle Unified Directoryで現在サポートされているRFCのリストです。
表A-7 サポートされているRFC
| 番号 | 説明 |
|---|---|
|
RFC 1274 |
COSINEおよびInternet X.500スキーマ |
|
RFC 1321 |
MD5メッセージ・ダイジェスト・アルゴリズム |
|
RFC 1777 |
Lightweight Directory Access Protocol (v2) |
|
RFC 1778 |
標準属性構文の文字列表現 |
|
RFC 1779 |
識別名の文字列表現 |
|
RFC 2079 |
Uniform Resource Identifiers (URI)を保持するためのX.500属性タイプおよびオブジェクト・クラスの定義 |
|
RFC 2222 |
Simple Authentication and Security Layer(SASL) |
|
RFC 2246 |
TLSプロトコル |
|
RFC 2246 |
TLSプロトコル・バージョン1.0 |
|
RFC 2247 |
LDAP/X.500識別名のドメインの使用 |
|
RFC 2251 |
Lightweight Directory Access Protocol (v3) |
|
RFC 2252 |
Lightweight Directory Access Protocol (v3): 属性構文定義 |
|
RFC 2254 |
LDAP検索フィルタの文字列表現 |
|
RFC 2255 |
LDAP URLフォーマット |
|
RFC 2256 |
LDAPv3とともに使用されるX.500(96)ユーザー・スキーマのサマリー |
|
RFC 2307 |
ネットワーク情報サービスとしてLDAPを使用する方法 |
|
RFC 2377 |
インターネット・ディレクトリ対応アプリケーションの命名計画 |
|
RFC 2605 |
ディレクトリ・サーバーのモニタリングMIB |
|
RFC 2649 |
操作署名を保持するためのLDAP制御およびスキーマ |
|
RFC 2696 |
単純なページ結果操作のためのLDAP制御拡張 |
|
RFC 2713 |
LDAPディレクトリのJava(tm)オブジェクトを表すスキーマ |
|
RFC 2714 |
LDAPディレクトリのCORBAオブジェクト参照を表すスキーマ |
|
RFC 2739 |
vCardおよびLDAPのカレンダ属性 |
|
RFC 2788 |
ネットワーク・サービスのモニタリングMIB |
|
RFC 2798 |
inetOrgPerson LDAPオブジェクト・クラスの定義 |
|
RFC 2829 |
LDAPの認証方法 |
|
RFC 2830 |
Lightweight Directory Access Protocol (v3): トランスポート・レイヤー・セキュリティ用の拡張 |
|
RFC 2831 |
SASLメカニズムとしてのダイジェスト認証の使用 |
|
RFC 2849 |
The LDAP Data Interchange Format (LDIF) - 技術仕様 |
|
RFC 2891 |
検索結果のサーバー側ソートのためのLDAP制御拡張 |
|
RFC 2926 |
LDAPスキーマからSLPテンプレートへの変換およびその逆の変換 |
|
RFC 3045 |
ベンダー情報のLDAPルートDSEへの格納 |
|
RFC 3062 |
LDAPパスワード変更拡張操作 |
|
RFC 3112 |
LDAP認証のパスワード・スキーマ |
|
RFC 3174 |
USセキュア・ハッシュ・アルゴリズム1 (SHA1) |
|
RFC 3296 |
Lightweight Directory Access Protocol (LDAP)ディレクトリの名前付き従属参照 |
|
RFC 3377 |
Lightweight Directory Access Protocol (v3) |
|
RFC 3377 |
Lightweight Directory Access Protocol (v3): 技術仕様 |
|
RFC 3383 |
Lightweight Directory Access Protocol (LDAP)のInternet Assigned Numbers Authority (IANA)の考慮事項 |
|
RFC 3454 |
国際化文字列("stringprep")の準備 |
|
RFC 3546 |
トランスポート・レイヤー・セキュリティ(TLS)の拡張 |
|
RFC 3671 |
Collective Attributes in the Lightweight Directory Access Protocol(LDAP) |
|
RFC 3672 |
Lightweight Directory Access Protocol (LDAP)のサブエントリ |
|
RFC 3673 |
Lightweight Directory Access Protocolバージョン3 (LDAPv3): すべての操作属性 |
|
RFC 3674 |
Lightweight Directory Access Protocol (LDAP)の機能検索 |
|
RFC 3698 |
Lightweight Directory Access Protocol (LDAP): 追加の一致ルール |
|
RFC 3771 |
Lightweight Directory Access Protocol (LDAP)中間応答メッセージ |
|
RFC 3829 |
Lightweight Directory Access Protocol (LDAP)認可IDリクエストおよび応答の制御 |
|
RFC 3866 |
Lightweight Directory Access Protocol (LDAP)の言語タグおよび範囲 |
|
RFC 3876 |
Lightweight Directory Access Protocolバージョン3 (LDAPv3)を使用した一致する値の返送 |
|
RFC 3909 |
Lightweight Directory Access Protocol (LDAP)取消操作 |
|
RFC 4346 |
トランスポート・レイヤー・セキュリティ(TLS)プロトコル・バージョン1.1 |
|
RFC 4370 |
Lightweight Directory Access Protocol (LDAP)プロキシ設定された認可制御 |
|
RFC 4403 |
Universal Description, Discovery, and Integrationバージョン3 (UDDIv3)のLightweight Directory Access Protocol (LDAP)スキーマ |
|
RFC 4422 |
Simple Authentication and Security Layer(SASL) |
|
RFC 4505 |
匿名のSimple Authentication and Security Layer (SASL)メカニズム |
|
RFC 4510 |
Lightweight Directory Access Protocol (LDAP): 技術仕様のロード・マップ |
|
RFC 4511 |
Lightweight Directory Access Protocol (LDAP): プロトコル |
|
RFC 4512 |
Lightweight Directory Access Protocol (LDAP): ディレクトリ情報モデル |
|
RFC 4513 |
Lightweight Directory Access Protocol (LDAP): 認証メソッドおよびセキュリティ・メカニズム |
|
RFC 4514 |
Lightweight Directory Access Protocol (v3): 識別名のUTF-8文字列表現 |
|
RFC 4515 |
Lightweight Directory Access Protocol (LDAP): 検索フィルタの文字列表現 |
|
RFC 4516 |
Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator |
|
RFC 4517 |
Lightweight Directory Access Protocol (LDAP): 構文および一致ルール |
|
RFC 4518 |
Lightweight Directory Access Protocol (LDAP): 国際化された文字列の準備 |
|
RFC 4519 |
Lightweight Directory Access Protocol (LDAP): ユーザー・アプリケーションのスキーマ |
|
RFC 4520 |
Lightweight Directory Access Protocol (LDAP)のInternet Assigned Numbers Authority (IANA)の考慮事項 |
|
RFC 4522 |
Lightweight Directory Access Protocol (LDAP): バイナリ・エンコーディング・オプション |
|
RFC 4524 |
COSINE LDAP/X.500スキーマ |
|
RFC 4525 |
Lightweight Directory Access Protocol (LDAP)変更増分拡張 |
|
RFC 4526 |
Lightweight Directory Access Protocol (LDAP)の絶対Trueフィルタおよび絶対Falseフィルタ |
|
RFC 4527 |
Lightweight Directory Access Protocol (LDAP)読取りエントリ制御 |
|
RFC 4528 |
Lightweight Directory Access Protocol (LDAP)アサーション制御 |
|
RFC 4529 |
Lightweight Directory Access Protocol (LDAP)のオブジェクト・クラスによる属性のリクエスト |
|
RFC 4530 |
Lightweight Directory Access Protocol (LDAP) entryUUID操作属性 |
|
RFC 4532 |
Lightweight Directory Access Protocol (LDAP)「Who am I?」操作 |
|
RFC 4616 |
PLAIN Simple Authentication and Security Layer (SASL)メカニズム |
|
RFC 4634 |
USセキュア・ハッシュ・アルゴリズム(SHAおよびHMAC-SHA) |
|
RFC 4752 |
Kerberos V5 ("GSSAPI") SASLメカニズム |
|
RFC 5020 |
Lightweight Directory Access Protocol (LDAP) entryDN操作属性 |
|
RFC 5246 |
トランスポート・レイヤー・セキュリティ(TLS)プロトコル・バージョン1.2 |
A.3.2 Oracle Unified Directoryがサポートしているインターネット・ドラフト
Oracle Unified Directoryは、Internet Engineering Task Force (IETF)および他のインターネット・ドラフトをサポートしています。
表A-8は、Oracle Unified Directoryがサポートしているインターネット・ドラフトのリストです。
表A-8 Oracle Unified Directoryがサポートしているインターネット・ドラフト
| ドキュメント | 説明 |
|---|---|
|
draft-armijo-ldap-treedelete |
ツリー削除制御 |
|
draft-behera-ldap-password-policy |
LDAPディレクトリのパスワード・ポリシー |
|
draft-furuseth-ldap-untypedobject |
LDAP/X.500の構造型オブジェクト・クラス「untypedObject」 |
|
draft-good-ldap-changelog |
LDAP変更レコードを保持するためのオブジェクト・クラスの定義 |
|
draft-haripriya-dynamicgroup |
LDAP: LDAPv3のダイナミック・グループ |
|
draft-howard-namedobject |
任意の補助オブジェクト・クラスの構造型オブジェクト・クラス |
|
draft-howard-rfc2307bis |
ネットワーク情報サービスとしてLDAPを使用する方法 |
|
draft-ietf-boreham-numsubordinates |
numSubordinates LDAP操作属性 |
|
draft-ietf-ldapext-ldapv3-dupent |
検索結果の重複エントリ表現のLDAP制御 |
|
draft-ietf-ldapext-ldapv3-vlv |
検索結果のビュー・ブラウズをスクロールするLDAP拡張 |
|
draft-ietf-ldapext-psearch |
永続検索: 単純なLDAP変更通知メカニズム |
|
draft-ietf-ldup-subentry |
LDAPサブエントリ・スキーマ |
|
draft-ietf-sasl-crammd5 |
CRAM-MD5 SASLメカニズム |
|
draft-ietf-sasl-rfc2831bis |
SASLメカニズムとしてのダイジェスト認証の使用 |
|
draft-poitou-ldap-schema-update |
LDAPスキーマ更新手順 |
|
draft-sermersheim-ldap-subordinate-scope |
LDAPの従属サブツリー検索範囲 |
|
draft-vchu-ldap-pwd-policy |
LDAPディレクトリのパスワード・ポリシー |
|
draft-wahl-ldap-adminaddr |
LDAP管理者アドレス属性 |
|
draft-weltman-ldapv3-proxy |
LDAPのプロキシ設定された認可制御 |
|
draft-zeilenga-ldap-noop |
LDAP操作なし制御 |
|
draft-zeilenga-ldap-entrydn |
LDAP entryDN操作属性 |
A.3.3 Oracle Unified Directoryがサポートしているその他の仕様
Oracle Unified Directoryは、OASISディレクトリ・サービス・マークアップ言語v2.0の規格やセキュア・ハッシュの規格など、他の規格およびドキュメントをサポートしています。
表A-9は、Oracle Unified Directoryがサポートしているドキュメントおよび規格のリストです。
表A-9 Oracle Unified Directoryがサポートしているその他の仕様
| 番号 | 説明 |
|---|---|
|
DSMLv2.doc |
OASISディレクトリ・サービス・マークアップ言語v2.0のドキュメント |
|
DSMLv2.xsd |
OASISディレクトリ・サービス・マークアップ言語v2.0の規格 |
|
FIPS 180-1 |
セキュア・ハッシュの規格(SHA-1) |
|
FIPS 180-2 |
セキュア・ハッシュの規格(SHS) (FIPS PUB 180-2) |
A.3.4 Oracle Unified DirectoryがサポートしているTLSプロトコルおよび暗号スイート
TLSは、ネットワーク経由のデータ送信を伴うアプリケーションで現在広く使用されているプロトコルです。TLSプロトコルの主要目的は、通信している2つのアプリケーション間に強化されたセキュリティおよびデータの整合性を提供することです。
Oracle Unified Directoryは、Java Secure Socket Extension (JSSE)によって提供されるプロトコルおよび暗号スイートをサポートしています。この項では、次の項目について説明します。
A.3.4.1 Oracle Unified Directoryがサポートしているシステム・デフォルトのTLSプロトコル
Oracle Unified Directoryは、デフォルトで、TLSバージョン1.1プロトコルおよびTLSバージョン1.2プロトコルをサポートしています。
TLSバージョン1.2は、Oracle Unified DirectoryとのTLS通信の推奨プロトコルとなります。ただし、Oracle Unified DirectoryまたはOracle Unified Directoryが通信する必要があるリモート・サーバーとの接続を確立するクライアントが、TLSバージョン1.1のみをサポートし、TLSバージョン1.2をサポートしていない場合、TLSバージョン1.1プロトコルが使用されます。
A.3.4.2 Oracle Unified DirectoryがサポートしているTLS暗号スイート
TLSハンドシェイク時に、2つの通信相手間でネゴシエーションし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Unified Directoryは、Oracle Software Security Assurance標準で定義された暗号スイート(サポートされている暗号スイートとサポートされていない暗号スイートの両方)を実装します。
Oracle Unified Directoryでセキュアな通信を構成する場合、サーバーでは、TLSバージョン1.1またはTLSバージョン1.2プロトコル、およびGalois Counter Mode (GCM)のAESを使用してTLS 1.2で定義された新しい認証暗号化モードを持つ暗号のリストの使用がサポートされます。このように拡張されていても、Oracle Unified Directoryではレガシー・プラットフォームを使用するユーザーをサポートするために古い暗号スイートを使用できます。ただし、デフォルトで有効になっている暗号スイートを使用することをお薦めします。
Oracle Unified Directoryは、Java構成の最新の更新によって安全であるとみなされる多数の暗号スイートをサポートしています。この項の表では、Oracle Unified Directoryがサポートしている暗号スイートを優先順に示します。
ノート:
暗号スイートは、デプロイしたJVMでサポートされている場合にのみ有効になることに注意してください。表A-10 デフォルトで有効になっている暗号スイート
| TLSプロトコル | 暗号スイート |
|---|---|
| TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_RSA_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_RSA_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 |
| TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
| TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 |
| TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
| TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_RSA_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_RSA_WITH_AES_256_CBC_SHA256 |
| TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_256_CBC_SHA256 |
| TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 |
| TLSバージョン1.2 | TLS_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2 | TLS_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 |
| TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 |
| TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 |
| TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_256_CBC_SHA256 |
| TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 |
| TLSバージョン1.1 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.1 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.1 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.1 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.1 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
| TLSバージョン1.1 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.1 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
| TLSバージョン1.1 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.1 | TLS_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.1 | TLS_DH_DSS_WITH_AES_128_CBC_SHA |
| TLSバージョン1.1 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.1 | TLS_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.1 | TLS_DH_DSS_WITH_AES_256_CBC_SHA |
| TLSバージョン1.1 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2、TLSバージョン1.1 | TLS_DH_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2、TLSバージョン1.1 | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA |
| TLSバージョン1.2、TLSバージョン1.1 | TLS_DH_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2、TLSバージョン1.1 | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA |
| TLSバージョン1.2、TLSバージョン1.1 | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA |
| TLSバージョン1.2、TLSバージョン1.1 | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA |
| TLSバージョン1.2、TLSバージョン1.1 | TLS_RSA_WITH_3DES_EDE_CBC_SHA |
Oracle Unified Directoryは、デフォルトでJVMレベルで有効になっている暗号で、前述の表で示したリストに含まれていない暗号もサポートしています。これらの暗号スイートは、JVMバージョンおよびJVMベンダーによって異なります。次のリンクを参照して、Oracle JDKバージョン8でデフォルトで有効になっている暗号を確認できます。
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
次に、Oracle Unified Directoryでデフォルトで無効になっている暗号スイートのリストを示します。ただし、各種のOracle Unified DirectoryクライアントまたはサーバーのデプロイメントおよびCLIコンポーネントで、レガシーの理由から必要となる場合は、これらの暗号スイートを構成できます。
-
SSL_RSA_WITH_RC4_128_MD5
-
SSL_RSA_WITH_RC4_128_SHA
-
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
-
TLS_ECDHE_RSA_WITH_RC4_128_SHA
-
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
-
TLS_ECDH_RSA_WITH_RC4_128_SHA
-
SSL_RSA_WITH_3DES_EDE_CBC_SHA
-
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
A.3.4.3 JVM暗号スイートの構成
場合によっては、Oracle Unified Directoryのシステム・デフォルトのプロトコルと暗号を完全にオーバーライドするのではなく、追加することがあります。そのようなシナリオのために、Oracle Unified Directoryには、Oracle Unified Directoryのすべてのシステム・デフォルトの暗号スイートをカプセル化するjvmキーワードが備えられています。
新しい暗号スイート(SSL_DH_anon_WITH_DES_CBC_SHAなど)をOracle Unified Directoryのシステム・デフォルト・リストに追加する場合は、次の暗号スイートを指定できます。
jvm, SSL_DH_anon_WITH_DES_CBC_SHA
システムはjvmキーワードをシステム・デフォルトの暗号スイートに解決し、新しい暗号スイートSSL_DH_anon_WITH_DES_CBC_SHAをリストの最後に追加します。
jvmキーワードは、サーバー側コンポーネント(ssl-cipher-suiteプロパティを使用)とCLIツール(cipher_suite_sequenceプロパティを使用)の両方に使用できることに注意してください。
jvmキーワードを含むCLIツールのサンプル・プロパティ・ファイル:
tls_protocols=TLSv1.1,TLSv1 cipher_suite_sequence=TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,\ TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,\ TLS_DHE_RSA_WITH_AES_128_CBC_SHA,\ TLS_DHE_RSA_WITH_AES_256_CBC_SHA,\ jvm,\ SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,\ SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,\ SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,\ TLS_EMPTY_RENEGOTIATION_INFO_SCSV,\ SSL_DH_anon_WITH_DES_CBC_SHA,\ SSL_DH_anon_WITH_RC4_128_MD5
A.3.5 基本エンコーディング・ルールの概要
基本エンコーディング・ルール(BER)は、抽象構文表記法1エンコーディング・ルールのセットで、情報をバイナリ形式でエンコードする特定の方法を定義します。
BERは、メッセージをエンコードする基礎的なメカニズムとして使用されます。
この項では、次の項目について説明します。
A.3.5.1 基本エンコーディング・ルールの理解
多くのネットワーク・プロトコルはテキストベースで、ネットワークのトラフィックを調べる場合に比較的理解しやすいという利点があります。多くの場合、ターゲット・サーバーにtelnet接続して適切なコマンドを入力することによって、ターゲット・サーバーと対話することさえできます。
ただし、一般的に、必要以上に冗長で解析が非効率であることなど短所もあります。一方、その他のプロトコルでは、より簡潔で効率的なバイナリ・エンコーディングを使用しています。LDAPはこのカテゴリに属しており、ASN.1(抽象構文表記法1)メカニズム、具体的にはASN.1の種類であるBER(基本エンコーディング・ルール)を使用します。その他にもASN.1に含まれるエンコーディング・ルール(DER、PERおよびCERなど)がいくつかありますが、LDAPではBERを使用します。
この項では特にLDAPで使用されるBERのサブセットについて説明し、その他の場合については説明していません。
BER要素はTLV構造を使用し、TLVはタイプ(type)、長さ(length)および値(value)の略です。つまり、次の項で説明するとおり、各BER要素は、1バイト以上で示される要素のデータ・タイプ(通常LDAPでは1バイトのみ)、1バイト以上で示される値の長さ、0バイト以上の値自体のエンコードされた値(エンコードされた値の形式はデータ・タイプに依存)を保有します
A.3.5.2 BERタイプについて
BERタイプは要素の値のデータ・タイプを示します。
BERの仕様では数種類のデータ・タイプがありますが、LDAPで最も一般的に使用されるものにはOCTET STRING(テキスト文字列またはバイナリ・データのいずれも可能)、INTEGER、BOOLEAN、NULL、ENUMERATED (integerと似ているが、各値が特別な意味を保有)、SEQUENCE(配列のように、順序付けられたその他の要素の集合)およびSET(順序に意味を持たない点を除けばsequenceと同様)があります。CHOICE要素もありますが、通常、複数の異なる種類の要素のうち1つを許可します。
通常、BERタイプは1バイトのみで、このバイトにエンコードされたデータが含まれています。2つの最も重要なビット(一番左の2ビット、BERではビッグ・エンディアン/ネットワーク順序を使用するため)が、次のクラス値により、要素のクラスを示すために使用されます:
-
00
ユニバーサル・クラス。ほとんどのBER要素はユニバーサル・タイプを保有するため、ユニバーサル・タイプを保有する要素は保持するデータの種類を指定します。ユニバーサル・タイプの例には、0x01 (
BOOLEAN)、0x02 (INTEGER)、0x04 (OCTET STRING)、0x05 (NULL)、0x0A (ENUMERATED)、0x30 (SEQUENCE)および0x31 (SET)があります。これらのタイプの値すべてのバイナリ・エンコーディングで、一番左の2ビットを0に設定します。 -
01
アプリケーション固有クラス。このクラスは、アプリケーション全体を通して一貫性のある独自のタイプを、アプリケーションで定義できます。このコンテキストでは、LDAPはアプリケーションとみなされます。たとえば、LDAPで0x42が出現した場合は、アンバインド・リクエスト・プロトコルopを示します。なぜなら、RFC 2251の第4.3項(
https://tools.ietf.org/html/rfc2251#section-4.3)で説明されるように、アンバインド・リクエスト・プロトコルopには[APPLICATION 2]タイプがあるためです。 -
10
コンテキスト固有クラス。このクラスは、指定されたアプリケーション内の特定の使用方法に固有のタイプであることを示します。指定された状況で、適用するコンテキストを判断するための情報が十分であれば、同じタイプを同じアプリケーションの異なるコンテキストで再使用することもできます。たとえば、バインド・リクエスト・プロトコルopの資格証明のコンテキストで、コンテキスト固有のタイプ0x80がバインド・パスワードの保持に使用されますが、拡張操作のコンテキストでリクエストOIDの保持に同じタイプが使用される場合があります。
-
11
プライベート・クラス。LDAPでは通常使用されません。
次のビット(左から3番目)はプリミティブ/コンストラクテッド・ビットです。0(オフ)に設定されている場合は、その要素はプリミティブとみなされ、データ・タイプのルールに応じて値がエンコードされます。1(オン)に設定されている場合は、エンコードされた形式で一緒に連結された0個以上のほかのASN.1要素から、値が構築されることを意味します。たとえば、ユニバーサルSEQUENCEタイプの0x30の場合は、バイナリ・エンコーディングは00110000で、プリミティブ/コンストラクテッド・ビットは1に設定されており、sequenceの値が0個以上のエンコードされた要素から構築されることを示します。
BERタイプのバイトの最後の5ビットはそのタイプの値を指定し、単純な整数値として取り扱われます(00000は0、00001は1、00010は2、00011は3など)。唯一の特別な値は11111で、タイプの値が、使用可能な5ビットに収まらない大きな値であり、複数のバイトが必要であることを意味します。この値はLDAPでは使用されません。
A.3.5.3 BERの長さについて
BER要素のTLV構造で、2番目のコンポーネントは長さです。これは、エンコードされた値のサイズをバイト単位で指定します。
ほとんどの場合は、ここでは整数値のバイナリ・エンコーディングをそのまま使用します(たとえば、エンコードされた値が5バイト長の場合は、バイナリで00000101または16進数で0x05とエンコードされます)が、値が127バイトよりも長い場合は、長さのエンコーディングに複数のバイトが必要です。その場合、第1バイトの一番左のビットを1に設定し、残りの7ビットを長さ全体のエンコーディングに必要なバイト数を指定するために使用します。たとえば、500バイトの長さ(16進数で0x01F4)の場合は、エンコードされた長さは実際には次の3バイトで構成されます: 82 01 F4。
長さをエンコードするための別の形式として、いわゆる不特定形式があることに注意してください。このメカニズムでは、長さの一部のみが一度に指定され、HTTP 1.1で使用可能なチャンク・エンコーディングに似ています。ただし、RFC 2251第5.1項(https://tools.ietf.org/html/rfc2251#section-5.1)で説明されるように、LDAPではこの形式は使用されません。
A.3.5.4 BERの値について
BER要素には要素の実データが含まれます。BERはバイナリ・エンコーディングのため、このエンコーディングには、データを簡潔な形式で表現できるという利点があります。
したがって、各データ・タイプは、次のようにデータ・タイプ自体のエンコードされた形式を持っています:
-
NULL -
NULL要素には値がなく、そのため長さは常に0です。 -
OCTET STRING -
この要素の値は、表現するデータの未処理のバイトを連結したものとしてエンコードされます。たとえば、文字列
Helloを表すには、エンコードされた値は48 65 6C 6C 6Fになります。値の長さを0バイトにすることもできます。 -
BOOLEAN -
この要素の値は常に1バイトです。そのバイトのすべてのビットが0 (0x00)に設定されている場合は、値は
FALSEです。1つ以上のビットが1に設定されている場合は、値はTRUEです。その結果、TRUEのBOOLEAN値をエンコードする方法が255通りありますが、実際には、通常0xFF(つまりすべてのビットを1に設定)としてエンコードされます。 -
INTEGER -
この要素の値は、2の補数形式のバイナリ整数としてエンコードされます。BER自体はエンコードできる値の大きさに制限を設けていませんが、多くのソフトウェアの実装では4バイトまたは8バイト(つまり32ビットまたは64ビットの整数値)の制限があり、通常LDAPでは最大4バイトを使用します(プラスマイナス20億の範囲で値をエンコードできます)。値には常に少なくとも1バイトがあります。
-
ENUMERATED -
この要素の値は、
INTEGER要素の値とまったく同じ方法でエンコードされます。 -
SEQUENCE -
この要素の値は、sequenceに含まれるエンコードされたBER要素を単純に連結したものです。たとえば、テキスト
Helloおよびthereをエンコードする2つのオクテット文字列要素を持つsequenceをエンコードすると、エンコードされたsequence値は04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65です。sequenceに要素がない場合は、sequence値は0バイトになります。 -
SET -
この要素の値は、
SEQUENCE要素の値とまったく同じ方法でエンコードされます。
A.3.5.5 BERエンコーディングの使用例
2つの完全なBER要素が連結された次のSEQUENCE値のエンコーディングの例を確認してください。文字列HelloおよびthereのOCTET STRING表現は次のとおりです。
04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65
どちらのケースでも、最初のバイトはタイプ(0x04、ユニバーサル・プリミティブOCTET STRINGタイプ)で、2番目のバイトは長さ(0x05、値が5バイトであることを示す)です。残りの5バイトは文字列Helloおよびthereをエンコードした表現です。
次の例では、ユニバーサルINTEGERタイプのかわりにコンテキスト固有のタイプ値である5を使用して、整数値3をエンコードします:
85 01 03
次の例では、RFC 2251第4.2項(https://tools.ietf.org/html/rfc2251#section-4.2)で定義されるLDAPバインド・リクエスト・プロトコルopをエンコードします。この要素の簡易BNF表現は次のとおりです:
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name OCTET STRING,
authentication CHOICE {
simple [0] OCTET STRING,
sasl [3] SEQUENCE {
mechanism OCTET STRING,
credentials OCTET STRING OPTIONAL } } }
この例では、パスワードpasswordを持つユーザーcn=testに対する簡易認証を使用したバインド・リクエストをエンコードします。このバインド・リクエスト・プロトコルopの完成したエンコーディングは次のとおりです:
60 16 02 01 03 04 07 63 6E 3D 74 65 73 74 80 08 70 61 73 73 77 6F 72 64
分析すると、このバイト文字列には次の情報が含まれています:
-
最初のバイトは0x60で、バインド・リクエスト・プロトコルopのBERタイプです。定義の一部である
[APPLICATION 0] SEQUENCEに由来します。アプリケーション固有であることから、クラス・バイトは01、SEQUENCEであることから、コンストラクテッドです。タイプ値0と合せると、バイナリ表現では01100000、16進数では0x60です。 -
2番目のバイトは0x16で、バインド・リクエスト・シーケンスの長さを示しています。16進数0x16は10進数の22で、0x16の後のバイト数は22です。
-
次の3バイトは
02 01 03で、3のユニバーサルINTEGER値です。バインド・リクエスト・シーケンスのバージョン・コンポーネントに対応し、LDAPv3バインド・リクエストであることを示しています。 -
次の9バイトは
04 07 63 6E 3D 74 65 73 74で、テキストcn=testを含むユニバーサルOCTET STRINGです。バインド・リクエスト・シーケンスの名前コンポーネントに対応しています。 -
最後のコンポーネントは
80 08 70 61 73 73 77 6F 72 64で、タイプcontext-specific primitive 0、長さ8バイトの要素です。バインド・リクエスト・プロトコルopの定義の説明に従って、context-specificは簡易認証タイプにマップされ、OCTET STRINGとして取り扱う必要があります。値の8バイトはエンコードされた文字列passwordを表します。
A.3.6 CRAM-MD5 SASLメカニズムを使用した認証
CRAM-MD5 Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。クリアテキスト・パスワードを公開しない方法であるため、クライアントとサーバーの間の接続が保護されていない場合は、簡易認証またはPLAIN SASLメカニズムよりも安全性に優れています。
draft-ietf-sasl-crammd5-10 (http://tools.ietf.org/html/draft-ietf-sasl-crammd5-10)インターネット・ドラフトにCRAM-MD5 SASLメカニズムについて記載されています。このプロセスは、次のとおりです。
- クライアントは、メカニズム名がCRAM-MD5で資格証明なしの認証タイプSASLを使用して、バインド・リクエスト・
プロトコルopタイプを含むメッセージをサーバーへ送信します。 - サーバーは、結果コード14 (SASLバインドが進行中です)およびランダムに生成されたデータ(challenge)を含むサーバーSASL資格証明要素とともにバインド・レスポンス・メッセージをクライアントに返信します。
- クライアントは、メカニズム名
CRAM-M5を使用して、2番目のSASLバインド・リクエスト・メッセージに応じてサーバーに応答します。今回は、ユーザーを識別するために使用される認証IDを含むSASL資格証明、およびサーバーから送られたchallengeとクリアテキスト・パスワードを組み合せて計算されたMD5ダイジェストを提供します。 - サーバーは認証IDを使用してユーザーを識別し、そのユーザー用のクリアテキスト・パスワードを取得して(クリアテキスト・パスワードを取得できない場合は、認証は失敗します)、指定されたダイジェストが有効かどうかを判断するために使用します。サーバーは、認証が成功したかどうかを示す適切なレスポンスを(通常
successまたはinvalid credentialsの結果とともに)クライアントに送信します。
CRAM-MD5 SASLメカニズムはDIGEST-MD5 SASLメカニズムとよく似ていますが、DIGEST-MD5がクライアントとサーバーの両方からのランダム・データを含めるのに対して、CRAM-MD5はサーバーからのみであるため、多少脆弱です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。