Introduction
We have a lot of excellent building blocks for a combined LDAP+Kerberos server. We need to "close the loop" on a number of features that will show the promise of combining LDAP and Kerberos and drastically improve our usability as a realm controller. In short, we need to:
- Add SASL GSSAPI authentication to the LDAP protocol - LDAP is our chosen management protocol. Through some combination of LDAP operations, extended operations, interceptors, and triggers/stored-procedures, we'll be able to manage our realm controller. But, the LDAP protocol needs authentication based on Kerberos credentials.
- Support Kerberos Version 5 Specification 2 (RFC 4120) Encryption Types - We need to add support for "modern" encryption types: AES256-CTS-HMAC-SHA1-96, AES128-CTS-HMAC-SHA1-96, and DES3-CBC-SHA1-KD. Additionally, for interoperability, we should support RC4-HMAC ("ArcFour with HMAC/md5"). Note: we already support DES-CBC-MD5, which is also listed in RFC 4120.
- Key provisioning (generation) - We need to make it easier to get keys into the directory. Today we can only get keys in by initial LDIF load or by OSGi console command. Keys need to be derived automatically from plaintext passwords or generated randomly.
- Key provisioning (export) - We need to make it easier to get keys out of the directory. We need a simple client mechanism for exporting keys to keytabs.
- Centralize password management - We need to make sure that when passwords are changed, be it by LDAP, LDIF, or Change Password, that a password policy is enforced centrally. Policy is typically applied per-server and per-realm. We have some interesting possibilities with subtrees and subtree refinements.
SASL GSSAPI (Kerberos) Authentication for the LDAP protocol
SASL GSSAPI support is now available in the ApacheDS 1.5.1 trunk. This is a prerequisite for using the LDAP protocol for KDC administration. We expect to use the LDAP protocol to manage the KDC and to export service keys. More information is available at HOWTO do SASL GSSAPI Authentication to ApacheDS.
Support modern encryption types
RFC 3961 (DES and Triple DES) and RFC 3962 (AES128 and AES256) encryption type support is now available in the ApacheDS 1.5.1 trunk. The following encryption types are now supported:
aes256-cts-hmac-sha1-96
aes128-cts-hmac-sha1-96
des3-cbc-sha1-kd
des-cbc-md5
des-cbc-crc
Kerberos key provisioning (generation)
Automatic centralized key derivation and random key generation are now available in the ApacheDS 1.5.1 trunk by using the KeyDerivationService interceptor. For more up-to-date status, please see the following issue in JIRA: https://issues.apache.org/jira/browse/DIRSERVER-897
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Support for PKINIT is well underway. For more up-to-date status, please see the following issue in JIRA: https://issues.apache.org/jira/browse/DIRSERVER-1076
Kerberos key provisioning (export)
Service principals typically do not use passwords. Instead their key is generated randomly. The random key is then exported from the KDC into a keytab ("key table") file for use by a service, such as OpenLDAP, an HTTP server, or SSHD. Today we have no easy way to get keys out of the directory. We need to be able to read keys from the directory and write them to a keytab file.
Additionally, to prevent a client from reading all the keys in the directory with a compromised administrative account, the server needs to generate a new random key on each read and increment the key version number (kvno).
Work is currently underway on a client that uses LDAP to read a key from the directory and write it to a keytab file. This client works in conjunction with a KeyExportService interceptor that ensures that keys read from outside the directory are re-randomized and the key version number (kvno) incremented.
For more up-to-date status, please see the following issue in JIRA: https://issues.apache.org/jira/browse/DIRSERVER-898
Password management
We have several issues related to password management that affect Kerberos, Change Password, LDAP, and the core, that I'd like to try to address for 1.5.1. Today passwords can be changed by LDIF load, the LDAP protocol, and the Change Password protocol. Above we mentioned that several authentication mechanisms either rely directly (LDAP) or indirectly (Kerberos, via derived keys) on the password. We have the additional problem that currently password policy is not applied centrally, let alone per subtree/subtree refinement. The Change Password protocol provider enforces a best-practice password policy, however, this is bypassed during other password sets, such as during LDIF load or LDAP modify operations.
2 things have to change:
- Password policy enforcement also moves to the core, for reuse by other mechanisms for password changes. Password policy is currently enforced in the CheckPasswordPolicy IoHandlerCommand. There is a major issue here that rejected passwords would need to result in error handling that results in the proper Change Password error being returned to the client.
- Looking further down the road, yet relevant to access control work, passwords should be modifiable according to access control. Users need to be able to change their own password and, additionally, admins with proper rights need to be able to initialize and change passwords, too.
We need to implement the "one true location" for passwords and the centralized enforcement of password policy.
For more up-to-date status, please see the following issues in JIRA:
Support centralized password policy enforcement https://issues.apache.org/jira/browse/DIRSERVER-899
Allow administrators to change and set passwords for users (DIRSERVER-110) https://issues.apache.org/jira/browse/DIRSERVER-110
Add Support for LDAP Password Modify Extended Operation (DIRSERVER-275) https://issues.apache.org/jira/browse/DIRSERVER-275
Configure an optional password message digest algorithm which is applied on userPassword attribute values at add and modify operations. (DIRSERVER-289) https://issues.apache.org/jira/browse/DIRSERVER-289
IDfusion: Kerberos- and LDAP-based Authorization
Looking further out, we have a real opportunity to impact how authorization decisions are made. However, the above usability issues have to take precedent.
Resources
Conference Materials: IDfusion, An Open-Architecture for Kerberos-based Authorization http://docs.safehaus.org/display/APACHEDS/IDfusion%2C+An+Open-Architecture+for+Kerberos-based+Authorization
KEYPROV: Symmetric key provisioning infrastructure
From the charter:
The scope of the working group shall be to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes.
The group shall consider use cases related to use of Shared Symmetric Key Tokens. Other use cases may be considered for the purpose of avoiding unnecessary restrictions in the design and ensure the potential for future extensibility.
The working group will produce the following deliverables:
- Portable Symmetric Key Container
- Dynamic Symmetric Key Provisioning Protocol
Resources
Extensions to CT-KIP to support one- and two-pass key initialization http://www.ietf.org/internet-drafts/draft-nystrom-ct-kip-two-pass-01.txt
Portable Symmetric Key Container http://www.ietf.org/internet-drafts/draft-vassilev-portable-symmetric-key-container-02.txt
IETF-Keyprov Mailing List http://lists.safehaus.org/mailman/listinfo/ietf-keyprov
IETF Announcement: New mailing list for discussion of KEYPROV symmetric key provisioning proposal http://www.mhonarc.org/archive/html/ietf/2006-06/msg00198.html