1. Administering Oracle Unified Directory
  2. Appendixes and Glossary
  3. Standards and Specifications Supported by Oracle Unified Directory

A.3 Standards and Specifications Supported by Oracle Unified Directory

Oracle Unified Directory supports various standards and specifications, such as RFCs, internet drafts, protocols, and cipher suites.

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 2307

An Approach for Using LDAP as a Network Information Service

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 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.4.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.

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.4.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 the cipher suites that are enabled by default.

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.4.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.5 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.5.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.5.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.5.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.5.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 be 48 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 is TRUE. As a result, there are 255 different ways to encode a BOOLEAN value of TRUE, 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 and there, the encoded sequence value is 04 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.5.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 are 01, and because it is a SEQUENCE, it is constructed. Put that together with a type value of zero, the binary representation is 01100000, 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 universal INTEGER value of 3. 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 universal OCTET STRING containing the text cn=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 of context-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 an OCTET STRING, and those eight bytes in the value do represent the encoded string password.

A.3.6 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:

  1. 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 of CRAM-MD5 and no credentials.
  2. 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).
  3. 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.
  4. 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 or invalid 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.