You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Enrique Rodriguez <en...@gmail.com> on 2007/05/07 03:59:08 UTC
[Kerberos] Encryption types branch stabilized
Hi, Directory developers,
Work in the kerberos-encryption-types branch has now stablized. I'll
be doing more interop testing over the next week and I can think of
some minor refactoring and other enhancements but everything is pretty
much working. I just checked in a server.xml in server-main in the
branch that shows how to enable Kerberos and Change Password, how to
enable the encryption types, and where the KeyDerivationService
interceptor needs to be inserted. So ...
1) The branch now supports the following encryption types:
aes256-cts-hmac-sha1-96
aes128-cts-hmac-sha1-96
des3-cbc-sha1-kd
des-cbc-md5
des-cbc-crc
This addresses JIRA issues:
(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) We now support automatic centralized key generation for Kerberos
principals, using a KeyDerivationService interceptor. This
interceptor will produce the following key types:
DES
DES3
AES128
AES256
RC4-HMAC
This addresses JIRA issue:
(DIRSERVER-897) Support automatic centralized key generation for
Kerberos principals
With the "key derivation" interceptor inserted in the service chain,
changes to the 'userPassword' attribute now result in automatic key
derivation or generation for Kerberos principals. If the special
keyword 'randomKey' is used, the principal receives random keys.
The interceptor works great whether the 'userPassword' is changed over
the LDAP protocol, by the ChangePassword protocol, or by LDIF load.
This is a testament to the interceptor service chain in the core. The
interceptor will make working with Kerberos principals much easier.
Enrique
Re: [Kerberos] Encryption types branch stabilized
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/8/07, Emmanuel Lecharny <el...@apache.org> wrote:
> Enrique,
>
> just wondering, is all this code complies with US rules about
> cryptography ?
1) We're using crypto in the JDK. We moved to JDK crypto 100% when
we removed the Bouncy Castle dependency.
2) US export policy restricts key size. For example, the Sun and IBM
JDK's ship with AES256 crypto, but it is disabled by policy. There is
an exception thrown when AES-256 is not enabled.
(a) Because 256-bit AES keys are used in the Kerberos encryption type
'aes256-cts-hmac-sha1-96', you must install the "unlimited strength"
policy file for it it work.
(b) Similarly, the KeyDerivationService interceptor, which is now
responsible for generating 256-bit AES keys, requires the "unlimited
strength" policy for it to automatically generate 256-bit bits.
Enrique
Re: [Kerberos] Encryption types branch stabilized
Posted by Emmanuel Lecharny <el...@apache.org>.
Enrique,
just wondering, is all this code complies with US rules about
cryptography ? I mean, there are some restriction on what could be
exported out of USA, and we have to take care of those rules.
Can you check this point?
Thanks !!!
Enrique Rodriguez a écrit :
> On 5/6/07, Emmanuel Lecharny <el...@apache.org> wrote:
>
>> ...
>> hey, thanks for all this code ! We now have to check it before merging
>> it, and we will do it this week, so that we will be both ready at the
>> same time to merge the code into the trunk !
>> <snip/>
>
>
> One thing to watch for is that AES256 requires "unlimited strength"
> policy in the JRE. I tried to make sure to handle its absence
> gracefully and to comment-out relevant unit tests. But, I haven't
> tested it on any platforms except Linux or VM's except Sun.
>
> I think this branch (encryption types) should merge in before the SASL
> branch. Once the new encryption types are in trunk, I'd like to
> revisit the SASL branch since there is some interop with SASL GSSAPI
> and Kerberos that I'd like to ensure is working.
>
>> > The interceptor works great whether the 'userPassword' is changed over
>> > the LDAP protocol, by the ChangePassword protocol, or by LDIF load.
>> > This is a testament to the interceptor service chain in the core. The
>> > interceptor will make working with Kerberos principals much easier.
>>
>> Just great !
>>
>> I can't wait to see all that alive in trunks ! Ok, svn co
>> kerberos-branch running :)
>
>
> The more I think about it, the more I'd like to get a password policy
> interceptor in there. Now that key derivation/generation is
> centralized, it makes even more sense to centralize password policy
> enforcement. There is a basic password policy validator in the Change
> Password and I'd like to convert this to an interceptor. I'm thinking
> I would model it after the AuthenticationService, w.r.t. how
> Authenticators are "pluggable." I would commit a policy validator
> based on the one in Change Password and we'd have this extension point
> available for other custom policies.
>
> Also, I'm going to start in on "key export" now, re: Realm Control
> Initiatives [1].
>
> Enrique
>
> [1]
> http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initiatives
>
>
Re: [Kerberos] Encryption types branch stabilized
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/6/07, Emmanuel Lecharny <el...@apache.org> wrote:
> ...
> hey, thanks for all this code ! We now have to check it before merging
> it, and we will do it this week, so that we will be both ready at the
> same time to merge the code into the trunk !
> <snip/>
One thing to watch for is that AES256 requires "unlimited strength"
policy in the JRE. I tried to make sure to handle its absence
gracefully and to comment-out relevant unit tests. But, I haven't
tested it on any platforms except Linux or VM's except Sun.
I think this branch (encryption types) should merge in before the SASL
branch. Once the new encryption types are in trunk, I'd like to
revisit the SASL branch since there is some interop with SASL GSSAPI
and Kerberos that I'd like to ensure is working.
> > The interceptor works great whether the 'userPassword' is changed over
> > the LDAP protocol, by the ChangePassword protocol, or by LDIF load.
> > This is a testament to the interceptor service chain in the core. The
> > interceptor will make working with Kerberos principals much easier.
>
> Just great !
>
> I can't wait to see all that alive in trunks ! Ok, svn co
> kerberos-branch running :)
The more I think about it, the more I'd like to get a password policy
interceptor in there. Now that key derivation/generation is
centralized, it makes even more sense to centralize password policy
enforcement. There is a basic password policy validator in the Change
Password and I'd like to convert this to an interceptor. I'm thinking
I would model it after the AuthenticationService, w.r.t. how
Authenticators are "pluggable." I would commit a policy validator
based on the one in Change Password and we'd have this extension point
available for other custom policies.
Also, I'm going to start in on "key export" now, re: Realm Control
Initiatives [1].
Enrique
[1] http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initiatives
Re: [Kerberos] Encryption types branch stabilized
Posted by Emmanuel Lecharny <el...@apache.org>.
> Hi, Directory developers,
Hi Enrique !
>
> Work in the kerberos-encryption-types branch has now stablized. I'll
> be doing more interop testing over the next week and I can think of
> some minor refactoring and other enhancements but everything is pretty
> much working. I just checked in a server.xml in server-main in the
> branch that shows how to enable Kerberos and Change Password, how to
> enable the encryption types, and where the KeyDerivationService
> interceptor needs to be inserted. So ...
hey, thanks for all this code ! We now have to check it before merging
it, and we will do it this week, so that we will be both ready at the
same time to merge the code into the trunk !
<snip/>
>
>
> The interceptor works great whether the 'userPassword' is changed over
> the LDAP protocol, by the ChangePassword protocol, or by LDIF load.
> This is a testament to the interceptor service chain in the core. The
> interceptor will make working with Kerberos principals much easier.
Just great !
I can't wait to see all that alive in trunks ! Ok, svn co
kerberos-branch running :)
>
> Enrique
Emmanuel