Return-Path: 
 <dev-return-18308-apmail-directory-dev-archive=directory.apache.org@directory.apache.org>
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: (qmail 42213 invoked from network); 7 May 2007 18:32:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 7 May 2007 18:32:10 -0000
Received: (qmail 97154 invoked by uid 500); 7 May 2007 18:32:17 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 96934 invoked by uid 500); 7 May 2007 18:32:16 -0000
Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@directory.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@directory.apache.org>
List-Post: <mailto:dev@directory.apache.org>
List-Id: <dev.directory.apache.org>
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Delivered-To: mailing list dev@directory.apache.org
Received: (qmail 96923 invoked by uid 99); 7 May 2007 18:32:16 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 May 2007 11:32:16 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of enriquer9@gmail.com designates
 64.233.162.225 as permitted sender)
Received: from [64.233.162.225] (HELO nz-out-0506.google.com) (64.233.162.225)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 May 2007 11:32:09 -0700
Received: by nz-out-0506.google.com with SMTP id i28so1695017nzi
        for <dev@directory.apache.org>; Mon, 07 May 2007 11:31:48 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=UENQyuRs/56pFdOvUcAoN3YR07igo3wItdM7b0rnOoWRSMxnql6RQkhdC9szrFRW0cfkmxiqeL2KJQGDDOwFz5Ez9ygsS8WiIKaCVfFCEA4rQ0CKsDwwS7KISHtvDSQjEnmcvxMW9rWCnbE5KadRKSecrWaZFU5OQ2a5Hf2JhL8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=UZpUGMqjCn2awss2u/9JMErec/gLeEBYz94ovtmv6i9pfm3y1DYXhKz1EWm7oUJV0oF/4jWk4PL720gesoCR7kDEB45Nxe++4WipgrAQWWgcI25BZcgGt4hxmKvflJkYjkaVajDVSfn+b2rXlhoAf59PCwy9QjeNvsYrDwI0Hwg=
Received: by 10.114.122.2 with SMTP id u2mr2252740wac.1178562707343;
        Mon, 07 May 2007 11:31:47 -0700 (PDT)
Received: by 10.115.111.11 with HTTP; Mon, 7 May 2007 11:31:47 -0700 (PDT)
Message-ID: <568753d90705071131i56ace29am401bbd0246001c26@mail.gmail.com>
Date: Mon, 7 May 2007 11:31:47 -0700
From: "Enrique Rodriguez" <enriquer9@gmail.com>
Reply-To: erodriguez@apache.org
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [Kerberos] Encryption types branch stabilized
In-Reply-To: <463ECA70.8080202@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <568753d90705061859i3949dcdbid45c8fa422d5af53@mail.gmail.com>
	 <463ECA70.8080202@apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

On 5/6/07, Emmanuel Lecharny <elecharny@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