You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Aleksander Adamowski <ap...@olo.org.pl> on 2012/01/14 22:34:31 UTC
Default encryptionTypes for KdcServer
Hi!
While working on my experimental KrbLDAP implementation (see the
thread on MIT krbdev list:
http://mailman.mit.edu/pipermail/krbdev/2012-January/010641.html),
I've discovered that KdcServer by default supports a very limited set
of encryption types consisting only of des-cbc-md5.
MIT's libkrb5, on the other hand, by default requires one of 4
enctypes, which doesn't include the ApacheDS's default:
aes256-cts-hmac-sha1-96 (18),
aes128-cts-hmac-sha1-96 (17),
des3-cbc-sha1-kd (16),
rc4-hmac (23)
Is this choice made on purpose?
In my experimental integration test, I'm creating the KdcServer using
the @CreateKdcServer annotation:
https://github.com/aadamowski/apacheds-krbldap-test/blob/master/src/test/java/pl/org/olo/krbldap/apacheds/test/KrbLdapIntegrationTest.java
What's the best way to configure it to handle enctypes compatible with
MIT libkrb5?
--
Best Regards,
Aleksander Adamowski
http://olo.org.pl
Re: Default encryptionTypes for KdcServer
Posted by Kiran Ayyagari <ka...@apache.org>.
committed at rev. 1233924
thanks for the patches
On Fri, Jan 20, 2012 at 6:40 PM, Aleksander Adamowski
<ap...@olo.org.pl> wrote:
> On Mon, Jan 16, 2012 at 11:42, Kiran Ayyagari <ka...@apache.org> wrote:
>> yeap, correct, earlier I tested with 256 bit
>> AES(aes256-cts-hmac-sha1-96) using default policy, now test
>> passes using 128 bit AES with default policy.
>
> So, is there anything that prevents it from being committed to SVN?
> http://svn.apache.org/repos/asf/directory/apacheds/trunk/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
>
>
> --
> Best Regards,
> Aleksander Adamowski
> http://olo.org.pl
--
Kiran Ayyagari
Re: Default encryptionTypes for KdcServer
Posted by Aleksander Adamowski <ap...@olo.org.pl>.
On Mon, Jan 16, 2012 at 11:42, Kiran Ayyagari <ka...@apache.org> wrote:
> yeap, correct, earlier I tested with 256 bit
> AES(aes256-cts-hmac-sha1-96) using default policy, now test
> passes using 128 bit AES with default policy.
So, is there anything that prevents it from being committed to SVN?
http://svn.apache.org/repos/asf/directory/apacheds/trunk/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
--
Best Regards,
Aleksander Adamowski
http://olo.org.pl
Re: Default encryptionTypes for KdcServer
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Jan 16, 2012 at 3:58 PM, Aleksander Adamowski
<ap...@olo.org.pl> wrote:
> On Mon, Jan 16, 2012 at 08:46, Kiran Ayyagari <ka...@apache.org> wrote:
>> in default Java installation AES is not enabled, user has to copy the
>> unlimited cryptography extension jars
>> (US_export_policy.jar and local_policy.jar) to enable it. (which IMHO
>> is an annoyance for most developers and users alike)
>
> I think only AES 256 is not enabled by standard policy because
> symmetric cipher key lengths are capped at 128 bits.
>
> According to my policy file on jdk 1.6.0_16:
>
> // Some countries have import limits on crypto strength. This policy
> file is worldwide importable.
> grant {
> permission javax.crypto.CryptoPermission "DES", 64;
> permission javax.crypto.CryptoPermission "DESede", *;
> permission javax.crypto.CryptoPermission "RC2", 128,
> "javax.crypto.spec.RC2ParameterSpec", 128;
> permission javax.crypto.CryptoPermission "RC4", 128;
> permission javax.crypto.CryptoPermission "RC5", 128,
> "javax.crypto.spec.RC5ParameterSpec", *, 12, *;
> permission javax.crypto.CryptoPermission "RSA", *;
> permission javax.crypto.CryptoPermission *, 128;
> };
>
> Notice that it allows all DESede variants and any other unspecified
> ciphers (including AES) at up to 128 bits key length.
>
> From looking at
> http://svn.apache.org/repos/asf/directory/apacheds/trunk/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/Des3CbcSha1KdEncryption.java
> it seems that des3-cbc-sha1-kd uses DESede.
>
> So 128 bit AES and 3DES could be used on standard policy files, I suppose:
>
yeap, correct, earlier I tested with 256 bit
AES(aes256-cts-hmac-sha1-96) using default policy, now test
passes using 128 bit AES with default policy.
appreciate the detailed information, otherwise I naively assumed that
AES was completely disabled based on the error log message.
(java.lang.IllegalArgumentException: Algorithm AES256 not enabled
at sun.security.krb5.EncryptionKey.<init>(EncryptionKey.java:292))
>>> private static final String[] DEFAULT_ENCRYPTION_TYPES = new String[]
>>> - { "des-cbc-md5" };
>>> + { "aes128-cts-hmac-sha1-96", "des3-cbc-sha1-kd", "des-cbc-md5" };
>
>
> --
> Best Regards,
> Aleksander Adamowski
> http://olo.org.pl
--
Kiran Ayyagari
Re: Default encryptionTypes for KdcServer
Posted by Aleksander Adamowski <ap...@olo.org.pl>.
On Mon, Jan 16, 2012 at 08:46, Kiran Ayyagari <ka...@apache.org> wrote:
> in default Java installation AES is not enabled, user has to copy the
> unlimited cryptography extension jars
> (US_export_policy.jar and local_policy.jar) to enable it. (which IMHO
> is an annoyance for most developers and users alike)
I think only AES 256 is not enabled by standard policy because
symmetric cipher key lengths are capped at 128 bits.
According to my policy file on jdk 1.6.0_16:
// Some countries have import limits on crypto strength. This policy
file is worldwide importable.
grant {
permission javax.crypto.CryptoPermission "DES", 64;
permission javax.crypto.CryptoPermission "DESede", *;
permission javax.crypto.CryptoPermission "RC2", 128,
"javax.crypto.spec.RC2ParameterSpec", 128;
permission javax.crypto.CryptoPermission "RC4", 128;
permission javax.crypto.CryptoPermission "RC5", 128,
"javax.crypto.spec.RC5ParameterSpec", *, 12, *;
permission javax.crypto.CryptoPermission "RSA", *;
permission javax.crypto.CryptoPermission *, 128;
};
Notice that it allows all DESede variants and any other unspecified
ciphers (including AES) at up to 128 bits key length.
>From looking at
http://svn.apache.org/repos/asf/directory/apacheds/trunk/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/Des3CbcSha1KdEncryption.java
it seems that des3-cbc-sha1-kd uses DESede.
So 128 bit AES and 3DES could be used on standard policy files, I suppose:
>> private static final String[] DEFAULT_ENCRYPTION_TYPES = new String[]
>> - { "des-cbc-md5" };
>> + { "aes128-cts-hmac-sha1-96", "des3-cbc-sha1-kd", "des-cbc-md5" };
--
Best Regards,
Aleksander Adamowski
http://olo.org.pl
Re: Default encryptionTypes for KdcServer
Posted by Kiran Ayyagari <ka...@apache.org>.
in default Java installation AES is not enabled, user has to copy the
unlimited cryptography extension jars
(US_export_policy.jar and local_policy.jar) to enable it. (which IMHO
is an annoyance for most developers and users alike)
On Sun, Jan 15, 2012 at 4:53 AM, Aleksander Adamowski
<al...@olo.org.pl> wrote:
> On Sat, Jan 14, 2012 at 22:42, Kiran Ayyagari <ka...@apache.org> wrote:
>> you can call kdcServer.setEncryptionTypes() (with an array or set of
>> EncryptionTypeS)
>> note that, this method should be called from a non-static method
>> (typically from the setup method or the one having @Before annotation)
>> calling it from static method might likely result in a null pointer exception.
>>
>> Let me know if you have any issues
>
> Thanks, it works!
> How about making the default in KdcServer compatible with MIT
> library's defaults?
>
> I think it would be sufficient to change one constant
> org.apache.directory.server.kerberos.kdc.KdcServer#DEFAULT_ENCRYPTION_TYPES:
>
> diff --git a/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
> b/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
> index fa14a4c..0673014 100644
> --- a/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
> +++ b/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
> @@ -85,7 +85,7 @@ public class KdcServer extends DirectoryBackedService
>
> /** The default encryption types */
> private static final String[] DEFAULT_ENCRYPTION_TYPES = new String[]
> - { "des-cbc-md5" };
> + { "aes256-cts-hmac-sha1-96", "aes128-cts-hmac-sha1-96",
> "des3-cbc-sha1-kd", "des-cbc-md5" };
>
> /** The default for allowing empty addresses */
> private static final boolean DEFAULT_EMPTY_ADDRESSES_ALLOWED = true;
>
> What do you think about that?
>
> Just in case, attaching a patch (attachment no. 0001).
>
> BTW, I've also found a suboptimal fragment in
> org.apache.directory.server.kerberos.kdc.KdcServer#prepareEncryptionTypes
> - sending a patch (attachment no. 0002).
>
> --
> Best Regards,
> Aleksander Adamowski
> http://olo.org.pl
--
Kiran Ayyagari
Re: Default encryptionTypes for KdcServer
Posted by Aleksander Adamowski <al...@olo.org.pl>.
On Sat, Jan 14, 2012 at 22:42, Kiran Ayyagari <ka...@apache.org> wrote:
> you can call kdcServer.setEncryptionTypes() (with an array or set of
> EncryptionTypeS)
> note that, this method should be called from a non-static method
> (typically from the setup method or the one having @Before annotation)
> calling it from static method might likely result in a null pointer exception.
>
> Let me know if you have any issues
Thanks, it works!
How about making the default in KdcServer compatible with MIT
library's defaults?
I think it would be sufficient to change one constant
org.apache.directory.server.kerberos.kdc.KdcServer#DEFAULT_ENCRYPTION_TYPES:
diff --git a/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
b/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
index fa14a4c..0673014 100644
--- a/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
+++ b/protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/kdc/KdcServer.java
@@ -85,7 +85,7 @@ public class KdcServer extends DirectoryBackedService
/** The default encryption types */
private static final String[] DEFAULT_ENCRYPTION_TYPES = new String[]
- { "des-cbc-md5" };
+ { "aes256-cts-hmac-sha1-96", "aes128-cts-hmac-sha1-96",
"des3-cbc-sha1-kd", "des-cbc-md5" };
/** The default for allowing empty addresses */
private static final boolean DEFAULT_EMPTY_ADDRESSES_ALLOWED = true;
What do you think about that?
Just in case, attaching a patch (attachment no. 0001).
BTW, I've also found a suboptimal fragment in
org.apache.directory.server.kerberos.kdc.KdcServer#prepareEncryptionTypes
- sending a patch (attachment no. 0002).
--
Best Regards,
Aleksander Adamowski
http://olo.org.pl
Re: Default encryptionTypes for KdcServer
Posted by Bob Ziuchkovski <bo...@gmail.com>.
Kiran Ayyagari <ka...@...> writes:
>
> thanks Aleksander, yes we should ignore any unknown/unsupported PA-DATA
>
> On Sun, Jan 15, 2012 at 5:27 AM, Aleksander Adamowski
> <al...@...> wrote:
> > On Sat, Jan 14, 2012 at 22:42, Kiran Ayyagari <ka...@...> wrote:
> >> you can call kdcServer.setEncryptionTypes() (with an array or set of
> >> EncryptionTypeS)
> >> note that, this method should be called from a non-static method
> >> (typically from the setup method or the one having @Before annotation)
> >> calling it from static method might likely result in a null pointer
exception.
> >>
> >> Let me know if you have any issues
> >
> > I've stumbled upon what I think is incorrect behaviour on the part of
> > ApacheDS's KDC.
> >
> > I've already consulted this with guys on MIT Kerberos dev mailing list:
> > http://mailman.mit.edu/pipermail/krbdev/2012-January/010640.html
> >
> > It seems that, if MIT libkrb5 (trunk version) and ApacheDS (version
> > 2.0.0-M1) agree on a common enctype (in my case -
> > aes256-cts-hmac-sha1-96) and proceed further, ApacheDS incorrectly
> > rejects an experimental preauth added by libkrb5 to AS-REQ message.
> >
> > What's important, this happens even using plain krb5 (without my
> > experimental KrbLDAP stuff).
> > Here's the relevant fragment from ApacheDS logs:
> >
> > [2012-01-15 00:27:16] DEBUG
> >
[org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService]
> > - Session will use encryption type aes256-cts-hmac-sha1-96 (18).
> > ...
> > [2012-01-15 00:27:16] DEBUG
> >
[org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService]
> > - Entry for client principal alice@... has no SAM type.
> > Proceeding with sta
> > ndard pre-authentication.
> > [2012-01-15 00:27:16] WARN
> > [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
> > - KDC has no support for padata type (16)
> > org.apache.directory.shared.kerberos.exceptions.KerberosException: KDC
> > has no support for padata type
> > at
org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.ve
rifyEncryptedTimestamp(AuthenticationService.java:291)
> > at
org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.ex
ecute(AuthenticationService.java:118)
> > at
org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler.messageRec
eived(KerberosProtocolHandler.java:159)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived
(DefaultIoFilterChain.java:716)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(De
faultIoFilterChain.java:434)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilte
rChain.java:46)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceive
d(DefaultIoFilterChain.java:796)
> > at
org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush
(ProtocolCodecFilter.java:427)
> > at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFi
lter.java:245)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(De
faultIoFilterChain.java:434)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilte
rChain.java:46)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceive
d(DefaultIoFilterChain.java:796)
> > at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter
.java:119)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(De
faultIoFilterChain.java:434)
> > at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(Defaul
tIoFilterChain.java:426)
> > at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoPr
ocessor.java:715)
> > at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingI
oProcessor.java:668)
> > at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingI
oProcessor.java:657)
> > at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPolli
ngIoProcessor.java:68)
> > at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPo
llingIoProcessor.java:1141)
> > at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> > at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > at java.lang.Thread.run(Thread.java:722)
> > [2012-01-15 00:27:16] DEBUG
> > [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
> > - Responding to request with error:
> > explanatory text: KDC has no support for padata type
> > error code: KDC has no support for padata type
> > clientPrincipal: null <at> null
> > client time: null
> > serverPrincipal: PrincipalName : {
> > name-type: KRB_NT_PRINCIPAL
> > name-string : <'krbtgt', 'EXAMPLE.COM'>
> > }@EXAMPLE.COM
> > server time: 20120114232716Z
> >
> >
> > According to Greg Hudson from MIT, ApacheDS KDC should just ignore the
> > presence of Kerberos preauth that it doesn't support.
> >
> >
> > --
> > Best Regards,
> > Aleksander Adamowski
> > http://olo.org.pl
>
Just a quick note -- I built ApacheDS from SVN trunk today and noticed it still
has a problem with the padata sent by recent MIT kerberos' kinit (I tested the
kinit from krb5-user-1.9.1+dfsg-1ubuntu2.2 on Ubuntu 11.10). It doesn't bug me
too much as I just switched to the heimdal userspace utils, which appear to work
just fine with ApacheDS. I just wanted to send the heads-up in case this bites
anyone else.
Re: Default encryptionTypes for KdcServer
Posted by Kiran Ayyagari <ka...@apache.org>.
thanks Aleksander, yes we should ignore any unknown/unsupported PA-DATA
On Sun, Jan 15, 2012 at 5:27 AM, Aleksander Adamowski
<al...@olo.org.pl> wrote:
> On Sat, Jan 14, 2012 at 22:42, Kiran Ayyagari <ka...@apache.org> wrote:
>> you can call kdcServer.setEncryptionTypes() (with an array or set of
>> EncryptionTypeS)
>> note that, this method should be called from a non-static method
>> (typically from the setup method or the one having @Before annotation)
>> calling it from static method might likely result in a null pointer exception.
>>
>> Let me know if you have any issues
>
> I've stumbled upon what I think is incorrect behaviour on the part of
> ApacheDS's KDC.
>
> I've already consulted this with guys on MIT Kerberos dev mailing list:
> http://mailman.mit.edu/pipermail/krbdev/2012-January/010640.html
>
> It seems that, if MIT libkrb5 (trunk version) and ApacheDS (version
> 2.0.0-M1) agree on a common enctype (in my case -
> aes256-cts-hmac-sha1-96) and proceed further, ApacheDS incorrectly
> rejects an experimental preauth added by libkrb5 to AS-REQ message.
>
> What's important, this happens even using plain krb5 (without my
> experimental KrbLDAP stuff).
> Here's the relevant fragment from ApacheDS logs:
>
> [2012-01-15 00:27:16] DEBUG
> [org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService]
> - Session will use encryption type aes256-cts-hmac-sha1-96 (18).
> ...
> [2012-01-15 00:27:16] DEBUG
> [org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService]
> - Entry for client principal alice@EXAMPLE.COM has no SAM type.
> Proceeding with sta
> ndard pre-authentication.
> [2012-01-15 00:27:16] WARN
> [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
> - KDC has no support for padata type (16)
> org.apache.directory.shared.kerberos.exceptions.KerberosException: KDC
> has no support for padata type
> at org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.verifyEncryptedTimestamp(AuthenticationService.java:291)
> at org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.execute(AuthenticationService.java:118)
> at org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler.messageReceived(KerberosProtocolHandler.java:159)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
> at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:427)
> at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:245)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
> at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:715)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1141)
> at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> [2012-01-15 00:27:16] DEBUG
> [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
> - Responding to request with error:
> explanatory text: KDC has no support for padata type
> error code: KDC has no support for padata type
> clientPrincipal: null@null
> client time: null
> serverPrincipal: PrincipalName : {
> name-type: KRB_NT_PRINCIPAL
> name-string : <'krbtgt', 'EXAMPLE.COM'>
> }@EXAMPLE.COM
> server time: 20120114232716Z
>
>
> According to Greg Hudson from MIT, ApacheDS KDC should just ignore the
> presence of Kerberos preauth that it doesn't support.
>
>
> --
> Best Regards,
> Aleksander Adamowski
> http://olo.org.pl
--
Kiran Ayyagari
Re: Default encryptionTypes for KdcServer
Posted by Aleksander Adamowski <al...@olo.org.pl>.
On Sat, Jan 14, 2012 at 22:42, Kiran Ayyagari <ka...@apache.org> wrote:
> you can call kdcServer.setEncryptionTypes() (with an array or set of
> EncryptionTypeS)
> note that, this method should be called from a non-static method
> (typically from the setup method or the one having @Before annotation)
> calling it from static method might likely result in a null pointer exception.
>
> Let me know if you have any issues
I've stumbled upon what I think is incorrect behaviour on the part of
ApacheDS's KDC.
I've already consulted this with guys on MIT Kerberos dev mailing list:
http://mailman.mit.edu/pipermail/krbdev/2012-January/010640.html
It seems that, if MIT libkrb5 (trunk version) and ApacheDS (version
2.0.0-M1) agree on a common enctype (in my case -
aes256-cts-hmac-sha1-96) and proceed further, ApacheDS incorrectly
rejects an experimental preauth added by libkrb5 to AS-REQ message.
What's important, this happens even using plain krb5 (without my
experimental KrbLDAP stuff).
Here's the relevant fragment from ApacheDS logs:
[2012-01-15 00:27:16] DEBUG
[org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService]
- Session will use encryption type aes256-cts-hmac-sha1-96 (18).
...
[2012-01-15 00:27:16] DEBUG
[org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService]
- Entry for client principal alice@EXAMPLE.COM has no SAM type.
Proceeding with sta
ndard pre-authentication.
[2012-01-15 00:27:16] WARN
[org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
- KDC has no support for padata type (16)
org.apache.directory.shared.kerberos.exceptions.KerberosException: KDC
has no support for padata type
at org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.verifyEncryptedTimestamp(AuthenticationService.java:291)
at org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.execute(AuthenticationService.java:118)
at org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler.messageReceived(KerberosProtocolHandler.java:159)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:427)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:245)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:715)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1141)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
[2012-01-15 00:27:16] DEBUG
[org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler]
- Responding to request with error:
explanatory text: KDC has no support for padata type
error code: KDC has no support for padata type
clientPrincipal: null@null
client time: null
serverPrincipal: PrincipalName : {
name-type: KRB_NT_PRINCIPAL
name-string : <'krbtgt', 'EXAMPLE.COM'>
}@EXAMPLE.COM
server time: 20120114232716Z
According to Greg Hudson from MIT, ApacheDS KDC should just ignore the
presence of Kerberos preauth that it doesn't support.
--
Best Regards,
Aleksander Adamowski
http://olo.org.pl
Re: Default encryptionTypes for KdcServer
Posted by Kiran Ayyagari <ka...@apache.org>.
you can call kdcServer.setEncryptionTypes() (with an array or set of
EncryptionTypeS)
note that, this method should be called from a non-static method
(typically from the setup method or the one having @Before annotation)
calling it from static method might likely result in a null pointer exception.
Let me know if you have any issues
HTH
On Sun, Jan 15, 2012 at 3:04 AM, Aleksander Adamowski
<ap...@olo.org.pl> wrote:
> Hi!
>
> While working on my experimental KrbLDAP implementation (see the
> thread on MIT krbdev list:
> http://mailman.mit.edu/pipermail/krbdev/2012-January/010641.html),
> I've discovered that KdcServer by default supports a very limited set
> of encryption types consisting only of des-cbc-md5.
>
> MIT's libkrb5, on the other hand, by default requires one of 4
> enctypes, which doesn't include the ApacheDS's default:
> aes256-cts-hmac-sha1-96 (18),
> aes128-cts-hmac-sha1-96 (17),
> des3-cbc-sha1-kd (16),
> rc4-hmac (23)
>
> Is this choice made on purpose?
>
> In my experimental integration test, I'm creating the KdcServer using
> the @CreateKdcServer annotation:
> https://github.com/aadamowski/apacheds-krbldap-test/blob/master/src/test/java/pl/org/olo/krbldap/apacheds/test/KrbLdapIntegrationTest.java
>
> What's the best way to configure it to handle enctypes compatible with
> MIT libkrb5?
>
>
> --
> Best Regards,
> Aleksander Adamowski
> http://olo.org.pl
--
Kiran Ayyagari