[Kerberos] Need to branch, part 2

[Enrique Rodriguez <en...@gmail.com>]

Hi, Directory developers,

I'm hoping to wrap up work in the kerberos-encryption-types branch
this weekend.  This is an update to let you know where I'm at.

1)  I have now mostly addressed the below JIRA issues.
DES3-CBC-SHA1-KD, AES128, and AES256 appear to be working.  I say
"appear" because of issue #2, below.

(DIRSERVER-141) Add DES3-CBC-SHA1-KD encryption system
(DIRSERVER-142) Add support for AES encryption types
(DIRSERVER-153) Make encryption system selection configurable

2)  Because we've only ever supported loading DES keys into the DIT, I
can only now work with some hardcoded AES128, AES256, and Triple-DES
key values.  So, I had to expand the scope of the work in the branch
to include JIRA issue:

(DIRSERVER-897) Support automatic centralized key generation for
Kerberos principals

I just added, on rev 535094, a "key derivation" interceptor.  Changes
to the 'userPassword' attribute now result in automatic key derivation
for Kerberos principals.  If the special keyword 'randomKey' is used,
the principal receives random keys.  It currently only works for DES
keys but it will be trivial to add AES128, AES256, Triple-DES, and
RC4-HMAC keys this weekend.  Most of the ancillary helper support is
already in place.

As it currently stands, the interceptor works great and I think it's
pretty much ready to replace the "Kerberos-aware" LDIF loader we've
been using.  The LDIF loader only supports DES keys and the
interceptor is way more convenient, so I'm hoping we can deprecate the
loader.

3)  I had to make one major change to support multiple Kerberos keys.
If you look at the schema we use, the key is actually supposed to be
ASN.1 encoded so it can be stored along with required metadata, such
as it's encryption type (DES vs. AES128, etc.).

attributetype ( 1.3.6.1.4.1.5322.10.1.10
	NAME 'krb5Key'
	DESC 'Encoded ASN1 Key as an octet string'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

We've never done that; rather we've always stored the raw key bytes in
this attribute.  We really need the key stored with its metadata in
ASN.1 form, so I went ahead and started encoding the keys.  This means
a change to the Kerberos protocol to decode the keys and it also means
the LDIF loader won't work, which, IMO, is fine since it was never
useful enough.

There was a thread where Ersin and I discussed this interceptor and
eventually modifying it to be a trigger/SP that you could apply to a
subtree/refinement.  I look forward to that work, but for now I'm
going to use an interceptor to get the encryption types working.  I
added an integration test to 'server-unit' (in the branch) that
demonstrates this interceptor and using it with the LDAP protocol to
update user passwords.

Enrique