A.3 Standards and Specifications Supported by Oracle Unified Directory
A.3.1 RFCs Supported by Oracle Unified Directory
Oracle Unified Directory is continuously being updated to ensure that it conforms to the newer protocols.
Table A-7 contains a list of the RFCs currently supported by Oracle Unified Directory.
Table A-7 Supported RFCs
Number | Description |
---|---|
RFC 1274 |
The COSINE and Internet X.500 Schema |
RFC 1321 |
The MD5 Message-Digest Algorithm |
RFC 1777 |
Lightweight Directory Access Protocol (v2) |
RFC 1778 |
The String Representation of Standard Attribute Syntaxes |
RFC 1779 |
A String Representation of Distinguished Names |
RFC 2079 |
Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) |
RFC 2222 |
Simple Authentication and Security Layer (SASL) |
RFC 2246 |
The TLS Protocol |
RFC 2246 |
The TLS Protocol Version 1.0 |
RFC 2247 |
Using Domains in LDAP/X.500 Distinguished Names |
RFC 2251 |
Lightweight Directory Access Protocol (v3) |
RFC 2252 |
Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions |
RFC 2254 |
The String Representation of LDAP Search Filters |
RFC 2255 |
The LDAP URL Format |
RFC 2256 |
A Summary of the X.500(96) User Schema for use with LDAPv3 |
RFC 2377 |
Naming Plan for Internet Directory-Enabled Applications |
RFC 2605 |
Directory Server Monitoring MIB |
RFC 2649 |
An LDAP Control and Schema for Holding Operation Signatures |
RFC 2696 |
LDAP Control Extension for Simple Paged Results Manipulation |
RFC 2713 |
Schema for Representing Java(tm) Objects in an LDAP Directory |
RFC 2714 |
Schema for Representing CORBA Object References in an LDAP Directory |
RFC 2739 |
Calendar Attributes for vCard and LDAP |
RFC 2788 |
Network Services Monitoring MIB |
RFC 2798 |
Definition of the inetOrgPerson LDAP Object Class |
RFC 2829 |
Authentication Methods for LDAP |
RFC 2830 |
Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
RFC 2831 |
Using Digest Authentication as a SASL Mechanism |
RFC 2849 |
The LDAP Data Interchange Format (LDIF) - Technical Specification |
RFC 2891 |
LDAP Control Extension for Server Side Sorting of Search Results |
RFC 2926 |
Conversion of LDAP Schemas to and from SLP Templates |
RFC 3045 |
Storing Vendor Information in the LDAP root DSE |
RFC 3062 |
LDAP Password Modify Extended Operation |
RFC 3112 |
LDAP Authentication Password Schema |
RFC 3174 |
US Secure Hash Algorithm 1 (SHA1) |
RFC 3296 |
Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories |
RFC 3377 |
Lightweight Directory Access Protocol (v3) |
RFC 3377 |
Lightweight Directory Access Protocol (v3): Technical Specification |
RFC 3383 |
Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
RFC 3454 |
Preparation of Internationalized Strings ("stringprep") |
RFC 3546 |
Transport Layer Security (TLS) Extensions |
RFC 3671 |
Collective Attributes in the Lightweight Directory Access Protocol (LDAP) |
RFC 3672 |
Subentries in the Lightweight Directory Access Protocol (LDAP) |
RFC 3673 |
Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes |
RFC 3674 |
Feature Discovery in Lightweight Directory Access Protocol (LDAP) |
RFC 3698 |
Lightweight Directory Access Protocol (LDAP): Additional Matching Rules |
RFC 3771 |
Lightweight Directory Access Protocol (LDAP) Intermediate Response Message |
RFC 3829 |
Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls |
RFC 3866 |
Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP) |
RFC 3876 |
Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3) |
RFC 3909 |
Lightweight Directory Access Protocol (LDAP) Cancel Operation |
RFC 4346 |
The Transport Layer Security (TLS) Protocol Version 1.1 |
RFC 4370 |
Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control |
RFC 4403 |
Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) |
RFC 4422 |
Simple Authentication and Security Layer (SASL) |
RFC 4505 |
Anonymous Simple Authentication and Security Layer (SASL) Mechanism |
RFC 4510 |
Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map |
RFC 4511 |
Lightweight Directory Access Protocol (LDAP): The Protocol |
RFC 4512 |
Lightweight Directory Access Protocol (LDAP): Directory Information Models |
RFC 4513 |
Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms |
RFC 4514 |
Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names |
RFC 4515 |
Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters |
RFC 4516 |
Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator |
RFC 4517 |
Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules |
RFC 4518 |
Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation |
RFC 4519 |
Lightweight Directory Access Protocol (LDAP): Schema for User Applications |
RFC 4520 |
Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
RFC 4522 |
Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option |
RFC 4524 |
COSINE LDAP/X.500 Schema |
RFC 4525 |
Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension |
RFC 4526 |
Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters |
RFC 4527 |
Lightweight Directory Access Protocol (LDAP) Read Entry Controls |
RFC 4528 |
Lightweight Directory Access Protocol (LDAP) Assertion Control |
RFC 4529 |
Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP) |
RFC 4530 |
Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute |
RFC 4532 |
Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation |
RFC 4616 |
The PLAIN Simple Authentication and Security Layer (SASL) Mechanism |
RFC 4634 |
US Secure Hash Algorithms (SHA and HMAC-SHA) |
RFC 4752 |
The Kerberos V5 ("GSSAPI") SASL Mechanism |
RFC 5020 |
The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute |
RFC 5246 |
The Transport Layer Security (TLS) Protocol Version 1.2 |
A.3.2 Internet Drafts Supported by Oracle Unified Directory
Oracle Unified Directory supports the Internet Engineering Task Force (IETF) and other internet drafts.
Table A-8 contains a list of Internet drafts supported by Oracle Unified Directory.
Table A-8 Internet Drafts Supported by Oracle Unified Directory
Document | Description |
---|---|
draft-armijo-ldap-treedelete |
Tree Delete Control |
draft-behera-ldap-password-policy |
Password Policy for LDAP Directories |
draft-furuseth-ldap-untypedobject |
Structural object class 'untypedObject' for LDAP/X.500 |
draft-good-ldap-changelog |
Definition of an Object Class to Hold LDAP Change Records |
draft-haripriya-dynamicgroup |
LDAP: Dynamic Groups for LDAPv3 |
draft-howard-namedobject |
A Structural Object Class for Arbitrary Auxiliary Object Classes |
draft-howard-rfc2307bis |
An Approach for Using LDAP as a Network Information Service |
draft-ietf-boreham-numsubordinates |
numSubordinates LDAP Operational Attribute |
draft-ietf-ldapext-ldapv3-dupent |
LDAP Control for a Duplicate Entry Representation of Search Results |
draft-ietf-ldapext-ldapv3-vlv |
LDAP Extensions for Scrolling View Browsing of Search Results |
draft-ietf-ldapext-psearch |
Persistent Search: A Simple LDAP Change Notification Mechanism |
draft-ietf-ldup-subentry |
LDAP Subentry Schema |
draft-ietf-sasl-crammd5 |
The CRAM-MD5 SASL Mechanism |
draft-ietf-sasl-rfc2831bis |
Using Digest Authentication as a SASL Mechanism |
draft-poitou-ldap-schema-update |
LDAP Schema Update Procedures |
draft-sermersheim-ldap-subordinate-scope |
Subordinate Subtree Search Scope for LDAP |
draft-vchu-ldap-pwd-policy |
Password Policy for LDAP Directories |
draft-wahl-ldap-adminaddr |
LDAP Administrator Address Attribute |
draft-weltman-ldapv3-proxy |
LDAP Proxied Authorization Control |
draft-zeilenga-ldap-noop |
The LDAP No-Op Control |
draft-zeilenga-ldap-entrydn |
The LDAP entryDN Operational Attribute |
A.3.3 Other Specifications Supported by Oracle Unified Directory
Oracle Unified Directory supports other standards and documents like the OASIS Directory Services Markup Language v2.0 and Secure Hash Standard.
Table A-9 contains a list of documents and standards supported by Oracle Unified Directory.
Table A-9 Other Specifications Supported by Oracle Unified Directory
Number | Description |
---|---|
DSMLv2.doc |
OASIS Directory Services Markup Language v2.0 Documentation |
DSMLv2.xsd |
OASIS Directory Services Markup Language v2.0 Standard |
FIPS 180-1 |
Secure Hash Standard (SHA-1) |
FIPS 180-2 |
Secure Hash Standard (SHS) (FIPS PUB 180-2) |
A.3.4 Enabling FIPS Mode on OUD
The Federal Information Processing Standards (FIPS) 140-2 is a standard that describes U.S. Federal government requirements for sensitive but unclassified use.
To enable FIPS mode on OUD, review the following topics:
A.3.4.1 Enabling FIPS Mode on OUD Server
Learn how to enable FIPS 140-2 mode in OUD Server.
To enable FIPS mode on OUD server:
Note:
-
As a prerequisite, OUD server must be installed and configured with a correct version of JDK.
-
See Enabling FIPS 140-2 Mode From Java Options in Administering Security for Oracle WebLogic Server for detailed steps.
- Update java security file of the JDK instance referred by your IDM WebLogic domain, as follows:
Note:
You can obtain
JAVA_HOME
reference from theSetDomainEnv
script.- Add RSA Security Provider to the top of the security file
JAVA_HOME
/jre/lib/security/java.security
. - update the sequence number for the remaining providers, as shown:
security.provider.1=com.rsa.jsafe.provider.JsafeJCE security.provider.2=com.rsa.jsse.JsseProvider
- Add RSA Security Provider to the top of the security file
- Update WLS Pre-ClassPath Setting with FIPS specific jars. To do so:
- Set WLS
PRE_CLASSPATH
variable to point tojcmFips.jar
andsslj.jar
, which is in theWL_HOME
/server/lib/
directory. - Export
PRE_CLASSPATH
by adding an entry in thesetDomainEnv.sh
script, which is in theDOMAIN_HOME
/bin/
directory. The following is a sample entry:PRE_CLASSPATH="WLS_HOME/server/lib/jcmFIPS.jar:WLS_HOME/server/lib/sslj.jar" export PRE_CLASSPATH
Here, replace WLS_HOME with the absolute path of WLS_HOME in your environment after confirming that
jcmFIPS.jar
andsslj.jar
exists in the location specified. This will set the PRE_CLASSPATH variable for the entire WLS Domain.
- Set WLS
- Restart the WebLogic Administrative Server and all Managed Servers.
A.3.4.2 Enabling FIPS Mode on OUD Standalone Server
Learn how to enable FIPS mode on OUD standalone server.
To enable FIPS mode on OUD standalone server:
Note:
-
As a prerequisite, OUD server must be installed and configured with a correct version of JDK.
-
See Enabling FIPS 140-2 Mode From Java Options in Administering Security for Oracle WebLogic Server for detailed steps.
- Update Java security file of the JDK instance referred by your OUD JDK, as follows:
- Add RSA Security Provider to the top of the security file
JAVA_HOME
/jre/lib/security/java.security
. - update the sequence number for the remaining providers, as shown:
security.provider.1=com.rsa.jsafe.provider.JsafeJCE security.provider.2=com.rsa.jsse.JsseProvider
- Add RSA Security Provider to the top of the security file
- Update ClassPath Setting with FIPS specific jars. To do so:
- Set
CLASSPATH
variable to point tojcmFips.jar
andsslj.jar
, which is in theWL_HOME
/server/lib/
directory of any existing WLS installation. - Export
CLASSPATH
. The following is a sample entry:CLASSPATH="WLS_HOME/server/lib/jcmFIPS.jar:WLS_HOME/server/lib/sslj.jar" export CLASSPATH
Here, replace WLS_HOME with the absolute path of
WLS_HOME
of any existing WLS installation.
- Set
A.3.5 Supported TLS Protocols and Cipher Suites by Oracle Unified Directory
TLS is a widely used protocol today by applications that entails data transmission over a network. The primary goal of the TLS protocol is to provide enhanced security and data integrity between two communicating applications.
Oracle Unified Directory supports protocols and cipher suites provided by Java Secure Socket Extension (JSSE). This section contains the following topics:
A.3.5.1 Supported System Default TLS Protocols by Oracle Unified Directory
Oracle Unified Directory supports TLS version 1.1 and TLS version 1.2 protocols by default. Oracle Unified Directory supports TLS version 1.3
TLS version 1.2 is the preferred protocol for TLS communication with Oracle Unified Directory. However, if a client establishing connection with Oracle Unified Directory or a remote server with which Oracle Unified Directory needs to communicate, supports only TLS version 1.1 and not TLS version 1.2, then TLS version 1.1 protocol will be used.
A.3.5.2 Supported TLS Cipher Suites by Oracle Unified Directory
During a TLS handshake, the two communicating parties negotiate to determine which cipher suite they will use while transmitting messages back and forth.
Oracle Unified Directory implements the cipher suites (both the supported and the non-supported cipher suites) defined by the Oracle Software Security Assurance standards.
When you configure Oracle Unified Directory for secure communication, the server supports the use of TLS version 1.1 or TLS version 1.2 protocols and a list of ciphers with new authenticated encryption modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM). Despite the enhancements, Oracle Unified Directory allows you to use older cipher suites to support users working on legacy platforms. However, it is recommended that you use stronger cipher suites.
Oracle Unified Directory supports a large number of cipher suites that are considered secure by the latest update of Java configuration. The tables in this section lists the cipher suites supported by Oracle Unified Directory in preference order.
Note:
You must note that the any cipher suite is only enabled if it is supported by the JVM you have deployed.Table A-10 Default Enabled Cipher Suites
TLS Protocol | Cipher Suite |
---|---|
TLS version 1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_RSA_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_RSA_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 |
TLS version 1.2 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
TLS version 1.2 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 |
TLS version 1.2 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
TLS version 1.2 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
TLS version 1.2 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
TLS version 1.2 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
TLS version 1.2 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.2 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
TLS version 1.2 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.2 | TLS_DH_DSS_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_DH_DSS_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_RSA_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_DH_DSS_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_RSA_WITH_AES_256_CBC_SHA256 |
TLS version 1.2 | TLS_DH_DSS_WITH_AES_256_CBC_SHA256 |
TLS version 1.2 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 |
TLS version 1.2 | TLS_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.2 | TLS_DH_DSS_WITH_AES_128_CBC_SHA |
TLS version 1.2 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
TLS version 1.2 | TLS_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.2 | TLS_DH_DSS_WITH_AES_256_CBC_SHA |
TLS version 1.2 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
TLS version 1.2 | TLS_DH_RSA_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 |
TLS version 1.2 | TLS_DH_RSA_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 |
TLS version 1.2 | TLS_DH_RSA_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 |
TLS version 1.2 | TLS_DH_RSA_WITH_AES_256_CBC_SHA256 |
TLS version 1.2 | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 |
TLS version 1.1 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.1 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
TLS version 1.1 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.1 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
TLS version 1.1 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
TLS version 1.1 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.1 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
TLS version 1.1 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.1 | TLS_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.1 | TLS_DH_DSS_WITH_AES_128_CBC_SHA |
TLS version 1.1 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
TLS version 1.1 | TLS_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.1 | TLS_DH_DSS_WITH_AES_256_CBC_SHA |
TLS version 1.1 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
TLS version 1.2, TLS version 1.1 | TLS_DH_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.2, TLS version 1.1 | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA |
TLS version 1.2, TLS version 1.1 | TLS_DH_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.2, TLS version 1.1 | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA |
TLS version 1.2, TLS version 1.1 | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA |
TLS version 1.2, TLS version 1.1 | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA |
TLS version 1.2, TLS version 1.1 | TLS_RSA_WITH_3DES_EDE_CBC_SHA |
Oracle Unified Directory also supports the ciphers which are enabled by default at the JVM level, but are not a part of the list described in the preceding table. These cipher suites would vary between different JVM versions and different JVM vendors. You can refer to the following link to view the default enabled ciphers on Oracle JDK version 8:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
The following is a list of cipher suites that are disabled by default in Oracle Unified Directory. However, you can configure these cipher suites if needed for various Oracle Unified Directory client/server deployments and CLI components for legacy reasons.
-
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.5.3 Configuring JVM Cipher Suite
In some cases, you want to add to the Oracle Unified Directory system default protocols and ciphers, instead of completely overriding them. For such scenarios, Oracle Unified Directory provides a jvm
keyword, which encapsulates all the Oracle Unified Directory system default cipher suites.
If you want to add a new cipher suite, for instance SSL_DH_anon_WITH_DES_CBC_SHA
to the Oracle Unified Directory system default list, then you can specify the following cipher suites:
jvm, SSL_DH_anon_WITH_DES_CBC_SHA
The system will resolve the jvm
keyword to system default cipher suites, and then add the new cipher suite SSL_DH_anon_WITH_DES_CBC_SHA
at the end of the list.
Note that the jvm
keyword can be used for both server side components (using ssl-cipher-suite
property) and CLI tools (using cipher_suite_sequence
property).
Sample properties files for CLI tools, which include the jvm
keyword:
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.6 Overview of Basic Encoding Rules
The Basic Encoding Rules (BER) are a set of Abstract Syntax Notation One encoding rules that define a specific way in which information may be encoded in a binary form.
BER is used as the underlying mechanism for encoding message.
This section contains the following topics:
A.3.6.1 Understanding Basic Encoding Rules
Many network protocols are text-based, which has the advantages of being relatively easy to understand if you examine the network traffic, and you can often even interact with the target server by telnetting to it and typing in the appropriate commands.
However, there are disadvantages as well, including that they are generally more verbose and less efficient to parse than they need to be. On the other hand, other protocols use a binary encoding that is more compact and more efficient. LDAP falls into this category, and uses the ASN.1 (abstract syntax notation one) mechanism, and more specifically the BER (basic encoding rules) flavor of ASN.1. There are several other encoding rules (such as DER, PER, and CER) that fall under the ASN.1 umbrella, but LDAP uses BER.
This section discusses the subset of BER that is used by LDAP in particular and does not address other cases.
BER elements use a TLV structure, where TLV stands for "type", "length", and "value". That is, each BER element has one or more bytes (in LDAP, typically only a single byte) that indicates the data type for the element, one or more bytes that indicate the length of the value, and the encoded value itself (where the form of the encoded value depends on the data type), which can be zero or more bytes, as described in the following sections.
A.3.6.2 About BER Type
The BER type indicates the data type for the value of the element.
The BER specification provides several different data types, but the most commonly used by LDAP include OCTET STRING
(which can be either a text string or just some binary data), INTEGER
, BOOLEAN
, NULL
, ENUMERATED
(like an integer, but where each value has a special meaning), SEQUENCE
(an ordered collection of other elements, similar to an array), and SET
(the same as a sequence, except that the order does not matter). There is also a CHOICE
element, but it typically allows one of a few different kinds of elements.
The BER type is typically only a single byte, and this byte has data encoded in it. The two most significant bits (the two leftmost bits, because BER uses big endian/network ordering) are used to indicate the class for the element, using these possible class values:
-
00
The universal class. Most BER elements have a universal type, so any element with a universal type specifies what kind of data it holds. Examples of universal types include 0x01 (
BOOLEAN
), 0x02 (INTEGER
), 0x04 (OCTET STRING
), 0x05 (NULL
), 0x0A (ENUMERATED
), 0x30 (SEQUENCE
), and 0x31 (SET
). The binary encodings for all of those type values have the leftmost two bits set to zero. -
01
The application-specific class. This class allows an application to define its own types that are consistent throughout that application. In this context, LDAP is considered an application. For example, when 0x42 appears in LDAP, it indicates an unbind request protocol op, because RFC 2251 section 4.3 (
https://tools.ietf.org/html/rfc2251#section-4.3
) states that the unbind request protocol op has a type of[APPLICATION 2]
. -
10
The context-specific class. This class indicates that the type is specific to a particular usage within a given application. You can reuse the same type in different contexts within the same application if there is enough other information to determine which context is applicable in a given situation. For example, in the context of the credentials in a bind request protocol op, the context-specific type 0x80 is used to hold the bind password, but in the context of an extended operation it would be used to hold the request OID.
-
11
The private class, not typically used in LDAP.
The next bit (the third from the left) is the primitive/constructed bit. If it is set to zero (off), then the element is considered primitive, and the value is encoded in accordance with the rules of that data type. If it is set to one (on), then it means that the value is constructed from zero or more other ASN.1 elements that are concatenated together in their encoded forms. For example, for the universal SEQUENCE
type of 0x30, the binary encoding is 00110000
and the primitive/constructed bit is set to one indicating that the value of the sequence is constructed from zero or more encoded elements.
The final five bits of the BER type byte specify the value of that type, and they are treated as a simple integer value (where 00000
is zero, 00001
is one, 00010
is two, 00011
is three, and so on). The only special value is 11111
, which means that the type value is larger than can fit in the five bits allowed, and so multiple bytes are required. This value is not used in LDAP.
A.3.6.3 About BER Length
The second component in the TLV structure of a BER element is the length. This specifies the size in bytes of the encoded value.
For the most part, this uses a straightforward binary encoding of the integer value (for example, if the encoded value is five bytes long, then it is encoded as 00000101 binary, or 0x05 hex), but if the value is longer than 127 bytes then it is necessary to use multiple bytes to encode the length. In that case, the first byte has the leftmost bit set to one and the remaining seven bits are used to specify the number of bytes required to encode the full length. For example, if there are 500 bytes in the length (hex 0x01F4), then the encoded length will actually consist of three bytes: 82 01 F4
.
Be aware that there is an alternate form for encoding the length called the indefinite form. In this mechanism, only a part of the length is given at a time, similar to the chunked encoding that is available in HTTP 1.1. However, this form is not used in LDAP, as specified in RFC 2251 section 5.1 (https://tools.ietf.org/html/rfc2251#section-5.1
).
A.3.6.4 About BER Value
The BER element contains the actual data of the element. Because BER is a binary encoding, the encodings can take advantage of that to represent the data in a compact form.
As such, each data type has its own encoded form:
-
NULL
-
The
NULL
element never has a value, and therefore the length is always zero. -
OCTET STRING
-
The value of this element is encoded as a concatenation of the raw bytes of the data being represented. For example, to represent the string
Hello
, the encoded value would be48 65 6C 6C 6F
. The value can have a length of zero bytes. -
BOOLEAN
-
The value of this element is always a single byte. If all the bits in that byte are set to zero (0x00), then the value is
FALSE
. If one or more of the bytes is set to one, then the value isTRUE
. As a result, there are 255 different ways to encode aBOOLEAN
value ofTRUE
, but in practice it is generally encoded as 0xFF (that is, all the bits are set to one). -
INTEGER
-
The value of this element is encoded as a binary integer in two's complement form. Although BER itself does not place a limit on the magnitude of the values that can be encoded, many software implementations have a cap of four or eight bytes (that is, 32-bit or 64-bit integer values), and LDAP generally uses a maximum of 4 bytes (which allows encoding values within the plus or minus 2 billion range). There is always at least one byte in the value.
-
ENUMERATED
-
The value of this element is encoded in exactly the same way as the value of an
INTEGER
element. -
SEQUENCE
-
The value of this element is simply a concatenation of the encoded BER elements contained in the sequence. For example, to encode a sequence with two octet string elements encoding the text
Hello
andthere
, the encoded sequence value is04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65
. A sequence value can be zero bytes if there are no elements in the sequence. -
SET
-
The value of this element is encoded in exactly the same way as the value of a
SEQUENCE
element.
A.3.6.5 Examples of Using BER Encoding
Review this example for encoding a SEQUENCE
value had two complete BER elements concatenated together: the OCTET STRING
representations of the strings Hello
and there
.
04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65
In both of these cases, the first byte is the type (0x04, which is the universal primitive OCTET STRING
type), and the second is the length (0x05, indicating that there are five bytes in the value). The remaining five bytes are the encoded representations of the strings Hello
and there
.
The following example encodes the integer value 3
using a context-specific type value of 5
instead of the universal INTEGER
type:
85 01 03
The next example encodes an LDAP bind request protocol op as defined in RFC 2251 section 4.2 (https://tools.ietf.org/html/rfc2251#section-4.2
). A simplified BNF representation of this element is as follows:
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 } } }
This example encodes a bind request using simple authentication for the user cn=test
with a password of password
. The complete encoding for this bind request protocol op is:
60 16 02 01 03 04 07 63 6E 3D 74 65 73 74 80 08 70 61 73 73 77 6F 72 64
In analysis, that string of bytes contains the following information:
-
The first byte is 0x60 and it is the BER type for the bind request protocol op. It comes from the
[APPLICATION 0] SEQUENCE
portion of the definition. Because it is application-specific, then the class bytes are01
, and because it is aSEQUENCE
, it is constructed. Put that together with a type value of zero, the binary representation is01100000
, which is 0x60 hex. -
The second byte is 0x16, which indicates the length of the bind request sequence. 0x16 hex is 22 decimal, and the number of bytes after the 0x16 is 22.
-
The next three bytes are
02 01 03
, which is a universalINTEGER
value of3
. It corresponds to the version component of the bind request sequence, and it indicates that this is an LDAPv3 bind request. -
The next nine bytes are
04 07 63 6E 3D 74 65 73 74
, which is a universalOCTET STRING
containing the textcn=test
. It corresponds to the "name" component of the bind request sequence. -
The last component is
80 08 70 61 73 73 77 6F 72 64
, which is an element with a type ofcontext-specific primitive 0
and a length of eight bytes. As specified in the definition of the bind request protocol op,context-specific
maps to the simple authentication type and that it should be treated as anOCTET STRING
, and those eight bytes in the value do represent the encoded stringpassword
.
A.3.7 Authenticating Using CRAM-MD5 SASL Mechanism
The CRAM-MD5 Simple Authentication and Security Layer mechanism provides a way for clients to authentication to the Directory Server with a username and password in a manner that does not expose the clear-text password, so it is significantly safer than simple authentication or the PLAIN SASL mechanism when the connection between the client and the server is not secure.
The draft-ietf-sasl-crammd5-10 (http://tools.ietf.org/html/draft-ietf-sasl-crammd5-10
) Internet Draft describes the CRAM-MD5 SASL mechanism. The process is as follows:
- The client sends an message to the server with a bind request protocol op type using an authentication type of
SASL
with a mechanism name ofCRAM-MD5
and no credentials. - The server sends a bind response message back to the client with a result code of 14 (SASL bind in progress) and a server SASL credentials element including randomly-generated data (the challenge).
- The client responds with a second SASL bind request message to the server with a mechanism name of
CRAM-M5
, and this time provides SASL credentials containing the authentication ID used to identify the user and an MD5 digest that is computed by combining the server-provided challenge with the clear-text password. - The server uses the authentication ID to identify the user, and then retrieves the clear-text password for that user (if the clear-text password cannot be obtained, then authentication will fail) and uses it to determine whether the provided digest is valid. The server will then send an appropriate response to the client (usually with a result of either
success
orinvalid credentials
) indicating whether the authentication was successful.
The CRAM-MD5 SASL mechanism is very similar to DIGEST-MD5 SASL mechanism, but it is somewhat weaker because CRAM-MD5 only includes random data from the server whereas DIGEST-MD5 includes random data from both the client and the server. DIGEST-MD5 also provides a provision for ensuring connection integrity, confidentiality, or both that CRAM-MD5 does not offer.